分布式事务常规解决方案

这里提供4种分布式事务解决方案，其中两种我确实用到过，也给大家简略讲一下我的场景和方案

1.两阶段提交方案/XA方案

两阶段提交方案/XA方案一班使用于有一个系统操作多个数据源的情况。

两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复ok，那么就正式提交事务，在各个数据库上执行操作；如果任何一个数据库回答不ok，那么就回滚事务。

这种分布式事务方案，比较适合单应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发`的场景。通常直接基于spring + JTA就可以搞定，demo可以看https://blog.csdn.net/peterwanghao/article/details/100076076。

这个方案很少用，因为目前项目都是微服务的，我们只能操作自己的数据库，不允许交叉访问别的库，如果一定访问别的库，必须通过接口访问来实现。

2.TCC方案

TCC的全程是：Try、Confirm、Cancel。

这个其实是用到了补偿的概念，分为了三个阶段：

1）Try阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留 2）Confirm阶段：这个阶段说的是在各个服务中执行实际的操作 3）Cancel阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作

给大家举个例子吧，比如说跨银行转账的时候，要涉及到两个银行的分布式事务，如果用TCC方案来实现，思路是这样的：

1）Try阶段：先把两个银行账户中的资金给它冻结住就不让操作了 2）Confirm阶段：执行实际的转账操作，A银行账户的资金扣减，B银行账户的资金增加

3）Cancel阶段：如果任何一个银行的操作执行失败，那么就需要回滚进行补偿，就是比如A银行账户如果已经扣减了，但是B银行账户资金增加失败了，那么就得把A银行账户资金给加回去

这种方案说实话几乎很少用人使用，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常之恶心。

比较适合的场景：这个就是除非你是真的一致性要求太高，是你系统中核心之核心的场景，比如常见的就是资金类的场景，那你可以用TCC方案了，自己编写大量的业务逻辑，自己判断一个事务中的各个环节是否ok，不ok就执行补偿/回滚代码。

但是说实话，一般尽量别这么搞，自己手写回滚逻辑，或者是补偿逻辑，实在太恶心了，那个业务代码很难维护。

写到这里我想起来我们项目里，我用到了一个比较标准的TCC事务，之前也没注意，就想着保证一致性，现在回想起来才发现这是TCC事务。 我们那个业务是要向微信那边申请创建模板

• 1.开启spring事务，用于保证数据库的回滚
• 2.进行接口信息校验（相当于try）
• 3.进行数据库插入，保存自己申请的模板信息（相当于confirm）
• 4.调用微信接口（相当于第三方服务），申请模板信息（相当于confirm）
• 5.记录申请成功的微信模板id
• 6.保存申请结果，更新到自己的数据库
• 7.如果过程中出现任何异常，进行上报，到顶层方法触发补偿逻辑。
  • 自己系统的数据库操作回滚
  • 微信模板恢复（自己的补偿逻辑，删除已添加的模板）

我在开发过程中遇到一个问题，就是我们既要保证过程中出现任何问题都要保证数据是可恢复的，那么以上过程中第5步是调用第三方微信接口，我们无法直接操作事务的，怎么办呢？我是用到了TCC，在传入方法里记录申请成功的模板id，如果过程中出现异常，那么在异常捕捉里我们既要进行spring的rollback也要判断成功模板id集合是否为空，如果不为空，在此时我们也要调用微信接口将刚刚申请成功的模板id进行删除。其实这就是用到了我自己写的补偿逻辑。

三 可靠消息最终一致性方案

直接基于MQ来实现事务。比如阿里的RocketMQ以及RabbitMQ就支持消息事务。

大概的意思就是： 1）A系统先发送一个prepared消息到mq，如果这个prepared消息发送失败那么就直接取消操作别执行了 2）如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉mq发送确认消息，如果失败就告诉mq回滚消息 3）如果发送了确认消息，那么此时B系统会接收到确认消息，然后执行本地的事务 4）有种可能,mq接收半消息了,本地消息也执行成功了,但是给mq发送确认消息时候失败了,这种情况mq还是半消息怎么办呢? mq会自动定时轮询所有prepared消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认消息？那是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，别确认消息发送失败了。 5）这个方案里，要是系统B的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如B系统本地回滚后，想办法通知系统A也回滚；或者是发送报警由人工来手工回滚和补偿

这个还是比较合适的，目前国内互联网公司大都是这么玩儿的，要不你举用RocketMQ支持的，要不你就自己基于类似ActiveMQ？RabbitMQ？自己封装一套类似的逻辑出来，总之思路就是这样子的

提供一个比较好的demo https://mp.weixin.qq.com/s/aFxCsAMjzGLROsw9MXN9EQ

4. 最大努力通知方案

这个方案的大致意思就是：

1）系统A本地事务执行完之后，发送个消息到MQ 2）这里会有个专门消费MQ的最大努力通知服务，这个服务会消费MQ然后写入数据库中记录下来，或者是放入个内存队列也可以，接着调用系统B的接口 3）要是系统B执行成功就ok了；要是系统B执行失败了，那么最大努力通知服务就定时尝试重新调用系统B，反复N次，最后还是不行就放弃；

其实我发现我这里也有用到这种模式。。。我这里有个延迟消息处理，A服务轮询数据库延迟消息表提取已到发送时间的延迟发送消息，查到了之后发到我们的MQ里。另一半消息监听服务会调用处理服务去处理消息，如果消息没有处理成功会进行一定的重试。（当然消息最终发送那里是做了幂等的）

06_可靠消息最终一致性方案.png