本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

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 特性。它是阿里云的一款产品。