分布式事务解决方案

面试中经常被问到分布式事务的解决方案，今天特地进行一个整理。
随着业务的快速发展、业务复杂度越来越高，几乎每个公司的系统都会从单体走向分布式，特别是转向微服务架构，随之而来就必然遇到分布式事务这个难题。
严格意义上的事务实现应该是具备原子性、一致性、隔离性和持久性，简称 ACID。
原子性（Atomicity），可以理解为一个事务内的所有操作要么都执行，要么都不执行。
一致性（Consistency），可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是300，不会存在我账上钱加了，你账上钱没扣的中间状态。
隔离性（Isolation），指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。
持久性（Durability），指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。

以商品流水账单为例，我们拆分为商品购买系统，订单系统，支付系统。

用户看中一件商品，点击购买。

商品购买系统响应用户的点击，向订单系统插入一条订单信息。

跳转到支付系统完成支付。

在用户整个购买商品的过程中，我们需要保证事件1，2，3在没有异常的情况下全部执行成功，一旦某个系统抛出异常，都需要回滚。

那么，如何保证各个子系统的操作具有一致性呢？这就是我们下面提到的分布式事务的解决方案。

解决方案

1. 两阶段提交
   基于两阶段提交协议两阶段提交协议概述
   该方案基于两阶段提交协议，因此也叫做两阶段提交方案。在该分布式系统中，其中 需要一个系统担任协调器的角色，其他系统担任参与者的角色。主要分为Commit-request阶段和Commit阶段
   

请求阶段：首先协调器会向所有的参与者发送准备提交或者取消提交的请求，然后会收集参与者的决策。

提交阶段：协调者会收集所有参与者的决策信息，当且仅当所有的参与者向协调器发送确认消息时协调器才会提交请求，否则执行回滚或者取消请求。

   该方案的缺陷：

同步阻塞：所有的参与者都是事务同步阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
单点故障：一旦协调器发生故障，系统不可用。
数据不一致：当协调器发送commit之后，有的参与者收到commit消息，事务执行成功，有的没有收到，处于阻塞状态，这段时间会产生数据不一致性。
不确定性：当协调器发送commit之后，并且此时只有一个参与者收到了commit，那么当该参与者与协调器同时宕机之后，重新选举的协调器无法确定该条消息是否提交成功。

2. TCC方案
   tcc方案全称是： try–confirm–cancel
   TCC方案分为Try Confirm Cancel三个阶段，属于补偿性分布式事务。

Try：尝试待执行的业务
这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源
Confirm：执行业务
这个过程真正开始执行业务，由于Try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。
Cancel：取消执行的业务
若业务执行失败，则进入Cancel阶段，它会释放所有占用的业务资源，并回滚Confirm阶段执行的操作。

TCC方案适用于一致性要求极高的系统中，比如金钱交易相关的系统中，不过可以看出，其基于补偿的原理，因此，需要编写大量的补偿事务的代码，比较冗余。不过现有开源的TCC框架，比如TCC-transaction

3. 本地消息表
   本地消息表顾名思义就是会有一张存放本地消息的表，一般都是放在数据库中，然后在执行业务的时候 将业务的执行和将消息放入消息表中的操作放在同一个事务中，这样就能保证消息放入本地表中业务肯定是执行成功的。流程如下：
   

然后再去调用下一个操作，如果下一个操作调用成功了好说，消息表的消息状态可以直接改成已成功。

如果调用失败也没事，会有 后台任务定时去读取本地消息表，筛选出还未成功的消息再调用对应的服务，服务更新成功了再变更消息的状态。

这时候有可能消息对应的操作不成功，因此也需要重试，重试就得保证对应服务的方法是幂等的，而且一般重试会有最大次数，超过最大次数可以记录下报警让人工处理。

可以看到本地消息表其实实现的是最终一致性，容忍了数据暂时不一致的情况。本地消息表方案需要写入消息表中，如果在高并发的场景下会进行大量的磁盘IO，因此该方案不适用于高并发场景

4. 消息事物

   消息事务的原理是将两个事务通过消息中间件进行异步解耦，和上述的本地消息表有点类似，但是是通过消息中间件的机制去做的，其本质就是“将本地消息表封装到了消息中间件中”。

执行流程：

发送 prepare 消息到消息中间件。
发送成功后，执行本地事务。
如果事务执行成功，则 commit，消息中间件将消息下发至消费端。如果事务执行失败，则回滚，消息中间件将这条 prepare 消息删除。
消费端接收到消息进行消费，如果消费失败，则不断重试。
这种方案也是实现了最终一致性，对比本地消息表实现方案，不需要再建消息表，不再依赖本地数据库事务了，所以这种方案更适用于高并发的场景。目前市面上实现该方案的只有阿里的RocketMQ

5. 最大努力通知
   最大努力通知的方案实现比较简单，适用于一些最终一致性要求较低的业务。
   执行流程：
   系统 A 本地事务执行完之后，发送个消息到 MQ。
   这里会有个专门消费 MQ 的服务，该服务会消费 MQ 并调用系统 B 的接口。
   要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B，反复 N 次，最后还是不行就放弃。

6. Sagas 事务模型长时间运行的事务
   其核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。Seata 框架中一个分布式事务包含三种角色：

「Transaction Coordinator (TC)」：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。「Transaction Manager ™」：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。「Resource Manager (RM)」：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

seata框架**「为每一个RM维护了一张UNDO_LOG表」**，其中保存了每一次本地事务的回滚数据。

具体流程：

首先 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。

XID 在微服务调用链路的上下文中传播。

RM 开始执行这个分支事务，RM 首先解析这条 SQL 语句，生成对应的 UNDO_LOG 记录。下面是一条 UNDO_LOG 中的记录，UNDO_LOG 表中记录了分支 ID，全局事务 ID，以及事务执行的 redo 和 undo 数据以供二阶段恢复。

RM 在同一个本地事务中执行业务 SQL 和 UNDO_LOG 数据的插入。在提交这个本地事务前，RM 会向 TC 申请关于这条记录的全局锁 。

如果申请不到，则说明有其他事务也在对这条记录进行操作，因此它会在一段时间内重试，重试失败则回滚本地事务，并向 TC 汇报本地事务执行失败。

RM 在事务提交前，申请到了相关记录的全局锁，然后直接提交本地事务，并向 TC 汇报本地事务执行成功 。此时全局锁并没有释放，全局锁的释放取决于二阶段是提交命令还是回滚命令。

TC 根据所有的分支事务执行结果，向 RM 下发提交或回滚 命令。

RM如果 收到 TC 的提交命令 ，首先 立即释放 相关记录的全局 锁 ，然后把提交请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。异步队列中的提交请求真正执行时，只是删除相应 UNDO LOG 记录而已。

RM如果 收到 TC 的回滚命令 ，则会开启一个本地事务，通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。将 UNDO LOG 中的后镜与当前数据进行比较，

如果不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理。

如果相同，根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句并执行，然后提交本地事务达到回滚的目的，最后释放相关记录的全局锁

如果读者想要进一步研究SAGA，go语言可参考DTM，java语言可参考seata