1 分布式事务的概念
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单来说就是组成事务的各个单元处于不同数据库服务器上。
相信同学们都接触过这种场景，手机支付，付款方和收款方的银行账号不是同一家一行，不在同一地域的情况。那么，我们就要保证付款方减去的金额，和收款方增加的金额保持一致。
在我们的实际开发中，分布式事务无处不在，比如，电商系统中的生成订单，账户扣款，减少库存，增加会员积分等等，他们就是组成事务的各个单元，它们要么全部发生，要么全部不发生，从而保证最终一致。
2 分布式事务的实现的 5 种方案
两阶段提交方案
TCC 方案
本地消息表
可靠消息最终一致性方案
最大努力通知方案
2.1 两阶段提交方案
二阶段提交作为早期分布式事务的解决方案，逐渐的淡出了主流方案的圈子。这里面其最重要的原因就是它是刚性事务，即需要满足强一致性。它的优点就是可以在多数据库间实现事务控制，而摆脱单一数据库使用事务的宿命。但是阻塞式这个缺点确是致命的，因为参与全局事务的数据库被动听从事务管理器的命令，执行或放弃事务，如果运行事务管理器的机器宕机，那整个系统就不能用了。当然，在极端情况下还可能同时影响其他系统，如果事务管理器挂了，但是这个数据库的表锁还没释放，因为数据库还在等待事务管理器的命令，因此，使用这个数据库的其他应用也会收到影响。
2.2 TCC 方案
TCC 的全称是：Try、Confirm、Cancel。
Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留。
Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。
Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）
这种方案说实话几乎很少人使用，我们用的也比较少，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大，非常之恶心。
比如说我们，一般来说跟钱相关的，跟钱打交道的，支付、交易相关的场景，我们会用 TCC，严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，保证在资金上不会出现问题。
而且最好是你的各个业务执行的时间都比较短。
但是说实话，一般尽量别这么搞，自己手写回滚逻辑，或者是补偿逻辑，实在太恶心了，那个业务代码是很难维护的。
2.3 本地消息表
本地消息表其实是国外的 ebay 搞出来的这么一套思想。
这个大概意思是这样的：
1.A 系统在自己本地一个事务里操作同时，插入一条数据到消息表；
2.接着 A 系统将这个消息发送到 MQ 中去；
3.B 系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息；
4.B 系统执行成功之后，就会更新自己本地消息表的状态以及 A 系统消息表的状态；
5.如果 B 系统处理失败了，那么就不会更新消息表状态，那么此时 A 系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到 MQ 中去，让 B 再次处理；
6.这个方案保证了最终一致性，哪怕 B 事务失败了，但是 A 会不断重发消息，直到 B 那边成功为止。
这个方案说实话最大的问题就在于严重依赖于数据库的消息表来管理事务啥的，如果是高并发场景咋办呢？咋扩展呢？所以一般确实很少用。
2.4 可靠消息最终一致性方案
这个的意思，就是干脆不要用本地的消息表了，直接基于 MQ 来实现事务。比如阿里的 RocketMQ 就支持消息事务。
大概的意思就是：
1.A 系统先发送一个 prepared 消息到 mq，如果这个 prepared 消息发送失败那么就直接取消操作别执行了；
2.如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉 mq 发送确认消息，如果失败就告诉 mq 回滚消息；
3.如果发送了确认消息，那么此时 B 系统会接收到确认消息，然后执行本地的事务；
4.mq 会自动定时轮询所有 prepared 消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认的消息，是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，而确认消息却发送失败了。
5.这个方案里，要是系统 B 的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如 B 系统本地回滚后，想办法通知系统 A 也回滚；或者是发送报警由人工来手工回滚和补偿。
6.这个还是比较合适的，目前国内互联网公司大都是这么玩儿的，要不你举用 RocketMQ 支持的，要不你就自己基于类似 ActiveMQ？RabbitMQ？自己封装一套类似的逻辑出来，总之思路就是这样子的。
2.5 最大努力通知方案
这个方案的大致意思就是：
- 系统 A 本地事务执行完之后，发送个消息到 MQ；
- 这里会有个专门消费 MQ 的最大努力通知服务，这个服务会消费 MQ 然后写入数据库中记录下来，或者是放入个内存队列也可以，接着调用系统 B 的接口；
- 要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B，反复 N 次，最后还是不行就放弃。
3 总结
如果你真的被问到，可以这么说，我们某某特别严格的场景，用的是 TCC 来保证强一致性；然后其他的一些场景基于阿里的 RocketMQ 来实现分布式事务。
你找一个严格资金要求绝对不能错的场景，你可以说你是用的 TCC 方案；如果是一般的分布式事务场景，订单插入之后要调用库存服务更新库存，库存数据没有资金那么的敏感，可以用可靠消息最终一致性方案。
4 Seata实现分布式事务
Seata实现分布式事务_赵广陆的博客-CSDN博客_分布式事务seata实现
目录1 分布式事务解决方案-面试1.1 本地事务与分布式事务1.1.1 事务1.1.2 本地事务1.1.3 分布式事务1.2 分布式事务相关理论1.2.1 CAP定理1.2.2 BASE理论1.2.2.1 Basically Available(基本可用)1.3 分布式事务解决方案-面试1.3.1 基于XA协议的两阶段提交1.3.2 TCC补偿机制1.3.3 消息最终一致性-重点2 基于Seata实现分布式事务2.1 Seata简介2.2 Seata事务模式-AT模式2.3 Seata Server端环境准
https://blog.csdn.net/ZGL_cyy/article/details/113829282
