分布式事务管理详解：DTP模型，2PC协议实现，TCC模式和SAGA模式实现原理

单体架构下的事务管理

在开发单体服务系统的时候，我们的业务系统通常是使用关系型数据库来进行数据存储的，如果一个业务操作需要对同一个数据源进行多次操作，其数据的一致性是由数据库的事务机制来保证的。而这些事务的机制一般都是依赖于ACID理论来做的。

ACID理论

• Atomicity - 原子性

  一个事务中的一系列操作要么全部成功，要么全部不成功。即：一个事务视为一个整体，在该事务中任何失败的操作都要视整个事务是无效的，不提交该事务

• Consistency - 一致性

  事务的执行不应该破坏数据的完整性和一致性，在事务的执行前和执行后数据库都应该保持一致性的状态。

• Isolation - 隔离性

  事务的隔离性是指在并发环境中，并发的事务时相互隔离的，一个事务的执行不能不被其他事务干扰。不同的事务并发操作相同的数据时，每个事务都有各自完成的数据空间，即一个事务内部的操作及使用的数据对其他并发事务时隔离的，并发执行的各个事务之间不能相互干扰

• Durability - 持久性

  事务提交后，其对数据库数据的变更应该是持久的，一旦事务提交后，持久化的数据不会被服务宕机等问题所影响，重启后依旧能看到完整的持久化的数据。

分布式架构下的事务管理

如果一个业务操作涉及对多个数据源来进行操作，那么使用原来单一数据库事务（本地数据）来控制就不能满足（全局事务）数据的一致性要求。
分布式事务是为了解决微服务架构（形式都是分布式系统）中不同节点之间的数据一致性问题。这个一致性问题本质上解决的也是传统事务需要解决的问题，即一个请求在多个微服务调用链中，所有服务的数据处理要么全部成功，要么全部回滚。当然分布式事务问题的形式可能与传统事务会有比较大的差异，但是问题本质是一致的，都是要求解决数据的一致性问题。

DTP（Distributed Transaction Processing）模型

X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 组织定义的一套分布式事务的标准，用来规范全局事务处理。如图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3iiRGfa3-1589967827651)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20200520151821982.png)]

它定义了几个组件：

• AP（Application Program 应用程序 ）

  即需要使用分布式事务的应用程序

• RM（Resource Manager 资源管理器）

  比如数据库或文件系统，提供对共享资源的访问，保障资源的ACID特性。

• TM（Transaction Manager 事务管理器）

  主要是给事务分配唯一标识，负责事务的启动、提交及回滚，保障全局事务的原子性

• CRMs（Communication Resource Managers 通信资源管理器）

  负责控制分布式应用在同一个（TM domain）事务管理器之内或跨TM domain的之间的通信，该通信使用的是OSI TP（Open Systems Interconnection Distributed Transaction Processing）服务，早期DTP规范内并没有剔除CRM组件的概念，这是在后面的版本规范中提出的

• 通信协议

  即由通信资源管理器支持，在分布式应用程序使用的通信协议

两阶段提交 2PC协议

1. 第一阶段：CanCommit阶段

   在第一阶段，事务管理器TM请求所有的资源管理器RM预提交各自的事务分支。资源管理器RM如果能够执行提交操作，返回成功，则它会记录相关的日志。如果资源管理器不能提交事务，则返回失败，同时回滚已经处理的操作，并释放相应的资源

2. 第二阶段：PreCommit阶段

   在第二阶段，事务管理器TM向所有的资源管理器RM发送提交或回滚事务分支的请求，如果第一阶段所有资源管理器RM返回的都是成功，则发送提交事务的请求。如果第一阶段只要有一个资源管理器RM返回的是失败，就发送回滚事务请求，在所有资源管理器RM对共享资源提交事务或回滚变更之后，反馈执行结果给事务管理器，然后事务管理器TM释放占用的所有的相关资源

采用二段提交2PC协议优点就是简单，但是它也有几个缺点，分别如下：

• 两个阶段的所有操作都是同步阻塞的，需要等待各个参与者的响应。这会影响分布式应用的操作性能
• 事务管理器TM在整个流程中负责操作协调管理，如果TM自身发生故障，则接下来的RM资源管理器就会一直处于阻塞状态，事务无法执行下去。从而长时间的占用资源
• 如果在第二阶段有部分资源管理器RM接收到了提交事务的请求后提交了事务，而一部分资源管理器RM因为网络的原因未能收到提交事务的请求。那么此时就会造成数据的不一致

XA接口与JTA

XA接口是DTP在2PC的基础上给事务管理器TM和资源管理器RM之间通信定义的接口。在JAVA领域 J2EE定义了JTA（Java Transaction API）规范，它遵循DTP XA接口，是高级版本的API规范，另外还有JTS（Java Transaction Service）规范，其定义了更底层实现事务管理器TM的相关接口

CAP与BASE定理

