BASE,CAP,ACID（转载）

云计算平台是非常巨大的分布式系统，需要处理庞大的处理请求，因此任何小概率事件在此平台中都必然发生。 


DBMS强调ACID：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性 (Durability)。其中的一致性强调当程序员定义的事务完成时，数据库处于一致的状态，如对于转帐来说，事务完成时必须是A少了多少钱B就多了多 少钱。而对于很多互联网应用来说，对于一致性和隔离性的要求可以降低，而可用性(Availability)的要求则更为明显。从而产生了两种弱一致性的 理论：BASE和CAP。 

BASE：Basically Availble --基本可用；Soft-state --；Eventual Consistency --最终一致性 

 

CAP： Consistency 一致性；Availability 可用性； Tolerance of network Partition 分区容忍性（可理解为部分节点故障或节点之间连接故障下系统仍可正常工作）。Brewer提出的该经验理论认为这三个目标最多只能达成两个，而另一个则需 要通过其他方式来弥补。 


如果网络中不存在分区，客户端和存储系统在同一环境中，通过分布式事务机制可以保证一致性和可用性。但在大型网络 系统中，分区是必然存在的，因此一般的选择只能是在一致性和可用性之间权衡和折衷。如Ebay的经验尽可能保证可用性，但采用周密调整数据库操作的次序、 异步恢复事件，以及数据核对（reconciliation）或者集中决算（settlement batches）等方式来帮助系统达到最终一致性。 


实际互联网系统往往都是ACID和BASE两种系统的结合，例如用户身份数据、交易数据通常采取ACID准则。 

Guy Pardon认为，CAP理论认为三者不能同时达到是假定CAP被满足是在at the same moment in time，如果放弃这个假定就可以得到三者都满足的方案。但是在我看来，其方案也只是在可用性和一致性之间的折衷而已。放弃了读写一致性，读到的可能只是 cache中的快照而不是最新值；通过在系统无分区时才执行写入队列来保证数据更新一致性，而结果则是异步获得，相当于是对写入可用性要求的一种降低。 

数据一致性通常指关联数据之间的逻辑关系是否正确和完整。而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。如果使用者遵 循这种约定，则可以得到系统所承诺的访问结果。 
常用的一致性模型有： 
a、严格一致性（linearizability, strict/atomic Consistency）：读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能，在分布式网络环境不可能实现。 

b、顺序一致性（sequential consistency）：所有使用者以同样的顺序看到对同一数据的操作，但是该顺序不一定是实时的。 
c、因果一致性（causal consistency）：只有存在因果关系的写操作才要求所有使用者以相同的次序看到，对于无因果关系的写入则并行进行，无次序保证。因果一致性可以看 做对顺序一致性性能的一种优化，但在实现时必须建立与维护因果依赖图，是相当困难的。 
d、管道一致性（PRAM/FIFO consistency）：在因果一致性模型上的进一步弱化，要求由某一个使用者完成的写操作可以被其他所有的使用者按照顺序的感知到，而从不同使用者中 来的写操作则无需保证顺序，就像一个一个的管道一样。 相对来说比较容易实现。 
e、弱一致性（weak consistency）：只要求对共享数据结构的访问保证顺序一致性。对于同步变量的操作具有顺序一致性，是全局可见的，且只有当没有写操作等待处理时 才可进行，以保证对于临界区域的访问顺序进行。在同步时点，所有使用者可以看到相同的数据。 
f、 释放一致性（release consistency）：弱一致性无法区分使用者是要进入临界区还是要出临界区， 释放一致性使用两个不同的操作语句进行了区分。需要写入时使用者acquire该对象，写完后release，acquire-release之间形成了 一个临界区，提供 释放一致性也就意味着当release操作发生后，所有使用者应该可以看到该操作。 
g、最终一致性（eventual consistency）：当没有新更新的情况下，更新最终会通过网络传播到所有副本点，所有副本点最终会一致，也就是说使用者在最终某个时间点前的中间 过程中无法保证看到的是新写入的数据。可以采用最终一致性模型有一个关键要求：读出陈旧数据是可以接受的。 
h、delta consistency：系统会在delta时间内达到一致。这段时间内会存在一个不一致的窗口，该窗口可能是因为log shipping的过程导致。 

最终一致性的几种具体实现： 
1、读不旧于写一致性（Read-your-writes consistency）：使用者读到的数据，总是不旧于自身上一个写入的数据。 
2、会话一致性（Session consistency）：比读不旧于写一致性更弱化。使用者在一个会话中才保证读写一致性，启动新会话后则无需保证。 
3、单读一致性（Monotonic read consistency）：读到的数据总是不旧于上一次读到的数据。 
4、单写一致性（Monotonic write consistency）：写入的数据完成后才能开始下一次的写入。 
5、写不旧于读一致性（Writes-follow-reads consistency）：写入的副本不旧于上一次读到的数据，即不会写入更旧的数据。 
Werner Vogels认为：在很多互联网应用中，单读一致性＋读不旧于写一致性可以提供足够的一致性了。 

Werner Vogels基于NWR模型来分析一致性，该模型决定了亚马逊云计算技术架构的方向。 
N－副本个数，W－每次同步写入的副本个数，R－每次读出副本个数。认为只要W+R>N，就可以达到很强一致性。例如同步方式 N=2,W=2,R=1，则始终是一致的；而如果是异步方式，则每次同步写入的W只有1，就不能保证一致性。如果W 要保证强一致性，那么如果每次不能写够W份时，此次写操作必须失败，系统变得不可用。