ACID、Data Replication、CAP、BASE

ACID、Data Replication、CAP与BASE 

ACID

在传数据库系统中，事务具有ACID 4个属性(Jim Gray在《事务处理：概念与技术》中对事务进行了详尽的讨论)。

(1)原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。

(2)一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。

(3)隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。

(4)持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

对于单个节点的事务，数据库都是通过并发控制（两阶段封锁，two phase locking或者多版本，multiversioning）和恢复机制（日志技术）保证事务的ACID特性。对于跨多个节点的分布式事务，通过两阶段提交协议（two phase commiting）来保证事务的ACID。

可以说，数据库系统是伴随着金融业的需求而快速发展起来。对于金融业，可用性和性能都不是最重要的，而一致性是最重要的，用户可以容忍系统故障而停止服务，但绝不能容忍帐户上的钱无故减少(当然，无故增加是可以的)。而强一致性的事务是这一切的根本保证。

 

Data Replication

数据复制(data replication)属于分布式计算的范畴，它并不仅仅局限于数据库，但这里主要是指分布式数据库的复制。

在多副本构成的分布式数据库系统中， 其事务特性与单个数据库系统的差别主要表现在原子性和一致性两个方 面。在原子性方面， 要求同一分布式事务的所有操作在所有相关副本上要么提交， 要么回滚， 即除了保证原有的局部事务的原子性，还需要控制全局事务的原子性； 在一致性方面，多副本之间需要保证单一副本一致性。 

针对分布式事务的原子性和一致性这两个复制协议中的核心问题， 经过近20年的研究 ， 人们提出了各种各样的复制协议。这些协议在外在功能和内部实现两方面都有较大的差别。据此，我们可以从这两个大的方面进行分类说明。

从外在功能的角度看， 依据文献[1]， 可以从事务执行的地点和时间两个方面进行分类。从事务执行的地点，可以分为两类： 主从( Priamry / Copy)方式和更新所有( Update-Anywhere ) 方式。

前者的处理过程一般是系统中仅仅指定一个Primary节点接受更新请求 ， 在事务操作执行完毕后， 在事务提交前或后将操作广播到其他Copy节点。

后者的处理过程稍微复杂， 系统中的任何副本具有相同的地位，都可以接收Update请求 ，在检测事务冲突、 事务提交前或后将各个节点的Update传播到其他副本节点。

Primary / Copy方式并发控制较为简单， 由Primary本地的事务控制即可实现， 事务的原子性的实现也较为简单， 一般由Primary节点作为协调节点来实现。但是， 其缺陷也显而易见： 仅仅单个节点提供Update请求处理能力， 对于Update密集类型的应用， 如OLTP， 容易形成单点性能瓶颈。Update-Anywhere方式则与其相辅相成， 可以通过多点提高事务吞吐率， 但随之而来的是多个分布式事务之间复杂的并发控制和原子性问题。

      从事务提交的时间点看， 可以分为积极 (Eager)和消极(Lazy) 两类。其区别在于， 前者是在事务提交前传播更新，后者则是在提交之后才将事务操作传播到其他副本。实际上，前者即通常无谓的同步复制(synchronous replication)，后者即无谓的异步复制(asynchronous replication)。

异步复制的优点是可以提高响应速度， 但牺牲了一致性 ，一般实现该类协议的算法需要增加额外的补偿机制。同步复制的优点是可以保证一致性(一般通过两阶段提交协议)，但是开销较大，可用性不好(参见CAP部分)，带来了更多的冲突和死锁等问题。值得一提的是Lazy+Primary/Copy的复制协议在实际生产环境中是非常实用的，MySQL的复制实际上就属于这种。

 

CAP

在2000的PODC（Principles of Distributed Computing）会议上，Brewer提出了著名的CAP理论。2002年，Seth Gilbert和Nancy Lynch证明了这一理论。CAP指的是：Consistency、Availability和Partition Tolerance。

（1）Consistency（一致性）：一致性是说数据的原子性，这种原子性在经典的数据库中是通过事务来保证的，当事务完成时，无论其是成功还是回滚，数据都会处于一致的状态。在分布式环境中，一致性是说多个节点的数据是否一致。

（2）Availability（可用性）：可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果。

（3）Partition Tolerance（分区容错性）：Partition是指网络的分区。可以这样理解，一般来说，关键的数据和服务都会位于不同的IDC。（可理解为部分节点故障或节点之间连接故障下系统仍可正常工作）

CAP理论告诉我们，一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个需求，三个要素中最多只能同时满足两点。三者不可兼顾，此所谓鱼与熊掌不可兼得也！而对于分布式数据系统而言，分区容错性是基本要求，否则就不称其为分布式系统了。因此架构设计师不要把精力浪费在设计如何能同时满足三者的完美分布式系统上，而是应该进行权衡取舍。这也意味着分布式系统的设计过程，也就是根据业务特点在C（一致性）和A（可用性）之间寻求平衡的过程，要求架构师真正理解系统需求，把握业务特点。

 

 

BASE

BASE来自于互联网的电子商务领域的实践，它是基于CAP理论逐步演化而来，核心思想是即便不能达到强一致性(Strong consistency)，但可以根据应用特点采用适当的方式来达到最终一致性(Eventual consistency)的效果。BASE是Basically Available、Soft state、Eventually consistent三个词组的简写，是对CAP中C & A的延伸。BASE的含义：

（1）Basically Available：基本可用；

（2）Soft-state：软状态/柔性事务，即状态可以有一段时间的不同步；

（3）Eventual consistency：最终一致性；

BASE是反ACID的，它完全不同于ACID模型，牺牲强一致性，获得基本可用性和柔性可靠性并要求达到最终一致性。

CAP、BASE理论是当前在互联网领域非常流行的NoSQL的理论基础。


－－－

如 果网络中不存在分区，客户端和存储系统在同一环境中，通过分布式事务机制可以保证一致性和可用性。但在大型网络 系统中，分区是必然存在的，因此一般的选择只能是在一致性和可用性之间权衡和折衷。如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份时，此次写操作必须失败，系统变得不可用。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11990065/viewspace-715489/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11990065/viewspace-715489/