理解分布式一致性协议：二三阶段提交

Posted 2023-02-26 wuezs

由于毕设和Lab项目需要，最近在看《从paxos到zookeeper分布式一致性原理与实践》， 2和3PC算法流程，网上资料很多，就不赘述了。由于书中关于2PC和3PC的缺点的部分描述不容易让人理解，因此本文主要想讨论一下2和3PC存在哪些优缺点？为什么存在这些缺点？ 以及该协议适应的场景。

2PC 二阶段提交

2PC其实就是先尝试执行事务再提交的策略，如果有一个参与者出现问题，则回滚尝试期间做的事务操作，从而保证分布式事务的原子性。

2PC的缺点：同步阻塞、单点问题、脑裂、过于保守

• 同步阻塞：
  2PC的执行过程中，协调者和参与者节点都处于阻塞状态。即节点之间在等待对方的相应消息时，它将什么也做不了。特别是，当一个节点A在已经占有了某项公共资源的情况下，为了等待其他节点的响应而陷入阻塞状态时，当节点B尝试访问节点A占有的资源时，这个节点B也将连带陷入阻塞状态。因此会极大限制分布式系统的性能。

• 单点问题：
  2PC中只有一个协调者，若算法执行到第二阶段，协调者宕机了，则参与者会一直阻塞下去，虽然可以通过选举新的协调者，或者参与者超时释放资源停止阻塞状态，但不管哪种方法都需要花费时间，而这段期间，参与者会一直陷入阻塞。

• 数据不一致：
  若算法执行到第二阶段，协调者向所有参与者发送commit请求，由于网络异常，导致部分参与者没有收到该commit，而另一部分参与者正常commit，这就导致了数据不一致的出现。
  还有一种情况，当执行到第二阶段，协调者向所有参与者发送commit请求完毕后，参与者A和协调者遇到宕机，此时系统中其余节点无法知道协调者的决策结果，也无法保证参与者A的执行情况，此时新协调者无论执行哪种决策，都可能导致恢复过来的参与者A状态不一致。

• 过于保守：
  协调者需要获取到所有参与者的响应信息，由于缺乏容错机制，任意一个参与者的失败都会导致整个事务的失败

2PC优点是原理简单、实现方便，但由于存在严重的性能问题，大部分的分布式高并发服务都在避免直接使用。常见的做法是将2PC和paxos协议结合起来，通过2PC保证多个数据分片上操作的原子性，通过paxos协议实现同一个数据分片的多个副本之间的一致性，另外，可以通过paxos协议选举新的协调者来解决2PC协议中协调者宕机的问题。

3PC 三阶段提交

3PC的核心理念是先询问，若所有人都同意，则锁定资源，在开始尝试执行、提交。

优点：
和2PC相比较而言，3PC降低了参与者的阻塞范围，能在出现单点故障后继续达成一致，参与者如果在不同阶段宕机，我们来看看3PC如何应对：

• 阶段1: 协调者未收到宕机参与者的vote，直接中止事务；宕机的参与者恢复后，读取logging发现未发出赞成vote，自行中止该次事务。因为先询问，此时并没有锁住资源，避免了2PC第一阶段若已经由节点宕机，其他节点无谓的阻塞。
• 阶段2: 协调者未收到宕机参与者的precommit ACK，但因为之前已经收到了宕机参与者的赞成反馈(不然也不会进入到阶段2)，协调者进行commit；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
• 阶段3:即便协调者未收到宕机参与者的commit ACK，也结束该次事务；宕机的参与者恢复后发现收到commit或者precommit，也将自行commit该次事务。

因为有了准备提交阶段，3PC的事务处理延时也增加了1个RTT，变为3个RTT，但是它防止参与者宕机后整个系统进入阻塞态，增强了系统的可用性，对一些现实业务场景是非常值得的。

缺点：
如果参与者接受到preCommit消息后，如果网络出现分区，此时协调者和参与者无法进行正常通行，这种情况下，参与者和协调者的数据会发生不一致。

参考链接：
https://zh.wikipedia.org/wiki/%E4%B8%89%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4
https://zh.wikipedia.org/wiki/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4
https://zhuanlan.zhihu.com/p/21994882
http://www.hollischuang.com/archives/1580