浅谈分布式一致性协议之2PC

1.前言

前面一篇文章和大家一起学习了下分布式系统一致性问题的一些理论，其中重点是理解 PACELC理论 、 BASE理论 等问题，让我们对于分布式一致性的重点是什么有一些认识。

在了解分布式一致性的理论和概念之后，后续将和大家一起讨论分布式一致性协议，其中包括： 2PC、3PC、Paoxs协议、Raft协议 。

篇幅有限，本文重点展开2PC协议，后续文章继续深入。

图(网络)|NASA合成的银河系中心区域图像

2. 单机事务和分布式事务

在聊2PC和3PC之前，我们有必要先了解下 单机事务 和 分布式事务 。

事务是一组原子操作， 要么全成功要么全失败 All or Nothing ，否则就会出现数据混乱，这种需求在 金融和电商 领域很普遍。

试想你去天猫买了台mac，订单服务、扣款服务、库存服务出现任何一个环节的失败都会带来问题，所以就需要事务来做保证， 一荣俱荣一损俱损 。

单机事务具备ACID特性，大家都比较喜欢，但是单机的能力毕竟有限，我们常常必须在分布式场景下同样完成这一组原子操作，也就是分布式事务。

由于分布式系统中各个子服务是部署在 不同的物理节点 上， 不同交换机 、 不同机房、不同城市 ，这样以来，要想 像单机系统一样完成这一组原子操作就没那么容易了 ，因此就出现了很多分布式一致性协议和算法，来解决分布式事务问题保证数据一致性。

分布式系统的各个节点只能依靠 网络 来进行数据通信，但是网络往往 并不完全可靠 ，同时节点 物理故障 也时常发生，在这样一个 复杂的环境 中去保证数据一致性确实不太容易。

3.一致性协议的一些思路

突兀地去学习一个新的协议或者算法往往比较生硬，不如思考一下生活现象，大部分的计算机领域的算法和思想在实际生活中都有映像，又或者说 算法来源于生活 。

举个栗子：在规模盛大的阅兵仪式中会有陆海空多兵种多方队，为了让命令和节奏准确地下达，我们 需要乐曲、指挥、领队、排头、队员等多种角色 。整个活动需要在不同角色的相互作用之下，才能让一个数量庞大的个体组成一个整体来完成一个目标。

再举个栗子：2018年5月在西安举行了一场盛大的 无人机编组飞行灯光秀 ，共计1374架无人机组成一个庞大的编组来完成灯光表演，但是还是出现了问题，并未上演完美图案：

图(网络)|西安无人机编组飞行灯光秀

分布式系统也是如此，为了让很多参与的 机器节点节奏步调一致 ，我们就需要不同的角色各司其职，共同完成一项任务，但是仍然困难重重，因为会有网络故障和节点物理故障等问题。

4. 2PC二阶段提交协议基本过程

要理解2PC协议重点在于 节点角色分工 和 两个阶段所执行的动作 以及 不同情况下的处理逻辑 。

2PC协议总体概览

4.1 节点角色

二阶段提交协议将节点分为： 协调者 和 参与者 ，对于者两种角色，当然你也可以理解为 Leader和大头兵 。

• 协调者Leader

  负责向参与者发送指令，收集参与者反馈，做出提交或者回滚决策

• 参与者大头兵

  接收协调者的指令执行事务操作，向协调者反馈操作结果，并继续执行协调者发送的最终指令

4.2 两个阶段

2PC协议分为： 准备阶段 和 提交阶段 。

4. 2.1 准备 阶 段

协调者向所有参与者节点发送询问并执行事务的命令，参与者节点收到命令后根据自己的状态执行或者不执行事务，并将动作记录下来，最后将对命令的处理结果反馈给协调者。

图|准备阶段的三个环节

1询问环节：协调者向参与者询问，是否准备好可以执行事务，之后协调者开始等待各参与者的响应，这个环节协调者处于阻塞等待状态。

2处理环节：参与者收到协调者的询问后根据自身情况来决定是否执行事务操作，如果参与者执行事务成功，将Undo和Redo信息记入事务日志，但不提交事务；否则直接返回失败。

3响应环节：当参与者成功执行了事务操作，就反馈yes给协调者，表示事务在本地执行；当参与者没有成功执行事务，就反馈no给协调者，表示事务不可以执行提交，这部分反馈对于协调者决策下个阶段起到非常重要的作用。

4. 2.2 准备 阶 段

协调者根据准备阶段收到的参与者反馈来决定最终提交事务或者中断回滚事务，具体来说，当协调者在准备阶段结束时收到的响应反馈有一个no，那么就中断事务，如果收到的反馈全部是yes就提交事务。

情况一: 提交事务 

如果在准备阶段结束时，协调者收到了来自 所有参与者的yes反馈 ，接下来协调者就会向所有参与者发送提交事务指令，具体的过程如下：

步骤1. 协调者向所有参与者发送事务提交消息Commit命令

步骤2. 参与者在收到来自协调者的Commit命令之后，执行事务提交动作，并 释放事务期间所有持有的锁和资源 ，这一步很重要

