简单来说，分布式事务就是一个业务操作包含多个子操作，并且子操作分属不同服务器上(也可以说操作不同数据库)，这时候需要保证这些子操作要么全部成功，要么全部失败，进而达到一致性。
基本理论
ACID
参考上一篇文章
CAP理论
- 一致性（Consistency）：在分布式环境下，一致性是指数据在多个副本之间能否保持一致的特性。这里指的是强一致性
- 可用性（Availability）：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限时间内返回结果
- 分区容错性（Partition tolerance）：分布式系统在遇到任何网络分区故障的时候，仍然能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要根据业务场景做出选择。这里要强调的是：CAP定律的前提是P，当P决定后才有CA的抉择。
BASE理论
BASE理论是对CAP中一致性和可用性权衡的结果，来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：牺牲强一致性，根据自身业务特点，采用适当的方式来使系统达到最终一致性，从而提高可用性。BASE中的三要素：
- 基本可用Basically Available：指分布式系统在出现不可预知故障的时候，允许损失部分可用性，这绝不等价于系统不可用，比如服务降级、页面降级等等。
- 软状态Soft state：是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步存在延时。
- 最终一致性Eventually consistent：强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，其本质是需要系统保证数据最终能够达到一致，而不需要保证系统数据的实时强一致性。
分布式事务解决方案
事务消息最终一致性
前提条件是MQ必须支持事务消息，比如RocketMQ
优点
- 实现了最终一致性，不需要依赖本地数据库事务；
- 不占用业务DB资源；
- 没有耦合其它非业务代码。
缺点：
- 主流开源MQ基本都不支持，自身实现难度大
本地消息（事务）表
核心设计思想：将分布式事务拆分成一系列的本地事务进行处理
优点
- 是一种非常经典且较简单的实现，避免了分布式事务，实现了最终一致性。
缺点
- 与具体的业务场景绑定，耦合性强，不可复用；
- 消息数据与业务数据同库，占用业务系统资源。
TCC补偿性事务
核心思想：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作
优点
- 解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用；
- 实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。
缺点
- Try、Confirm和Cancel操作功能需业务提供，开发成本高；
- Cancle要考虑部分cancle成功的场景，保证数据最终一致性。
最大努力通知型
本质上就是通过定期校对，实现数据一致性。典型的使用场景有：银行通知、商户通知
优点
实现简单。
缺点
无补偿机制，不保证能够送达。
