微服务架构下的分布式事务问题
ACID理论：关系型数据库的事务满足 ACID 的特性，具有 ACID 特性的数据库支持数据的强一致性，保证了数据本身不会出现不一致。适用于传统的单体架构。
CAP理论：在分布式系统下， 包含三个要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），并且三者不可兼得。分布式系统要求保证分区容错性，只能在数据强一致性（C）和可用性（A）之间做平衡，即选择CP或者AP。比如Zookeeper为CP系统保证强一致性牺牲一定的可用性；Eureka为AP系统保证较高可用性牺牲一定的一致性。另外，CAP理论中是忽略网络延迟，也就是当事务提交时，从节点A复制到节点B，但是在现实中这个是明显不可能的，所以总会有一定的时间是不一致。所以CAP一般适用于局域网系统的理论基础。
BASE理论：解决 CAP 理论中分布式系统的可用性和一致性不可兼得的问题，提出最终一致性。即，最终数据是一致的就可以了，而不是实时保持强一致。例如，支付成功，订单也成功，但增加积分失败，此时，不应回滚支付和订单，而应通过一些 补偿方法来让积分得以正确地增加。
本地事务
基于数据库的ACID理论
基于undo、redo日志记录
undo日志实现回滚、redo日志实现commit场景异常的恢复
传统单体架构
分布式事务要求不高的场景
分布式系统场景出现问题怎么办？
日志记录–监控告警–人工干预修复
问题溯源，例如：维修工单可以创建，但是维修费用调用失败导致整个事务回滚
可能维修费用自身问题，如性能压力过大导致请求时，触发调用失败回滚
可能维修费用操作依据成功了，但是返回
两阶段提交
基于XA协议，依赖TM、RM的交互，依赖数据库的能力
TM存在单点故障，锁资源占用时间较长
面向多数据源或者分布式数据库设计（XA本质是TM与RM之间的规范）
适用于多数据源的架构
Mycat也实现了XA协议，一些公司的分布式事务使用该方案，但是应用层非微服务架构
适用于并发量不大，处理时间较短的核心交易业务场景
三阶段提交
基于TCC协议
在数据库外部实现事务机制达到最终一致性
牺牲了应用的灵活性，需要提供Try、Confirm、Cancel的具体实现，且需要小心保证幂等操作
跨应用，但需要实现TCC接口，对已有系统侵入较大，适用于新系统
不强依赖数据库特性，TCC是一个通用的模型
参考实现：https://github.com/liuyangming/ByteTCC/
可靠消息模式
大事务转变为小事务，小事物之间的不一致通过额外的轮训任务进行补偿
该思路最初由Ebay提出：https://queue.acm.org/detail.cfm?id=1394128
可分为基于本地事件、基于外部事件两种模式
业务逻辑需要保证幂等性
适用于核心模块的改造，或者完全基于消息驱动的架构，否则对已有系统入侵较大
另外，如果需要回滚，超过两个实务操作的场景比较复杂，所以这种场景需要遵守最终一致性原则，失败不会滚，直到补偿成功
依赖具备事务功能的消息系统或者数据库，如：RabbitMQ、Kafka、RocketMQ等
基于本地事件：
基于外部事件：
可靠消息变种
不依赖消息队列通信，将消息队列的功能包装为Rest服务，屏蔽消息队列的接口
将基于可靠消息模式对架构和应用入侵的缺点降低
最大努力通知型
如支付宝的回调机制，可以设置指数时间重试，参考阿里实现：https://zhuanlan.zhihu.com/p/26114119
下游应用轮询
如微信的轮询机制，由下游应用自己保证一致性
SAGA方案
基于工作流的思路，原理：https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf
定义顺序操作、回滚操作的流程，交给事务协调器统一管理
一些应用框架实现了该方案，如CQRS框架Axonframework：https://github.com/AxonFramework/AxonFramework，又如华为servicecomb：https://github.com/apache/incubator-servicecomb-saga
应用方定义工作流，交给SAGA进行管理，虽然这种方案不火热，但是对应用入侵较小，且符合分层的设计原则，添加一个composite层单独实现需要分布式事务的流程即可
SAGA工作流：
阿里GTS
优化XA架构的路线，使用上与XA类似，业务入侵较小，添加注解
GTS参考：https://zhuanlan.zhihu.com/p/32684212
仿GTS实现：https://github.com/wxbty/meepo
https://github.com/chenjy16/gts
与GTS类似的：https://github.com/codingapi/tx-lcn 看起来最成熟的开源方案
适用于阿里云方案，专线也可以接入使用，第三方系统遵循TCC的也可以接入
如果非必要，不引入分布式事务，每个微服务保证自身的高可用，基本能够保证数据的一致性，极端的情况除外。–事实上微服务的架构BAT十年前就在使用，没有分布式事务也一样，因为基础设施、每个微服务自身可用性比较高，所以不需要引入更大的复杂性
如果必要，首先保证核心业务的数据一致性，比如交易业务，可以采用消息机制、最大努力通知、轮询机制的方案，他们的本质都是记账，即使出了问题也有据可查–这部分一般借助第三方支付系统的能力即可满足
如果只是较少量的业务需要分布式事务特性，可以局部使用基于可靠消息的方案，参考：https://github.com/vvsuperman/coolmq，这种方案需要注意很多细节，理论上每个环节都可能出现网络异常，都需要有相应的措施保障，比如：如果建立指数时间重试机制，下游服务接口需要保证幂等，该方案相当于业务自己负责维护一致性
如果大量业务需要分布式事务，也可以引入类似DelayMq的服务做解耦，利用该服务提供回调服务将服务链串联起来（消息中包含回调的Url、参数），但是下游的服务接口需要保证幂等性–PaaS平台可以提供类似的服务，参考：https://zhuanlan.zhihu.com/p/26114119。该方案需要能够接受部分代码的重构
如果大量业务需要分布式事务，可以引入类似GTS对业务入侵较小的框架，避免更新架构和代码，代码添加必要的注解即可，如：https://github.com/codingapi/tx-lcn –开源方案，建议经过测试之后谨慎上线，这个能力也可以研究下看看能不能做到PaaS平台
数据一致性是一个系统工程，仅仅在事务框架层面解决是不够的，还需要配套的规范措施–如请求RequestID、链路追踪、接口幂等、日志输出规范、关键日志记录规范等，出现问题可以快速定位，这部分的数据可以让PaaS接管，提供链路服务、监控告警服务等
完善基础设施，降低网络问题的影响是重要前提。对于实际调用已经成功，返回时网络异常的问题，需要补偿机制–PaaS可以提供类似DelayMq的服务
完善应用的监控告警设施，如应用的API、访问次数、失败次数等监控，及时告警–PaaS可以提供应用的实时监控告警能力
三、参考资料
再有人问你分布式事务，把这篇扔给他：https://mp.weixin.qq.com/s/W7XeNKIwB-JxnyStq0xD6g
GTSDemo介绍：https://help.aliyun.com/document_detail/57267.html?spm=a2c4g.11174283.3.5.6eea735d9NoIS6
ByteTCC：https://github.com/liuyangming/ByteTCC/
GTS解密–GTS的原理、架构与特点：https://zhuanlan.zhihu.com/p/32684212
分布式事务系列：https://blog.csdn.net/qq_27384769/article/details/79305402
四、GitHub相关项目
https://github.com/HasonHuang/distributed-transaction-process
https://github.com/QNJR-GROUP/EasyTransaction
https://github.com/vvsuperman/coolmq
https://github.com/yu199195/myth
https://github.com/yu199195/hmily
https://github.com/1991wangliang/tx-lcn
https://github.com/codingapi/tx-lcn
https://github.com/prontera/spring-cloud-rest-tcc
https://github.com/QNJR-GROUP/EasyTransaction
