## 1. 分布式事务协议 > 在分布式系统里，每个节点都可以知晓自己操作的成功或者失败，却无法知道其他节点操作的成功或失败。当一个事务跨多个节点时，为了保持事务的原子性与一致性，而引入一个协调者来统一掌控所有参与者的操作结果，并指示它们是否要把操作结果进行真正的提交或者回滚（rollback）。 ### 1.1 二阶段提交2PC 二阶段提交协议（Two-phase Commit，即 2PC）是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理。 **阶段** * 准备阶段 * 提交阶段 **参与角色** * 协调者：事务的发起者 * 参与者：事务的执行者 **1\. 第一阶段（voting phase投票阶段）：** 1. 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复 2. 各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务） 3. 如参与者执行成功，给协调者反馈**同意**，否则反馈**中止**  **2. 第二阶段（commit phase提交执行阶段）：** 当协调者节点从所有参与者节点获得的相应消息都为**同意**时： 1. 协调者节点向所有参与者节点发出**正式提交**(`commit`)的请求。 2. 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。 3. 参与者节点向协调者节点发送**ack完成**消息。 4. 协调者节点收到所有参与者节点反馈的**ack完成**消息后，完成事务。  如果任一参与者节点在第一阶段返回的响应消息为**中止**，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时： 1. 协调者节点向所有参与者节点发出**回滚操作**(`rollback`)的请求。 2. 参与者节点利用阶段1写入的undo信息执行回滚，并释放在整个事务期间内占用的资源。 3. 参与者节点向协调者节点发送**ack回滚完成**消息。 4. 协调者节点受到所有参与者节点反馈的**ack回滚完成**消息后，取消事务。 不管最后结果如何，第二阶段都会结束当前事务。   二阶段提交看起来确实能够提供原子性的操作，但是不幸的是，二阶段提交还是有几个缺点的： 1. **性能问题**：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。 2. **可靠性问题**：参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。 3. **数据一致性问题**：二阶段无法解决的问题：协调者在发出`commit`消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。 ### 1.2 三阶段提交（3PC） 三阶段提交协议，是二阶段提交协议的改进版本，三阶段提交有两个改动点。 * 在协调者和参与者中都引入超时机制。 * 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。 也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有`CanCommit`、`PreCommit`、`DoCommit`三个阶段。处理流程如下：   **1\. 阶段一：CanCommit阶段** 3PC的`CanCommit`阶段其实和2PC的准备阶段很像。协调者向参与者发送`commit`请求，参与者如果可以提交就返回Yes响应，否则返回No响应。 1. 事务询问 协调者向所有参与者发出包含事务内容的`canCommit`请求，询问是否可以提交事务，并等待所有参与者答复。 2. 响应反馈 参与者收到`canCommit`请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。 **2\. PreCommit阶段** 协调者根据参与者的反应情况来决定是否可以进行事务的`PreCommit`操作。根据响应情况，有以下两种可能。 * 假如所有参与者均反馈 yes，协调者预执行事务。 1. 发送预提交请求 ：协调者向参与者发送`PreCommit`请求，并进入准备阶段 2. 事务预提交 ：参与者接收到`PreCommit`请求后，会执行事务操作，并将`undo`和`redo`信息记录到事务日志中（但不提交事务） 3. 响应反馈 ：如果参与者成功的执行了事务操作，则返回**ACK**响应，同时开始等待最终指令。  假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。 1. 发送中断请求 ：协调者向所有参与者发送`abort`请求。 2. 中断事务 ：参与者收到来自协调者的`abort`请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。  3.