一、场景
二、理论
1、cap理论
2、base理论
三、解决方案
1、xa/2pc
2、消息队列
2.1 普通方式
2.2 加上事务
2.3 基于本地消息的最终一致性
2.4 独立消息服务系统
3、tcc
4、LCN
一、场景
事务的基本属性：ACID。单机的时候，用本地的数据库事务就能解决了。
但是，随着互联网发展，微服务的流行，分布式事务急需解决。
如图，假如有两个服务，一个在北京，另一个在上海，此时要转账，如何保证转账正确，变的尤为重要。
二、理论
1、cap理论
- Consistency 一致性
- Availability 可用性
- Partition tolerance 分区容错
它们的第一个字母分别是 C、A、P。
Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
既然是分布式，那么就有p,如果没有p，那就不是分布式了。一般是从C、A中选择一种，CP或者AP。
参考：http://www.ruanyifeng.com/blog/2018/07/cap.html
2、base理论
BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。
Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
参考：https://www.jianshu.com/p/9cb2a6fa4e0e
三、解决方案
1、xa/2pc
XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：
总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。资源全局锁定，性能差。对于互联网项目，吞吐量的要求比较大，这种方案比较少用。
2、消息队列 基于消息的最终一致性方案
2.1 普通方式
2.2 加上事务
2.3 基于本地消息的最终一致性
2.4 独立消息服务系统
3、tcc
TCC 将事务提交分为 Try - Confirm - Cancel 3个操作。
- Try：预留业务资源/数据效验
- Confirm：确认执行业务操作
- Cancel：取消执行业务操作
TCC事务处理流程和 2PC 二阶段提交类似，不过 2PC通常都是在跨库的DB层面，而TCC本质就是一个应用层面的2PC。
4、LCN
分布式事务框架。
LCN并不生产事务，LCN只是本地事务的协调工