分布式事务（一）理论篇

目录

摘要说明：

一、什么是分布式事务？

二、基础理论

1、ACID

2、CAP定理

3、BASE理论

三、解决方案

1、XA协议:标准分布式事务

2、2PC:两阶段提交(Two Phase Commit)

3、3PC：三阶段提交协议

4、TCC：事务补偿型方案

5、异步确保型（MQ）

6、最大努力通知型

四、主流框架介绍

1、TX-LCN框架

2、Seata框架

摘要说明：

       简单的说事务的本质就是将多个非原子性的操作构造成一个“原子性”的执行单元的机制；即多个原子操作要么全部成功，要么全部失败即回滚；

       但往往一个业务会因为多种原因需要划分成多个这样的节点，通常的原因有

1. 业务划分产生多个节点如微服务；
2. 由于多个数据源产生多个节点；

      简单的说分布式事务需要保证这些小节点要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库或操作的数据一致性。

一、什么是分布式事务？

       事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。

        那什么是分布式事务？

         举个例子，微服务中有两个服务分别是服务A和服务B，若服务A的一个接口a调用服务B的接口B成功后处理自己的逻辑时出现异常，那么服务A回滚本身接口a的业务的同时，如何协调服务B将其接口b的业务回滚；这就是分布式事务；

         分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

二、基础理论

1、ACID

      ACID指的是本地数据库事务的四大特性，其对于解决分布式事务有指导意义：

• A:原子性(Atomicity)

一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

就像你买东西要么交钱收货一起都执行，要么要是发不出货，就退钱。

• C:一致性(Consistency)

事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。

• I:隔离性(Isolation)

指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。

打个比方，你买东西这个事情，是不影响其他人的。

• D:持久性(Durability)

指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

打个比方，你买东西的时候需要记录在账本上，即使老板忘记了那也有据可查。

2、CAP定理

       分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点；同时CAP定理，又被叫作布鲁尔定理     

       CAP(Consistency、Availability、Partition tolerance)分别指的是C (一致性)、A (可用性)、P (分区容错性)；

       一致性（Consistency）：对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致。

       可用性（Consistency）：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是返回40。

       分区容错性 (Partition tolerance)：当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。

        CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。

3、BASE理论

     BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩展

1. 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。

2. 软状态:允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。

3. 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。

       BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

三、解决方案

1、XA协议:标准分布式事务

        XA是由X/Open组织提出的分布式事务的规范。 XA规范主要定义了（全局）事务管理器（TM）和（局部）资源管理器（RM)之间的接口。主流的关系型数据库产品都是实现了XA接口的。

        XA接口是双向的系统接口，在事务管理器（TM）以及一个或多个资源管理器（RM）之间形成通信桥梁。

        XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲两台机器理论上无法达成一致的状态，需要引入一个单点进行协调。

        由全局事务管理器管理和协调的事务，可以跨越多个资源（如数据库或JMS队列）和进程。全局事务管理器一般使用XA二阶段提交协议与数据库进行交互。

        总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。

2、2PC:两阶段提交(Two Phase Commit)

       2PC，将事务的提交过程分为： 准备阶段和提交阶段。 事务的发起者称协调者，事务的执行者称参与者。

       阶段1：准备阶段

1. 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
2. 各参与者执行事务操作，但不提交事务。
3. 如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。

      阶段2：提交阶段

      此阶段分两种情况：

• 所有参与者均反馈YES、或任何一个参与者反馈NO。 所有参与者均反馈YES时，即提交事务。
• 任何一个参与者反馈NO时，即中断事务。

3、3PC：三阶段提交协议

       3PC，三阶段提交协议，是2PC的改进版本， 即将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理。

       阶段1：CanCommit

1. 协调者向参与者发出CanCommit请求，询问是否可以提交事务，并等待所有参与者答复。
2. 参与者收到CanCommit请求后，如果认为可以执行事务操作，则反馈YES，否则反馈NO。

      阶段2：PreCommit

1. 所有参与者均反馈YES，即执行事务预提交。
2. 任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。

      阶段3：do Commit

1. 所有参与者均反馈Ack响应，即执行真正的事务提交。
2. 任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。 