步骤3. 所有参与者在执行本地事务且释放资源完成后，向协调者发送事务提交确认消息ACK

步骤4. 协调者在收到所有参与者的ACK消息后确认完成本次事务

情况二: 回滚事务 

如果在准备阶段结束时，协调者 没有 收到来自所有参与者的yes反馈，接下来协调者就会向所有参与者发送 回滚事务指令 ，具体的过程如下：

步骤1.协调者向所有参与者发送事务回滚消息Rollback

步骤2.参与者收到Rollback回滚指令后，根据本地的回滚日志来撤销阶段一执行的事务，并释放事务期间所有持有的锁和资源

步骤3.所有参与者在完成指令后向协调者回复反馈ACK

步骤4.协调者在收到所有参与者的ACK确认消息后撤销该事务

通过上面的描述我们知道了，2PC协议通过将节点分为不同的角色，进行两个阶段的处理来执行分布式事务，但是难免要去想2PC协议可以真正解决分布式数据一致问题吗？

5. 2PC协议的异常分析

前面的两个阶段涉及了多次协调者和参与者的网络通信交互，但是我们都知道 网络是不可靠的 ， 节点也能出现故障 ，因此必须要考虑异常情况下2PC协议是否仍然可以正常工作。

故障可以分为很多种： 可恢复机器故障 和 不可恢复机器故障 、 网络正常抖动故障 、 网络分区故障 等多种情况。

2PC整个过程交互也很多， 不同阶段发生不同故障造成的结果也是不一样的， 显然 这是个m*n的组合问题 ，不同的异常情况会产生不同的结果要完全列出来并分析绝非易事，我们找其中几个重点异常来做分析。

从前面的分析我们知道，在 准备阶段本质上是不会提交事务数据的，即使发生故障也可以根据日志来进行回滚，所以不会产生数据不一致的问题 ，但是在提交阶段提交事务的情况下由于可能已经有参与者提交了事务数据，因此可能出现数据不一致，这个是要重点分析的阶段。

注：以下所说的参与者故障并非指全部的参与者，而是其中1个或者几个。

• 协调者故障&参与者正常

协调者作为系统的领导者角色，由于协调者是单点的在任何过程出现异常都需要重点处理，发生不可恢复的物理故障时，选举出新的协调者来接替之前的工作，这时新协调者就需要向所有参与者询问当前的阶段和处理进度，但是如果只是出现网络分区协调者暂时失联，就可能出现脑裂的情况。

• 协调者正常&参与者故障

由于协调者做决策需要依据参与者的反馈，出现参与者故障会造成协调者决策困难，如果参与者的故障是可恢复的，在短时间内恢复后则向协调者询问自己需要做什么，从而跟上节奏，如果时间过长或者是不可恢复故障，那么协调者就会回滚本次事务。

• 协调者故障&参与者故障(重点)

协调者在提交阶段会向所有参与者发送指令，假定在 协调者发送第一条指令之后挂掉 ，此时 只有一个参与者接收到了指令并执行后也挂掉了 ， 其他 参与者并没有收到指令 。

新选举出来的协调者询问所有参与节点状态时，如果 已经挂掉的参与者恢复 了，那么状态就明确了commit或者rollback，如果挂掉的 参与者并没有恢复并且已经执行了commit/rollback操作 ，那么将会 出现数据不一致 ，并且新的协调者由于没有获得足够的信息无法明确当前的状态，其他的参与者在阶段一执行后 产生阻塞 。

• 网络故障

网络分区是个很棘手的问题，极端情况下可能出现几个分区，不同分区中有独自的参与者和协调者。

综上可知，2PC协议在协调者和参与者都挂掉的时候会出现数据不一致，并且在正常的交互过程中会有阻塞情况，以及协调者单点的问题。

6.2PC协议的优缺点

2PC协议的原理简单，实现方便，但是存在 同步阻塞 、 单点问题 、 网络 分区脑裂 、极端情况 数据不一致 的问题，我们具体展开一下。

2PC在准备阶段等待参与者响应反馈时是同步阻塞的，在实际网络中可能会导致长时间阻塞的问题，因为我们无法保证所有参与者网络的顺畅。

协调者在整个两阶段中作用很大，但是存在单点问题，一旦出现协调者故障，所有的参与者都将处于阻塞资源无法释放的情况，从而影响其他操作的进行。

2PC协议整个过程中基于所有参与者的反馈，但是由于异常情况的存在，在一些时候很难达成一致从而回滚事务，整个策略容错性不强，并且网络分区的存在可能产生脑裂造成分区数据不一致。

7.小结

本文对从单机事务和分布式事务的刚需作为切入点，描述了分布式数据一致性的难点和基本解决思路，重点阐述了2PC协议准备阶段和提交阶段的详细过程，最后对2PC协议的异常情况做出分析并给出2PC协议的优缺点。

8.巨人的肩膀

• https://www.cnblogs.com/sunsky303/p/9290992.html

• https://segmentfault.com/q/1010000014439562

• https://www.cnblogs.com/shangxiaofei/p/5196260.html