CAP和BASE理论以及分布式事务

回想12年左右刚开始接触Nosql，各种Nosql数据库如雨后春笋般出现，如MongoDB、Redis、Hadoop、CouchDB等等，其中有一篇CAP理论文章非常火。到现在CAP、ACID、BASE各种概念，但分布式事务是必须面对的问题。

ACID

数据库管理系统中事务(transaction)的四个特性
原子性（Atomicity）
原子性是指事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。

一致性（Consistency）
一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。

隔离性（Isolation）
多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。（数据库事务隔离级别）

持久性（Durability）
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，即使数据库发生故障也不应该对其有任何影响。

所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。

单实例关系型数据库天生就是解决具有复杂事务场景的问题，关系型数据库完全满足ACID的特性。

CAP理论

1. Consisteny（一致性）

   一致性的要求是指，对于任何客户端来说，每次的读操作，都能获得最新的数据。即，当有客户端向A节点写入了新数据之后，其它客户端从B节点中进行读操作所获得的数据必须也是最新的，是与A节点数据保持一致的。

2. Availability（可用性）

   可用性的要求是指，每个请求都能在合理的时间内获得符合预期的响应（不保证获取的结果是最新的数据）。

   客户端只要向A节点或B节点发起请求后，只要这两个节点收到了请求，就必须响应给客户端，但不需要保证响应的值是否正确。

3. Partition tolerance（分区容错性）

   分区容错性是指，当节点之间的网络出现问题之后，系统依然能正常提供服务。

CA、CP、AP 三种组合方式，但是在分布式系统的结构下，网络是不可能做到100%可靠的。既然网络不能保证绝对可靠，那 P（分区容错性）就是一个必选项了。原因如下：

如果选择 CA组合，放弃 P（分区容错性）。当发生节点间网络故障时，为了保证 C（一致性），那么就必须将系统锁住，不允许任何写入操作，否者就会出现节点之间数据不一致了。但是锁住了系统，就意味着当有写请求进来的时候，系统是不可用的，这一点又违背了 A（可用性）原则。

比如我们熟知的关系型数据库，如My Sql和Oracle就是保证了可用性和数据一致性，但是他并不是个分布式系统。一旦关系型数据库要考虑主备同步、集群部署等就必须要把P也考虑进来。

其实，在CAP理论中。C，A，P三者并不是平等的，CAP之父在《Spanner，真时，CAP理论》一文中写到：

如果说Spanner真有什么特别之处，那就是谷歌的广域网。Google通过建立私有网络以及强大的网络工程能力来保证P，在多年运营改进的基础上，在生产环境中可以最大程度的减少分区发生，从而实现高可用性。

从Google的经验中可以得到的结论是，无法通过降低CA来提升P。要想提升系统的分区容错性，需要通过提升基础设施的稳定性来保障。

所以，对于一个分布式系统来说。P是一个基本要求，CAP三者中，只能在CA两者之间做权衡，并且要想尽办法提升P。

因此分布式系统理论上是不可能有CA组合的，所以我们只能选择 CP 和 AP组合架构。

CP 架构

由于网络问题，节点A和节点B之前不能互相通讯。当有客户端向节点A进行写入请求时（准备写入Message 2），节点A会不接收写入操作，导致写入失败，这样就保证了节点A和节点B的数据一致性，即保证了Consisteny（一致性）。

然后，如果有另一个客户端向B节点进行读请求的时候，B请求返回的是网络故障之前所保存的信息（Message 1），并且这个信息是与节点A一致的，是整个系统最后一次成功写入的信息，是能正常提供服务的，即保证了Partition tolerance（分区容错性）。

上述情况就是保障了CP架构，但放弃了Availability（可用性）的方案。

AP 架构

由于网络问题，节点A和节点B之前不能互相通讯。当有客户端向节点A进行写入请求时（准备写入Message 2），节点A允许写入，请求操作成功。但此时，由于A和B节点之前无法通讯，所以B节点的数据还是旧的（Message 1）。当有客户端向B节点发起读请求时候，读到的数据是旧数据，与在A节点读到的数据不一致。但由于系统能照常提供服务，所以满足了Availability（可用性）要求。

因此，这种情况下，就是保障了AP架构，但其放弃了 Consisteny（一致性）。

BASE 理论

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。

• BA：（Basically Available ），基本可用。
  基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
  
  电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
• S：（ Soft State），软状态
  软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。
  
  分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
• E：（Eventually Consistent ），最终一致
  最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
  
  弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

ACID是传统数据库常用的设计理念，追求强一致性模型。BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

分布式事务处理 

柔性事务分为

• 两阶段型
• 补偿型
• 异步确保型
• 最大努力通知型

参考：分布式事务解决方案——柔性事务与服务模式

模式分类：异步确保 、重试与幂等 、可补偿操作 

 

两阶段型 

二阶提交协议（Two Phase Commitment Protocol）、三阶提交协议（Three Phase Commitment Protocol）和Paxos 、Raft 算法。

分布式事务两阶段提交，对应技术上的XA、JTA/JTS，这是分布式环境下事务处理的典型模式。

阿里巴巴Fescar 基于XA研发的分布式事务中间件。

XA规范

X/Open 组织（即现在的 Open Group ）定义了分布式事务处理模型。 X/Open DTP 模型（ 1994 ）包括应用程序（ AP ）、事务管理器（ TM ）、资源管理器（ RM ）、通信资源管理器（ CRM ）四部分。

一般，常见的事务管理器（ TM ）是交易中间件，常见的资源管理器（ RM ）是数据库，常见的通信资源管理器（ CRM ）是消息中间件。

 通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。  

所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。     

一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。 

XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。 

二阶提交协议 

二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常，二阶段提交也被称为是一种协议(Protocol))。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

二阶段提交还是有几个缺点的：

1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

三阶提交协议

与两阶段提交不同的是，三阶段提交有两个改动点。

1、引入超时机制。同时在协调者和参与者中都引入超时机制。

2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

补偿型

 TCC型事务（Try/Confirm/Cancel）可以归为补偿型；TCC思路是：尽早释放锁；在Try成功的情况下，如果事务要回滚，Cancel将作为一个补偿机制，回滚Try操作； 
TCC各操作事务本地化，且尽早提交 (放弃两阶段约束)；当全局事务要求回滚时，通过另一个本地事务实现“补偿”行为； 
TCC是将资源层的两阶段提交协议转换到业务层，成为业务模型中的一部分；

Try: 尝试执行业务

完成所有业务检查(一致性) 预留必须业务资源(准隔离性)

Confirm:确认执行业务

真正执行业务 不作任何业务检查 只使用Try阶段预留的业务资源 Confirm操作要满足幂等性

Cancel: 取消执行业务

释放Try阶段预留的业务资源  
Cancel操作要满足幂等性

这种类型和可补偿操作类似，就是提供一种提交和回滚的机制。是一种典型的两阶段类型的操作。这里说的两阶段类型操作并不是指2PC，他和2PC还是有区别的。

TCC与2PC协议比较 
TCC位于业务服务层而非资源层 
TCC没有单独的准备(Prepare)阶段,Try操作兼备资源操作与准备能力 Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度) 
TCC有较高开发成本

异步确保型

将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用

典型例子是热点账户异步记账、批量记账的处理。

最大努力型 

通过通知服务器（消息通知）进行，允许失败，有补偿机制（或重发机制）。

例如商户交易结果通知重试、补单重试。

参考：

RocketMQ 4.3 正式发布，支持分布式事务

微服务架构下分布式事务解决方案——阿里GTS

分布式事务 Seata TCC 模式深度解析