分布式事务原理

XA协议

ACID特性：

• 原子性（Atomicity）∶事务必须是原子工作单元，不可继续分割，要么全部成功，要么全部失败。
• 一致性（Consistengy）∶事务完成时，所有的数据都必须保持一致。
• 隔离性（Isolation）∶由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。
• 持久性（Durability）∶事务执行完成之后，它对于系统的影响是永久性的。

此特性是针对单库夺标事务所要满足的特性，在分布式事务下不能保证。

X/OPEN 这个组织定义了一套分布式事务标准。这个标准提出了两阶段提交（2PC），来保证分布式事务的完整性。 X/OPEN 包含了以下三种角色：

• AP ∶ Application ，表示应用程序。
• RM∶ Resource Manager，表示资源管理器，比如数据库。
• TM∶Transaction Manager，表示事务管理器，一般指事务协调者，负责协调和管理事务，提供AP编程接口或管理RM。可以理解为Spring中提供的Transaction Manager。

 

大致实现步骤：

1. 配置TM，把多个RM注册到TM，相当于TM注册RM作为数据源。
2. AP从TM管理的RM中获取连接，如果RM是数据库则获取JDBC连接。
3. AP向TM发起一个全局事务，生成全局事务ID（XID），XID会通知各个RM。
4. AP通过第二步获得的连接直接操作RM完成数据操作。这时，AP在每次操作时会把XID传递给RM。
5. AP结束全局事务，TM会通知各个RM全局事务结束。
6. 根据各个RM的事务执行结果，执行提交或者回滚操作。

需要注意的是，TM和多个RM之间的事务控制，是基于XA协议（XA Specification）来完成的。XA协议是X/Open提出的分布式事务处理规范，也是分布式事务处理的工业标准，它定义了xa_和ax系列的函数原型及功能描述、约束等。目前Oracde、MySQL、DB2都实现了XA接口，所以它们都可以作为RM。

两阶段提交协议

• 准备阶段∶事务管理器（TM）通知资源管理器（RM）准备分支事务，记录事务日志，并告知事务管理器的准备结果。
• 提交/回滚阶段∶如果所有的资源管理器（RM）在准备阶段都明确返回成功，则事务管理器（TM）向所有的资源管理器（RM）发起事务提交指令完成数据的变更。反之，如果任何一个资源管理器（RM）明确返回失败，则事务管理器（TM）会向所有资源管理器（RM）发送事务回滚指令。

 

两阶段提交存在以下缺点：

• 同步阻塞∶所有参与者（RM）都是事务阻塞型的，对于任何一次指令都必须要有明确的响应才能继续进行下一步，否则会处于阻塞状态，占用的资源一直被锁定。
• 过于保守∶ 任何一个节点失败都会导致数据回滚。
• 事务协调者的单点故障∶如果协调者在第二阶段出现了故障，那么其他的参与者（RM）会一直处于锁定状态。
• "脑裂"导致数据不一致问题∶在第二阶段中，事务协调者向所有参与者（RM）发送commit请求后，发生局部网络异常导致只有一部分参与者（RM）接收到了commit请求，这部分参与者（RM）收到请求后会执行commit操作，但是未收到commit请求的节点由于事务无法是交，导致数据出现不一致问题。

 三阶段提交协议

• CanCommit（询问阶段）∶事务协调者向参与者发送事务执行请求，询问是否可以完成指令，参与者只需要回答是或者不是即可，不需要做真正的事务操作，这个阶段会有超时中止机制。
• PreCommit（准备阶段）∶事务协调者会根据参与者的反馈结果决定是否继续执行，如果在询问阶段所有参与者都返回可以执行操作，则事务协调者会向所有参与者发送PreCommit请求，参与者收到请求后写redo和undo日志，执行事务操作但是不提交事务，然后返回ACK响应等待事务协调者的下一步通知。如果在询问阶段任意参与者返回不能执行操作的结果，那么事务协调者会向所有参与者发送事务中断请求。
• DoCommit（提交或回滚阶段）;这个阶段也会存在两种结果，仍然根据上一步骤的执行结果来决定DoCommit的执行方式。如果每个参与者在PreCommit阶段都返回成功，那么事务协调者会向所有参与者发起事务提交指令。反之，如果参与者中的任一参与者返回失败，那么事务协调者就会发起中止指令来回滚事务。

