分布式一致性-2PC、3PC

这是我参与8月更文挑战的第26天，活动详情查看： 8月更文挑战

2PC

2PC（Two-Phase Commit），即二阶段提交。其将事务提交过程分为两个阶段来进行处理，执行流程如下。

阶段一：提交事务请求

1. 事务询问

   协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

2. 执行事务

   各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中。

3. 各参与者向协调者反馈事务询问的响应

   如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者No响应，表示事务不可以执行。

阶段二：执行事务提交

在阶段二中，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况下，包含以下两种情况。

执行事务提交

协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务提交。

1. 发送提交请求

   协调者向所有参与者节点发出Commit请求。

2. 事务提交

   参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。

3. 反馈事务提交结果

   参与者在完成事务提交之后，向协调者发送Ack消息。

4. 完成事务

   协调者接收到所有参与者反馈的Ack消息后，完成事务。

中断事务

假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无发接收到所有参与者的反馈响应，那么就会中断事务。

1. 发送回滚请求

   协调者向所有参与者节点发出Rollback请求。

2. 事务回滚

   参与者接收到Rollback请求后，会利用其在阶段一种记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。

3. 反馈事务回滚结果

   参与者在完成事务回滚之后，向协调者发送Ack消息。

4. 中断事务

   协调者接收到所有参与者反馈的Ack消息后，完成事务中断。

问题

1. 同步阻塞

   无论是在一阶段还是在二阶段，所有参与者资源和协调者资源都是被锁定的，所有参与事务操作的逻辑都处于阻塞状态。

2. 单点问题

   由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞下去。尤其是在第二阶段，所有的参与者都处于锁定事务资源的状态中，无法继续完成事务操作。

3PC

3PC（Three-Phase Commit），即三阶段提交，是2PC的改进版。其将二阶段提交协议的 执行事务提交过程一分为二，形成了由CanCommit、PreCommit和do Commit三个阶段组成的事务处理协议。除此之外，3PC支持参与者超时机制（在2PC中只有协调者拥有超时机制）。

阶段一：CanCommit

1. 事务询问
2. 各参与者向协调者反馈事务询问的响应

阶段二：PreCommit

在阶段二中，协调者会根据各参与者反馈进行事务的预提交操作。根据参与者的反馈有两种可能。

执行事务预提交

如果协调者获得所有参与者的反馈都为Yes，就会执行事务预提交。

1. 发送预提交请求
2. 事务预提交
3. 各参与者向协调者反馈事务执行的响应

中断事务

任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

1. 发送中断请求
2. 中断事务

阶段三：doCommit

和2PC的阶段二相似。

相较于2PC，3PC支持参与者的超时机制，降低了参与者的阻塞范围。另外，通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。