关于分布式事务实现原理（Seata篇）

分布式事务

1.浅谈分布式事务

        当一个服务需要调用其他服务时，所有服务都调用成功而其中mou'xi服务因为某些原因失败导致整体数据出现异常，比如如下，扣钱成功了，但是没用减库存。因此为了保证服务整体的ACID就引入了分布式事务

1.2.分布式事务基本定理

2.1.CAP定理

• Consistency（一致性）
• Availability（可用性）
• Partition tolerance （分区容错性）

2.1.1.一致性

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据一致，这种称为强一致

2.1.2.可用性

Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。

当有部分节点因为某些原因无法访问时，代表节点不可用

2.1.3.分区容错

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

2.1.4.矛盾

当节点某些节点因为未知原因产生分区时，

如果此时要保证强一致性，就必须关闭对分区的访问，势必会影响可用性

如果此时要保证可用性，就会访问不一致的数据，影响数据一致性

也就是说，一致性和可用性只能保证一个

2.2.BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

• Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

2.3.解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，有两种解决思路：

• AP模式：各子事务分别执行和提交，允许出现结果不一致，然后通过业务补偿实现最终一致。可能会带来一致性问题

• CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个全局事务协调者(TC)：

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

2.关于Seata的基本模型

2.1.Seata的架构

Seata事务管理中有三个重要的角色：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

• TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

• RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

整体的架构模型：

简述Seata实现分布式事务的基本模型（并非最终实现）：

       首先，全局事务会有一个入口方法，TM会监控入口方法，监控入口方法便会得知该业务调用多少服务，每个微服务视为一个分支事务，当入口方法被调用，TM会拦截该方法，并向TC发起请求注册全局事务，然后开始执行方法，每调用一个微服务都会被该服务的RM拦截并向TC注册当前分支事务，然后执行分支事务业务逻辑，每个RM执行完业务逻辑都不提交事务但会向TC报告当前业务状态，当有一个分支事务异常，TC会通知TM回滚全局事务，并由RM回滚分支事务。

Seata基于上述架构提供了四种不同的分布式事务解决方案：

• XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
• TCC模式：最终一致的分阶段事务模式，有业务侵入
• AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
• SAGA模式：长事务模式，有业务侵入4.动手实践

2.2.XA模式

2.2.1.两阶段提交

XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

正常情况：

异常情况：

一阶段：

事务协调者通知每个RM执行本地事务但不提交，随后先向告知事务协调者结果

二阶段：

事务协调者基于一阶段的报告来判断下一步操作，如果一阶段都成功，则通知所有事务参与者，提交事务，如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

XA模式是基于数据库本身的事务特性来实现分布式事务，属于强一致性，

2.2.2.Seata的XA模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

一阶段的工作：

​ ① TM注册分支事务到TC，然后执行业务调用分支

​ ② RM代理注册事务，由数据库本身的事务执行分支业务sql但不提交

​ ③ 报告执行状态到TC

二阶段的工作：

• TC检测各分支事务执行状态决定全部提交或回滚

2.2.3.优缺点

XA模式的优点是什么？

• 事务的强一致性，满足ACID原则。
• 常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

• 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
• 依赖关系型数据库实现事务

2.3.AT模式

AT模式同样是分阶段提交的事务模型，针对并解决XA模型中资源锁定周期过长的缺陷。

2.3.1.Seata的AT模型

基本流程图：

阶段一：

• 注册全局事务，注册分支事务
• 执行业务sql并提交，并由RM记录数据提交前后状态的快照
• 报告事务状态

阶段二：

• TC检查分支事务状态，如果成功则删除快照，失败则根据快照恢复数据

阶段二回滚时RM的工作：

流程图：
2.3.3.脏写问题

在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题，如图：

由于分支事务是直接提交的数据库锁会得到释放，因此当多个事务对同一数据进行更改后，有一个事务所属的全局事务进行回滚后，会根据快照恢复导致数据错误

如图，事务一先于二对同一数据进行修改，事务一回滚后导致数据恢复修改前，使用事务二的修改如同虚设。

解决思路就是引入了全局锁的概念，避免同一时刻有另外一个事务来操作当前数据：

事务一拿到全局锁，在服务执行并提交事务后释放DB锁，此时其他线程来修改该表的数据，无法获得全局锁导致无法修改表。

注意：这种逻辑可能会引发新的问题（如上图），事务一拥有全局锁进行回滚的时候等待DB锁，而事务二则准备改表持着DB锁等待全局锁，这是会导致一个死锁问题，对此Saeata对全局锁获取设置了限制，重试获取最多30次，每次间隔10ms，超过时间则回滚事务并释放DB锁

AT模式的优点：

• 一阶段完成直接提交事务，释放数据库资源，性能比较好
• 利用全局锁实现读写隔离
• 没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

• 两阶段之间属于软状态，属于最终一致
• 框架的快照功能会影响性能，但比XA模式要好很多

2.3.2.Seata的TCC模型

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

• Try：资源的检测和预留；

• Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。

• Cancel：预留资源释放，可以理解为try的反向操作。

2.3.3.流程分析

举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。可用余额和冻结金额分表存储

• 阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30

初始余额：

余额充足，可以冻结：

此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。

• 阶段二（Confirm)：假如要提交（Confirm），则冻结金额扣减30

确认可以提交，不过之前可用金额已经扣减过了，这里只要清除冻结金额就好了：

此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元

• 阶段二(Canncel)：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30

需要回滚，那么就要释放冻结金额，恢复可用金额。

Seata中的TCC模型依然延续之前的事务架构，如图：

阶段一：注册全局事务，注册分支事务，进行资源预留（Try），提交并报告资源状态

阶段二：进行资源判断，并根据判断提交（Confirm）或回滚（Cancel）

2.3.4.优缺点

TCC的优点是什么？

• 一阶段完成直接提交事务，释放数据库资源，性能好
• 相比AT模型，无需生成快照，无需使用全局锁，性能最强
• 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

TCC的缺点是什么？

• 有代码侵入，需要人为编写try、Confirm和Cancel接口，很费程序员
• 软状态，事务是最终一致
• 需要考虑Confirm和Cancel的失败情况，做好幂等处理

2.3.5.事务悬挂和空回滚

1）空回滚（如图）：

当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。而后续的分支事务未执行try操作，对于这部分支事务不能回滚（Cancel），就是空回滚。执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。

2）业务悬挂

对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。

执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂

2.4.SAGA模式

该模式由于使用场景复杂，用于事务跨度较大的业务，或者十分复杂的业务，不做深入研究

2.4.1.原理

在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

Saga也分为两个阶段：

• 一阶段：直接提交本地事务
• 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

2.4.2.优缺点

优点：

• 事务参与者可以基于事件驱动实现异步调用，吞吐高
• 一阶段直接提交事务，无锁，性能好
• 不用编写TCC中的三个阶段，实现简单

缺点：

• 软状态持续时间不确定，时效性差
• 没有锁，没有事务隔离，会有脏写

2.5.四种模式对比

我们从以下几个方面来对比四种实现：

• 一致性：能否保证事务的一致性？强一致还是最终一致？
• 隔离性：事务之间的隔离性如何？
• 代码侵入：是否需要对业务代码改造？
• 性能：有无性能损耗？
• 场景：常见的业务场景

3.高可用

Seata的TC服务作为分布式事务核心，一定要保证集群的高可用性。

3.1.高可用架构模型

搭建TC服务集群非常简单，启动多个TC服务，注册到nacos即可。