分布式事务就是由多个本地事务组合而成的事务
事务我们都不陌生，我们常说的事务一般都是指单机事务，即本地事务。那分布式事务是什么？分布式事务就是由多个本地事务组合而成的事务，一般在分布式场景下才会出现。
比如电商平台中，我们在购物的时候，下单支付这个过程看上去是一气呵成的，但是背后可能是多个系统的分工合作。订单系统、支付系统、物流系统等。这些系统部署在不同的服务器上，执行的都是各种的事务，对于电商平台来说，这就是分布式事务。
本地事务都好解决，有一套现成的事务机制，分布式事务比本地事务就要复杂多。如何实现分布式事务呢？大概有 3 种解决方式：
- 基于 XA 协议的二阶段提交协议。
- 三阶段提交协议。
- 基于 MQ 的最终一致性。
基于 XA 协议的二阶段提交
XA协议由 Tuxedo 首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。目前，Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。----来源百度百科
二阶段提交也叫 2PC ，The two-phase commit protocol。首先在二阶段提交中有两个角色：
- 参与者：本地资源管理器，即事务的执行者，也就是各个业务系统。
- 协调者：分布式事务的大脑，负责指挥协调各个业务系统提交/回滚事务。
所谓得两阶段提交就是指投票（voting）和提交（commit） 两个阶段，跟选举制度一样，先投票，再决定。
投票阶段，协调者向参与者发起执行事务操作的请求（CanCommit 请求），并等待参与者响应。
参与者接受到请求后，执行事务请求操作，记录日志信息但不提交，记录成功后，向协调者发生 “Yes” 消息，表示同意提交操作，若不成功，则发送“No” 消息，表示不同意这次操作。注意这个过程会锁定数据。
投票阶段得流程图，大概就是下面这样子：
提交阶段，协调者接受到所有参与者的响应之后，根据返回来的信息情况，向参与者发送提交或回滚请求。
若收到的响应消息都是 “Yes”，则向参与者发送 “DoCommit” 消息，参与者完成本地事务的其他操作并释放资源，然后向协调者发送 “HaveCommitted”消息；
如果协调者收到的消息中包含“No”消息或者在规定时间内有参与者没有响应，则向所有参与者发送“DoAbort”消息，此时发送“Yes”的参与者则会根据之前执行操作时的回滚日志对操作进行回滚，然后所有参与者会向协调者发送“HaveCommitted”消息；
提交阶段的流程，大概入下图所示：
二阶段提交协议容易理解，基于 XA 的二阶段提交算法满足事务的 ACID 特性，看上去比较完美，但是缺点还是挺多的，主要有以下几个问题：
- 同步阻塞问题：二阶段提交在执行过程中，所有参与节点都是事务阻塞型的，参与者会锁定数据，其他访问者要访问该数据的话，都会被阻塞。
- 单点故障问题。在二阶段提交协议中，协调者只有一台，一旦协调者发送故障，整个系统都会处于停滞阶段。特别是提交阶段，如果协调者挂了的话，参与者就会一直等待协调者回应，会处于阻塞中。
- 数据不一致问题：在提交阶段，协调者向参与者发送 DoCommit 请求后，由于网络抖动或者在发送请求的过程中，协调者发生故障，就会导致只有一部分参与者接收到了提交请求并执行提交操作，但其他未接到提交请求的那部分参与者则无法执行事务提交。于是整个分布式系统便出现了数据不一致的问题。
三阶段提交
三阶段提交协议（Three-phase commit protocol，3PC）是对二阶段提交（2PC）的改进。解决了二阶段提交的一些问题，三阶段和二阶段提交最大的不同是引入超时机制和准备阶段。
先来说说超时机制，在二阶段提交，只有协调者才有超时机制，如果协调者在规定时间内没有接收到参与者的响应，就会根据当前状态提交或者终止整个事务，但是如果协调者挂了，参与者并没有超时机制，所以就一直等待，这也是二阶段提交单点故障的问题。在三阶段提交中，同时在协调者和参与者中引入超时机制。如果协调者或参与者在规定的时间内没有接收到来自其他节点的响应，就会根据当前的状态选择提交或者终止整个事务。
三阶段提交其实就是将二阶段提交中的提交阶段一分为二，三阶段提交协议中的具体三阶段是：CanCommit、PreCommit、DoCommit 三个阶段
CanCommit 阶段，CanCommit 阶段与 2PC 的投票阶段类似：协调者向参与者发送请求操作（CanCommit 请求），询问参与者是否可以执行事务提交操作，然后等待参与者的响应；参与者收到 CanCommit 请求之后，回复 Yes，表示可以顺利执行事务；否则回复 No。
PreCommit 阶段，根据二阶段提交中的提交阶段相似，根据 CanCommit 阶段返回的结果，来决定是否可以进行 PreCommit 操作。
这时候就存在两种情况，如果所有参与者都回复 “Yes”，那么执行流程是这样的：
- 1、协调者发送预提交请求：协调者向参与者发送 PreCommit 请求，进入预提交阶段.
- 2、事务预提交：参与者接收到 PreCommit 请求后执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中。
- 3、响应反馈：如果参与者成功执行了事务操作，则返回 ACK 响应，同时开始等待最终指令。
如果有参与者返回 “No”，或者协调者在规定时间内没有收到参与者的响应，那么将执行中断事务操作。流程是这样的：
- 1、发送中断请求：协调者向所有参与者发送“Abort”消息。
- 2、中断事务：参与者收到“Abort”消息之后，或超时后仍未收到协调者的消息，执行事务的中断操作。
DoCommit 阶段， 事务真正提交阶段，协调者根据 PreCommit 阶段参与者返回来的信息，决定是进入提交阶段还是事务中断阶段。
提交阶段流程如下：
- 1、发送提交请求：协调者接收到所有参与者发送的 Ack 响应，从预提交状态进入到提交状态，并向所有参与者发送 DoCommit 消息。
- 2、事务提交：参与者接收到 DoCommit 消息之后，正式提交事务。完成事务提交之后，释放所有锁住的资源。
- 3、响应反馈：参与者提交完事务之后，向协调者发送 Ack 响应。
- 4、完成事务：协调者接收到所有参与者的 Ack 响应之后，完成事务。
事务中断阶段，流程如下：
- 1、发送中断请求：协调者向所有参与者发送 Abort 请求。
- 2、事务回滚：参与者接收到 Abort 消息之后，利用其在 PreCommit 阶段记录的 Undo 信息执行事务的回滚操作，并释放所有锁住的资源。
- 3、反馈结果：参与者完成事务回滚之后，向协调者发送 Ack 消息。
- 4、中断事务：协调者接收到参与者反馈的 Ack 消息之后，执行事务的中断，并结束事务。
基于分布式消息的最终一致性方案
不管是二阶段提交还是三阶段提交，都属于强一致性的，满足事务的 ACID 原则。它们都有两个共同的问题：
- 1、需要锁定数据，降低了系统性能。
- 2、因为网络等原因，并没有完全解决数据一致性问题。
而基于 MQ 消息的分布式解决方案就不太一样了，它采用的不是强一致性，而是最终一致性，这也就是 BASE 理论。并且我们直到 MQ 是异步的，所以性能也比较快，可以说完美的解决了上面两种方式带来的问题。
基于 MQ 消息中间件解决分布式事务的思路是这样的：主要是基于 MQ 消息投递的可靠性，将分布式事务发送给 MQ 中间件之后，中间件将事务持久化，这一点非常重要，保证消息不丢失。消费者端异步消费，如果遇到失败情况，由于我们的消息是持久化的，所以可以根据业务规则不断重试，有必要的话，人工补偿，保证数据最终一致性。
关于基于分布式消息的最终一致性方案，我准备基于 RocketMQ 单独开一个章节，详细聊一聊，这里就不多说了。