分布式与并发【二】浅谈分布式一致性协议2PC与3PC

前言：

在分布式系统体系中，为保证数据的一致性，产生了一系列的一致性协议，其中最为著名的就是2PC和3PC协议，以及现在广泛使用的真正解决一致性的Paxos算法，本篇只讲述2PC和3PC，下一篇再介绍Paxos算法。

在分布式系统中，每个子节点都能明确认知到自己处理的事务成功或者失败，但是却无法直接获取其他分布式节点的操作结果，因此当一个事务需要跨多个系统操作时，就需要一个中间方也叫做协调者来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点称之为参与者，由协调者来确定事务是否最终需要提交，基于这个思想衍生出2PC和3PC一致性提交协议。

2PC提交协议

2PC协议也就是两阶段提交协议，将分布式事务提交分为两个阶段，分别为提交事务和执行事务。

阶段一，事务预提交

1. 事务询问
   首先由协调者节点向各个参与者节点发送事务内容，并等待参与者返回结果。

2. 事务执行
   事务参与者将事务内容写入redo和undo日志，但是此时并不会真正的提交事务。

3. 事务响应
   事务参与者返回事务可执行状态给协调者，可以执行返回YES，否则返回NO

此时阶段一完毕，整个过程相当于一个参与者投票的过程，所有参与者响应事务是否可以执行。

阶段二，事务执行与中断
当阶段一完成后，此时根据参与者返回的状态，一共两种情况，分别为可执行事务，不可执行事务。

可执行事务（事务Commit）：

1. 此时协调者已经收到了所有参与者返回YES，向所有参与者发送事务commit请求。
2. 参与者收到commit请求后各自进行事务的执行。
3. 参与者事务提交完成后，向协调者发送ACK请求，告知事务执行提交结果。
4. 协调者收到所有参与者的ACK成功结果后，完成本次事务。

不可执行事务（事务Rollback）：

1. 此时协调者收到某个参与者返回No，或者等待超时Timeout，那么向所有参与者发送Rollback事务中断请求。
2. 参与者收到回滚请求后根据Undo日志进行事务回滚操作。
3. 回滚完成后向协调者发送ACK回滚状态。
4. 此时协调者收到所有参与者ACK后完成事务中断操作。

小结

以上就是两阶段事务提交的全部流程，该流程是一个强一致性的算法，对每个事务都先尝试提交再确认提交的过程。

2PC协议优点：原理简单，实现方便。
2PC协议缺点：同步阻塞，单点故障，数据不一致。

1. 同步阻塞：当事务执行阶段，那么每个节点都要占用资源，并等待其他节点返回结果，此时该事务其他逻辑处于阻塞阶段，无法完成其他操作。

2. 单点故障：从流程上可以看到，该算法非常依赖协调者，如果协调者出现故障问题，整个流程都将阻塞，并且如果在阶段二中发生，由于其他节点占用资源，导致资源无法释放。

3. 数据不一致：这是最大的问题，如果协调者在发送给部分节点Commit时挂掉，会导致数据不一致问题发生。

3PC提交协议

三阶段提交协议是对二阶段中同步阻塞进行了优化，将整个事务执行流程分为提交询问（canCommit）、预提交（preCommit）、实际提交（doCommit）三个过程，是2PC协议的进化版。

阶段一，提交询问（canCommit）

1. 事务询问
   首先由协调者节点向各个参与者节点事务是否可以提交请求（此时不发送事务内容），并等待参与者返回结果。
2. 询问返回
   各个参与者返回给协调者是否可以提交事务，YES 或 NO。

阶段二，预提交事务（preCommit）
当阶段一完成后，此时根据参与者返回的状态，一共两种情况，分别为可提交、不可提交。

可提交事务（事务preCommit）：

1. 此时协调者已经收到了所有参与者返回YES，向所有参与者发送事务preCommit请求，并发送事务内容。
2. 参与者收到preCommit请求后各自进行事务的执行，写入Undo和Redo日志。
3. 参与者事务提交完成后，向协调者发送ACK响应，告知事务执行结果，然后等待最终指令Commit和abort。

不可提交事务（事务abort）：

1. 此时协调者已经收到了某个参与者返回No或者等待超时，向所有参与者发送事务abort请求。
2. 无论此时收到了abort请求或者等待超时，参与者直接进行中断本次事务。

阶段三，最终提交事务（doCommit）
当阶段二完成后，此时根据参与者返回的状态，一样分为两种情况，分别为可最终commit、事务中断回滚abort。

最终提交事务（commit）：

1. 此时协调者已经收到了所有参与者返回YES，代表所有参与者已经执行事务完成，向所有参与者发送事务最终的commit提交请求。
2. 参与者收到commit请求后各自进行事务的提交。
3. 参与者事务提交完成后，向协调者发送ACK响应。
4. 协调者在收到ACK响应后，完成本次的事务执行。

事务回滚（abort）：

1. 此时协调者已经收到了某个参与者返回No或者等待超时，向所有参与者发送事务回滚abort请求。
2. 参与者此时收到了abort请求，参与者利用Undo日志来进行事务的执行回滚操作，然后释放掉事务执行占用的资源。
3. 参与者事务回滚完成后，向协调者发送ACK响应。
4. 协调者在收到ACK响应后，完成本次的事务中断。

PS： 如果在该阶段参与者等待超时，未收到协调者的任何请求，默认会在超时后继续提交事务。

小结

以上就是三阶段事务提交的全部流程，可以看到其实比2阶段提交优化了同步阻塞的问题，但是依然没有避免单点故障和数据不一致的问题。

3PC协议优点：降低同步阻塞。
3PC协议缺点：如果在preCommit阶段后此时协调者发生故障或发生网络分区，此时协调者和参与者无法进行正常通信，参与者超时后依然提交了事务，导致数据不一致。

总结：

2PC和3PC协议都是强一致性事务提交算法，但是依然无法避免一些问题，在以前Mysql数据库则采用这种协议来保证一致性，现在目前主流则采用Paxos算法来保证一致性。

参考文献：
【1】从Paxos到Zookeeper 分布式一致性原理与实践
【2】部分来源于网络