本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
1. 分布式理论
1.1. CAP定律
CAP指的是：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
CAP定律说的是，在一个分布式系统中，最多只能满足C、A、P中的两个，不可能三个同时满足。
在分布式系统中，网络无法 100% 可靠，分区其实是一个必然现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是 A 又不允许，所以分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。
而且，显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。
更多请参考
1.2. BASE理论
往往在分布式系统中无法实现完全一致性，于是有了BASE理论，它是对CAP定律的进一步扩充
BASE指的是：
- Basically Available（基本可用） ： 分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用
- Soft state（软状态） ： 允许系统中存在中间状态，这个状态不影响系统可用性
- Eventually consistent（最终一致性） ： 经过一段时间后，所有节点数据都将会达到一致
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果
BASE理论核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性
BASE理论是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态
2. 分布式事务解决方案
2.1. 基于XA协议的两阶段提交
XA协议包含两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，目前主流的关系型数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。
优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）
缺点：XA协议遵循强一致性。在事务执行过程中，各个节点占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知提交，参与者提交后释放资源。这样的过程有着非常明显的性能问题。
（PS：XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段，并且引入了超时机制。这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。）
两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。
2.2. TCC方案
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。
其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。
拿前面的下单的例子来说，服务A的try相当于查询是否有可用的积分，Confirm相当于扣减积分，Cancel相当于增加积分。
优点：跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些
缺点：TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，而且补偿的时候也有可能失败，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
2.3. 本地消息表
其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。
消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。
本地消息表是一个比较好的做法，这样可以有效防止重复消息处理
以转账为例，这种方式的过程是这样的：
- 当A想给B转100元时，A账户先减100元，然后在其本地消息表中加一条记录，写明A给B转100元，并且状态是消息未发送。这个向消息表写数据的操作和A账户扣减100元在同一个事务中，依靠数据库本地事务保证一致性，即只要A减100成功了，这条记录必然成功。
- 定时任务去轮询消息表，把没有发出去的消息都发出去，并标记状态为已发送
- B收到这个消息的时候先存入本地的消息表，标记未处理
- B这边定时扫描未处理的消息，处理完成后更新状态为已处理
有了消息表以后，可以防止重复、可以重试、保证消息不丢失、做幂等性校验
优点：一种非常经典的实现，避免了分布式事务，实现了最终一致性。
缺点：消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。
2.4. MQ（非事务消息）
如果不把本地数据库操作和消息投递放在同一个事务中，那么很难保证本地事务成功后消息一定发送成功
如果把它们放在同一个事务中，那么考虑下面几种情况：
- 第1种情况：本地数据库操作成功，消息发送成功，皆大欢喜
- 第2种情况：本地数据库操作失败，消息不会发送
- 第3种情况：本地数据库操作成功，消息发送失败（抛异常），事务回滚
以上三种情况都是正常的，不会有什么问题
然而，考虑下面这种情况：
本地数据库操作成功，消息投递成功，应用服务器挂了，事务回滚，于是不一致出现了，即本地数据库操作没成功，而消息却发成功了
如果这是转账的话，对方会无缘无故多出一笔钱
究其原因，是因为发消息不是数据库操作，它不受ACID的限制，也就是说数据库事务管不了发消息，因为他们不是同一个数据库的同一个事务，当然还有一个原因是发出去的消息是无法撤销的。（PS：在后面将要介绍的RocketMQ的事务消息可以撤销）
而上面消息表的话，是同一个数据库的同一个事务，因此不会出现这种问题
综上，这种方式有一定的风险，它无法保证本地数据库操作 与 消息投递的一致性，不建议使用
2.5. MQ（事务消息）
目前，仅阿里云的RocketMQ支持事务消息。帮助用户实现类似 X/Open XA 的分布事务功能，通过 MQ 事务消息能达到分布式事务的最终一致。
说明：
- 发送方向 MQ 服务端发送消息
- MQ Server 将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功，此时消息为半消息
- 发送方开始执行本地事务逻辑
- 发送方根据本地事务执行结果向 MQ Server 提交二次确认（Commit 或是 Rollback），MQ Server 收到 Commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server 收到 Rollback 状态则删除半消息，订阅方将不会接受该消息
- 在断网或者是应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达 MQ Server，经过固定时间后 MQ Server 将对该消息发起消息回查
- 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果
- 发送方根据检查得到的本地事务的最终状态再次提交二次确认，MQ Server 仍按照步骤4对半消息进行操作
其中，事务消息发送对应步骤1、2、3、4，事务消息回查对应步骤5、6、7
更多请参见
2.6. GTS
全局事务服务（Global Transaction Service，简称 GTS）是一款高性能、高可靠、接入简单的分布式事务中间件，用于解决分布式环境下的数据一致性问题。GTS 可以保证分布式系统中的分布式事务的 ACID 特性。它是阿里云的一款产品。
更多请参见
3. 参考