讲解分布式事务的一篇良心之作

本文主要是介绍讲解分布式事务的一篇良心之作，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

分布式事务的几种实现思路

整个流程图如下所示：

我们来解释一下这个方案的大概流程：

A系统先发送一个prepared消息到mq，如果这个prepared消息发送失败那么就直接取消操作别执行了，后续操作都不再执行
如果这个消息发送成功过了，那么接着执行A系统的本地事务，如果执行失败就告诉mq回滚消息，后续操作都不再执行
如果A系统本地事务执行成功，就告诉mq发送确认消息
那如果A系统迟迟不发送确认消息呢？

此时mq会自动定时轮询所有prepared消息，然后调用A系统事先提供的接口，通过这个接口反查A系统的上次本地事务是否执行成功

如果成功，就发送确认消息给mq；失败则告诉mq回滚消息（后续操作都不再执行）
此时B系统会接收到确认消息，然后执行本地的事务，如果本地事务执行成功则事务正常完成
如果系统B的本地事务执行失败了咋办？

基于mq重试咯，mq会自动不断重试直到成功，如果实在是不行，可以发送报警由人工来手工回滚和补偿

这种方案的要点就是可以基于mq来进行不断重试，最终一定会执行成功的。

因为一般执行失败的原因是网络抖动或者数据库瞬间负载太高，都是暂时性问题。

通过这种方案，99.9%的情况都是可以保证数据最终一致性的，剩下的0.1%出问题的时候，就人工修复数据呗。

适用场景：

这个方案的使用还是比较广，目前国内互联网公司大都是基于这种思路玩儿的。

整个流程图如下所示：

这个方案的大致流程：

这套方案和上面的可靠消息最终一致性方案的区别：

可靠消息最终一致性方案可以保证的是只要系统A的事务完成，通过不停（无限次）重试来保证系统B的事务总会完成

但是最大努力方案就不同，如果系统B本地事务执行失败了，那么它会重试N次后就不再重试，系统B的本地事务可能就不会完成了。

至于你想控制它究竟有“多努力”，这个需要结合自己的业务来配置。

比如对于电商系统，在下完订单后发短信通知用户下单成功的业务场景中，下单正常完成，但是到了发短信的这个环节由于短信服务暂时有点问题，导致重试了3次还是失败。

那么此时就不再尝试发送短信，因为在这个场景中我们认为3次就已经算是尽了“最大努力”了。

简单总结：就是在指定的重试次数内，如果能执行成功那么皆大欢喜，如果超过了最大重试次数就放弃，不再进行重试。

适用场景：

一般用在不太重要的业务操作中，就是那种完成的话是锦上添花，但失败的话对我也没有什么坏影响的场景。

比如上边提到的电商中的部分通知短信，就比较适合使用这种最大努力通知方案来做分布式事务的保证。

TCC的全称是：

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

还是给大家举个例子：

比如跨银行转账的时候，要涉及到两个银行的分布式事务，如果用TCC方案来实现，思路是这样的；

Try阶段：先把两个银行账户中的资金给它冻结住就不让操作了
Confirm阶段：执行实际的转账操作，A银行账户的资金扣减，B银行账户的资金增加
Cancel阶段：如果任何一个银行的操作执行失败，那么就需要回滚进行补偿，就是比如A银行账户如果已经扣减了，但是B银行账户资金增加失败了，那么就得把A银行账户资金给加回去

适用场景：

这种方案说实话几乎很少有人使用，我们用的也比较少，但是也有使用的场景。

因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常之恶心。

比如说我们，一般来说跟钱相关的，跟钱打交道的，支付、交易相关的场景，我们会用TCC，严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，在资金上不允许出现问题。

比较适合的场景：除非你是真的一致性要求太高，是你系统中核心之核心的场景，比如常见的就是资金类的场景，那你可以用TCC方案了

你需要自己编写大量的业务逻辑，自己判断一个事务中的各个环节是否ok，不ok就执行补偿/回滚代码。

而且最好是你的各个业务执行的时间都比较短。

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