1. CAP

   CAP与ACID虽然名字里都有一个C但是其一致性的含义不太一样，ACID的C主要关注数据在跨节点的操作下操作原子性。而CAP的C关注的主要是同一份数据在多个副本之间同步的一致性

2. BASE

   BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）

分布式事务：TCC模式

严格遵守ACID的分布式事务我们称为刚性事务，而遵循BASE理论（基本可用：在故障出现时保证核心功能可用，软状态：允许中间状态出现，最终一致性：不要求分布式事务打成中时间点数据都是一致性的，但是保证达到某个时间点后，数据就处于了一致性了）的事务我们称为柔性事务，其中TCC编程模式就属于柔性事务
其基本定义如下：

• 初步操作（Tentative Operation） ：为了在多个实体之间达成一致，要求一个实体必须能够接受另外一个实体对请求执行的不确定性，比如在发出执行请求之后又发出取消该操作的请求
• 确认执行（Confirmation）：如果请求方认为初步操作没问题，那么就可发出确认的执行请求，最终确定这个操作
• 取消执行（Cancellation）：如果请求方决定撤回这个操作，那么就发出取消的请求，结束这个操作

TCC编程模型本质上也是另外一种二段2PC协议的实现

TCC模式把一个分布式事务操作分为Initial、Reserved、Final三个状态

• Initial：为最初始的状态、接到Try请求后变为Reserved状态。
• Reserved：接收确认请求（Confirmation）后变为Final状态，如果接收Cancellation请求或者是等待超时回退为Initial状态
• Final：TCC事务成功状态

TCC的缺点

• TCC是不满足Isolation （隔离性）的，即TCC是采用预留资源来做try以及取消操作的，那么在达到Final之前，其他事务如果读取处于中间状态的资源时，读到的是“脏”数据。
• 另外TCC要求confirm、cancel操作必须是幂等的，因为实际场景会因为网络场景或其他问题导致这些操作被重试。因此TCC实现的是最终一致性

分布式事务：SAGA模式

​ 1987年普林斯顿大学的Hector Garcaa-Molrna与Kenneth Salem发表了-篇名为《SAGAS》的论文，提出了sAGA的事务模式。它涉及一个概念一-LLT (Long Lived Transaction)。LLT指的是持有数据库资源相对较长的长活事务。如果个LLT可以被拆解为一序列可以跟其他事务错开执行(interleaved with)的子事务，而且里面的每个子事务保持自身ACID特性，要么可以成功提交，要么可以通过补偿事务(compensating transaction)来进行恢复，从而达到最终一致性，那么这个LLT就可称为SAGA。

​ 该论文同时还定义了两种恢复方式，一种是正向恢复Forward Recovery,一种是逆向恢复Backward Recovery。每一个内部事务T都有一个对应的补偿事务C,补偿事务C用于逆向恢复已提交的事务T,来使数据恢复到T事务执行之前的状态。逆向恢复的示例过程为T1T2T3C3C2C1,即对每个已经提交的事务T,按照后提交先补偿的顺序依次执行补偿事务C。正向恢复则不同，它则是充分利用保存点sp ( save points), 在sp的基础上不断重试，使得整个大事务不断往前执行下去，其过程示例为TI (sp) T2 (sp)T3 (sp) T4。当然正向恢复并不适用于所有的场景。

Distributed Saga对正常请求及补偿请求有如下几点要求:

• 正常请求以及补偿请求都必须是幂等的。

• 补偿请求是commutative的，commutative在这里的意思是:如果一-个正常请求在补偿请求之后到达，那么正常请求不应该被执行。

• 正常请求可以被中断(触发补偿请求),但是补偿请求必须执行完成，没有中断操作。

SAGA与2PC

与2PC相比，SAGA与TCC通过牺牲ACID的部分特性来提升分布式事务的可用性。另外SAGA及TCC可以理解为是服务层面的事务模式，将分布式事务的控制由数据库事务层提升到服务层。

SAGA与TCC

SAGA与TCC最显著的区别在于TCC采用的是预留资源的方式，其状态里有个Reserved状态;而SAGA则没有这个预留资源的动作，事务直接提交，然后采取的是补偿事务的方式来进行撤回。与2PC相比，2PC采用事务prepare以及rollback动作，整个都在一个大事务中，而SAGA是将这些大事务拆分为个个本地事务。

SAGA与ACID

SAGA模式不满足Isolation 的特性，因为其将LLT划分为一个个本地事务，一旦本地事务提交，在整个SAGA执行完毕之前，中间如果有其他事务也访问到了共享资源，则会读到“未完成”的事务的数据。与TCC类似，SAGA不满足C特性，SAGA 实现的是最终-致性，但是拆分出来的一个个本地事务则满足ACID特性。

参考

书籍：《重新定义SpringCloud实战》
Blog：
分布式事务：深入理解什么是2PC、3PC及TCC协议
X/Open DTP——分布式事务模型