4、TCC：事务补偿型方案

       TCC方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。

        事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口，完成一阶段准备。之后事务协调器会根据try接口返回情况，决定调用confirm接口或者cancel接口。如果接口调用失败，会进行重试。

       TCC方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。 当然TCC方案也有不足之处，集中表现在以下两个方面：

• 对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
• 实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等。

       上述原因导致TCC方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署，而TCC方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大。

5、异步确保型（MQ）

       异步确保型是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。

       本方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高。

6、最大努力通知型

       此方案是业务处理后，向被动方发送通知消息（允许消息丢失） ；

       主动发可以设置时间梯度通知规则，在通知失败后按照规则重复通知，直到通知N次后不再通知；

       主动方提供查询接口供校对查询，如： 收款通知、注册通知等等；

       使用范围一般是：对业务最终一致性的时间敏感度低，跨企业的业务活动。如（支付宝/微信/12306，付款后页面自动跳转）；

       特点：业务活动的主动方在完成业务处理之后，向业务活动的被动方发送通知消息。主动方可以设置时间阶梯通知规则，在通知失败后按规则重复通知，知道通知N次后不再通知。主动方提供校对查询接口给被动方按需校对查询，用户恢复丢失的业务消息。

四、主流框架介绍

1、TX-LCN框架

       LCN框架在2017年6月份发布第一个版本，从开始的1.0，已经发展到了5.0版本。
       LCN名称是由早期版本的LCN框架命名，在设计框架之初的1.0 ~ 2.0的版本时框架设计的步骤是如下,各取其首字母得来的LCN命名。

• 锁定事务单元（lock）
• 确认事务模块状态(confirm)
• 通知事务(notify)

      5.0以后由于框架兼容了LCN、TCC、TXC三种事务模式，为了避免区分LCN模式，特此将LCN分布式事务改名为TX-LCN分布式事务框架。

       TX-LCN定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。

事务控制原理：

    TX-LCN由两大模块组成, TxClient、TxManager，TxClient作为模块的依赖框架，提供TX-LCN的标准支持，TxManager作为分布式事务的控制放。事务发起方或者参与反都由TxClient端来控制。

原理图:

核心步骤：

• 创建事务组
  是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。

• 加入事务组
  添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。

• 通知事务组
  是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。

更多可参考：http://www.txlcn.org/zh-cn/

2、Seata框架

       Seata：简单的可扩展的自主事务架构，一个分布式事务的解决方案具有高性能和易用性的微服务架构。

       Seata有3个基本组成部分：

• 事务协调器（TC）：维护全局事务和分支事务的状态，驱动全局提交或回滚。
• 事务管理器TM：定义全局事务的范围：开始全局事务，提交或回滚全局事务。
• 资源管理器（RM）：管理正在处理的分支事务的资源，与TC对话以注册分支事务并报告分支事务的状态，并驱动分支事务的提交或回滚。

Seata管理的分布式事务的典型生命周期：

1. TM要求TC开始一项新的全球交易。TC生成代表全局交易的XID。
2. XID通过微服务的调用链传播。
3. RM将本地事务注册为XID到TC的相应全局事务的分支。
4. TM要求TC提交或回退相应的XID全局事务。
5. TC驱动XID的相应全局事务下的所有分支事务以完成分支提交或回滚。

历史：

蚂蚁金融

• XTS：扩展事务服务。自2007年以来，Ant Financial中间件团队就开发了分布式事务中间件，该中间件在Ant Financial中得到了广泛使用，解决了跨数据库和服务的数据一致性问题。

• DTX：分布式事务扩展。自2013年以来，XTS以DTX的名称发布在Ant Financial Cloud上。

阿里巴巴

• TXC：淘宝交易构造函数。阿里巴巴中间件团队自2014年开始启动该项目，以解决由于应用程序架构从单片式服务向微服务式转换而引起的分布式事务问题。
• GTS：全球交易服务。自2016年以来，TXC作为新名称GTS的Aliyun中间件产品发布。
• Fescar：自2019年以来，我们开始基于TXC / GTS的开源项目Fescar，以在将来与社区紧密合作。

西塔社区

• Seata：简单的可扩展自治事务架构。蚂蚁金服加入了Fescar，使它成为一个更加中立和开放的分布式交易社区，并将Fescar更名为Seata。

 由于其由阿里巴巴实践加持，目前热度很高；

 更多可参考：https://github.com/seata/seata