https://www.cnblogs.com/chengxy-nds/p/14046856.html
分布式事务三大难题：一致性、高性能和易用性
分布式系统的事务一致性本身是一个技术难题，没有一种简单完美的方案能够应对所有场景，很难兼顾事务一致性，高性能与易用性。三者缺一，则适用场景大大受限，实用价值不高。
首先是一致性：要求在各种异常情况下保证数据是强一致的。目前最常见的一致性解决方案是最终一致性方案，通常是结合消息中间件实现，在互联网企业中广泛使用。最终一致性实现方案比较复杂，开发、运维成本高，并且与强一致相比，业务上是受很多限制的。
其次是高性能：目前基于XA协议的两阶段提交是最常见的分布式事务解决方案，但XA类产品的典型不足是性能低下，这对于互联网大并发需求下的多数企业是无法接受的。国外具有几十年历史和技术沉淀的基于XA模型的商用分布式事务产品，在相同软硬件条件下，开启分布式事务后吞吐经常有数量级的下降。
第三是易用性：为了满足一致性和高性能要求，出现了一些特定场景下的分布式事务方案，但通常会限制用户用法，对业务侵入性强，无法做到简单易用，带来更多开发成本。

1、基于XA协议的2PC

XA是一个分布式事务协议，XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：
image.png
XA也有致命的缺点，那就是性能不理想，无法满足高并发场景。

2、2PC的改进版本-3PC

3、消息事务+最终一致性

消息事务其实就是基于消息中间件的两阶段提交，将本地事务和发消息放在同一个事务里，保证本地操作和发送消息同时成功。
原理如下：
image.png

  • 订单系统向 MQ 发送一条预备扣减库存消息，MQ 保存预备消息并返回成功 ACK
  • 接收到预备消息执行成功 ACK，订单系统执行本地下单操作，为防止消息发送成功而本地事务失败，订单系统会实现 MQ 的回调接口，其内不断的检查本地事务是否执行成功，如果失败则 rollback 回滚预备消息；成功则对消息进行最终 commit 提交。
  • 库存系统消费扣减库存消息，执行本地事务，如果扣减失败，消息会重新投，一旦超出重试次数，则本地表持久化失败消息，并启动定时任务做补偿。

基于消息中间件的两阶段提交方案，通常用在高并发场景下使用，牺牲数据的强一致性换取性能的大幅提升，不过实现这种方式的成本和复杂度是比较高的，还要看实际业务情况。

4、基于业务层的 TCC编程模式

也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不能很好地被复用，代码侵入性很强，不推荐。

5、Seata

Seata 也是从两段提交演变而来的一种分布式事务解决方案，提供了 AT、TCC、SAGA 和 XA 等事务模式，这里重点介绍 AT模式。
业务大致流程：用户发起下单请求，本地 order 订单服务创建订单记录，并通过 RPC 远程调用 storage 扣减库存服务和 account 扣账户余额服务，只有三个服务同时执行成功，才是一个完整的下单流程。如果某个服执行失败，则其他服务全部回滚。
Seata 对业务代码的侵入性非常小，代码中使用只需用 @GlobalTransactional 注解开启一个全局事务即可。

6、总结

分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力。