三阶段提交协议和两阶段提交协议相比有一些不同点 ∶

• 增加了一个CanCommit阶段，用于询问所有参与者是否可以执行事务操作并且响应，它的好处是，可以尽早发现无法执行操作而中止后续的行为。
• 在准备阶段之后，事务协调者和参与者都引入了超时机制，一旦超时，事务协调者和参与者会继续提交事务，并且认为处于成功状态，因为在这种情况下事务默认为成功的可能性比较大。

实际上，一旦超时，在三阶段提交协议下仍然可能出现数据不一致的情况，当然概率是比较小的。另外，最大的好处就是基于超时机制来避免资源的永久锁定。需要注意的是，不管是两阶段提交协议还是三阶段提交协议，都是数据一致性解决方案的实现，我们可以在实际应用中灵活调整。比如ZooKeeper集群中的数据一致性，就用到了优化版的两阶段提交协议，优化的地方在于，它不需要所有参与者在第一阶段返回成功才能提交事务，而是利用少数服从多数的投票机制来完成数据的提交或者回滚。

 

CAP 

 前面提到的两阶段提交和三阶段提交是XA协议解决分布式数据一致性问题的基本原理，但是这两种方案为了保证数据的强一致性，降低了可用性。实际上这里涉及分布式事务的两个理论模型。

CAP定理，又叫布鲁尔定理。简单来说它是指在分布式系统中不可能同时满足一致性（C∶Consistency）、可用性（A∶Availability）、分区容错性（P∶Partition Tolerance）这三个基本需求，最多同时满足两个。

• C∶ 数据在多个副本中要保持强一致，比如前面说的分布式数据一致性问题。
• A∶系统对外提供的服务必须一直处于可用状态，在任何故障下，客户端都能在合理的时间内获得服务端的非错误响应。
• P∶在分布式系统中遇到任何网络分区故障 ，系统仍然能够正常对外提供服务。

在分布式系统中，要么满足CP，要么满足AP，不可能实现CAP或CA。

CA或者CAP，相当于网络百分之百可靠。

• AP∶对于AP来说，相当于放弃了强一致性，实现最终的一致，这是很多互联网公司解决分布式数据一致性问题的主要选择。
• CP∶放弃了高可用性，实现强一致性。前面提到的两阶段提交和三阶段提交都采用这种方案。可能导致的问题是用户完成一个操作会等待较长的时间。

 BASE理论

BASE理论是由于CAP中一致性和可用性不可兼得而衍生出来的一种新的思想，BASE理论的核心思想是通过牺牲数据的强一致性来获得高可用性。它有如下三个特性。

• ·Basicly Available（基本可用）∶分布式系统在出现故障时，允许损失一部分功能的可用性，保证核心功能的可用。
• ·Soft State（软状态）;允许系统中的数据存在中间状态，这个状态不影响系统的可用性，也就是允许系统中不同节点的数据副本之间的同步存在延时。
• ·Eventually Consistent（最终一致性）;中间状态的数据在经过一段时间之后，会达到一个最终的数据一致性。

BASE理论并没有要求数据的强一致，而是允许数据在一段时间内是不一致的，但是数据最终会在某个时间点实现一致。在互联网产品中，大部分都会采用BASE理论来实现数据的一致，因为产品的可用性对于用户来说更加重要。

举个例子，在电商平台中用户发起一个订单的支付，不需要同步等待支付的执行结果，系统会返回一个支付处理中的状态到用户界面。对于用户来说，他可以从订单列表中看到支付的处理结果。而对于系统来说，当第三方的支付处理成功之后，再更新该订单的支付状态即可。在这个场景中，虽然订单的支付状态和第三方的支付状态存在短期的不一致，但是用户却获得了更好的产品体验。