一顿愉快的小火锅之后，悠哉悠哉的回家了，于是只能开始新一轮的家庭科普了。

分布式一致性

幸好在《漫话：如何给女朋友解释什么是2PC（二阶段提交）？》中介绍过关于2PC的知识，要不然这事儿可就说来话长了。

不过还是要简单交代下背景。我们以饭店的后厨为例介绍过：

随着饭店的发展，慢慢的从只有一个厨师演变成有多个厨师，进而演变成有洗菜工、配菜师、厨师等多个职位。

当有了多种分工之后，就势必需要协调这些人之间的合作。

比如餐厅客人点了一份番茄炒蛋，然后后厨开始准备起来，洗菜工开始洗西红柿，配菜师开始准备鸡蛋，厨师开始向锅内加油准备炒菜。这是一种很正常的情况。

但是，如果消息传达的不到位，或者洗菜师傅临时不在厨房等，就会导致有的人已经开始准备起来，但是有的人并没有准备。

这就像是一个分布式系统一样的，当我们在电商网站下单的时候，需要有多个分布式服务同时服务，如支付系统进行支付、红包系统进行红包扣减、库存系统扣减库存、物流系统更新物流信息等。

但是，如果其中某一个系统在执行过程中失败了，或者由于网络原因没有收到请求，那么，整个系统可能就有不一致的现象了，即：付了钱，扣了红包，但是库存没有扣减。

这就是所谓的分布式系统的数据一致性问题。

为了解决分布式一致性问题，人们提出了很多解决方案，其中比较重要的就是2PC和3PC。之前我们介绍过了2PC，其实就是相当于在后厨引入一个协调者，他负责统筹所有参与者。

二阶段提交的算法思路是在分布式系统中引入了协调者，参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

那么整个操作被分为两个阶段：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）

但是，同时，2PC也存在一些缺点，如同步阻塞问题、单点故障问题、无法100%保证数据一致性等问题。所以人们在2PC的基础上提出了3PC算法。

三阶段提交

在二阶段提交（2PC）存在诸多问题的情况下，人们提出了三阶段提交（3PC），主要用来解决2PC存在的一些问题（但是这里提一句，3PC并没彻底解决2PC存在的所有问题）。

有一个人想要五黑玩王者荣耀，于是他开始联系自己的小伙伴们。

采用2PC的算法召集好友开黑时，会发生以下事情：

组织者：小A，我们准备玩王者荣耀，你要是可以来参加的话，现在你就登录游戏，然后在游戏好友上给我回复个消息。

小A登录自己的游戏账号，然后告诉组织者：小A已就位。

组织者：小B、小C、小D，我们准备玩王者荣耀，你要是可以来参加的话，现在你就登录游戏，然后在游戏好友上给我回复个消息。

小B、小C、小D分别登录自己的游戏账号，然后告诉组织者：小B、小C、小D已就位。

组织者发现所有人都就位了，于是在游戏上逐一通知大家，

组织者：小A，我邀请你了，你进来吧。

小A接受邀请

组织者：小B、小C、小D，我邀请你了，你进来吧。

小小B、小C、小D接收邀请

接着我们看下，如果采用3PC的方式组织王者荣耀五黑，会发生怎样的事情：

组织者：小A，我们想定在晚上8点，你有时间嘛？有时间你就说YES，没有你就说NO，然后我还会再去问其他人，这段时间你可先去干你自己的事儿，不用一直等着我。

小A：好的，我有时间。

组织者：小B、小C、小D，我们想定在晚上8点王者荣耀五黑……不用一直等我。

组织者收集完大家的时间情况了，一看大家都有时间，那么就再次通知大家。（协调者接收到所有YES指令）

组织者：小A，我们确定了晚上8点王者荣耀五黑，你要把段时间空出来，你不能再安排其他的事儿了。然后我会逐个通知其他朋友，通知完之后我会再来和你确认一下，还有啊，如果我没有特意给你打电话，你就8点上号就行了。对了，你确定能来是吧？

小A顺手设置了晚上8点闹钟，然后跟组织者说，我可以去。

组织者：小B，我们决定了晚上8点王者荣耀五黑……你就8点上号就行了。

组织者通知完一圈之后。所有朋友都跟他说：”我已经把8点这个时间段空出来了”。于是，他在8点的时候这一天又挨个打了一遍电话告诉他们：嘿，现在你们可以上号啦。。。。

小A、小B、小C、小D：我已经登录了，你拉我吧。

组织者邀请A、B、C等加入游戏。

以上过程，就是一个典型的三阶段提交（3PC）的过程，和2PC相比，3PC多了一个步骤，就是提前询问所以参与者是否都能参与，并且所有人都同意后再次通知大家登录游戏。

所谓3PC，就是把2PC的准备阶段再次一分为二，组成了三阶段。

在第一阶段，只是询问所有参与者是否可以执行事务操作，并不在本阶段执行事务操作。当协调者收到所有的参与者都返回YES时，在第二阶段才执行事务操作，然后在第三阶段在执行commit或者rollback。

这样三阶段提交就有CanCommit（事务询问）、PreCommit（事务执行）、DoCommit（事务提交）三个阶段。

3PC的处理过程

和二阶段提交对比，三阶段提交主要是在2PC的第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

接下来看看具体执行过程。

CanCommit

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

1、事务询问：协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。

2、响应反馈：参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回YES响应，并进入预备状态。否则反馈NO

PreCommit阶段

协调者根据CanCommit阶段参与者的反应情况来决定是否可以进行事务的PreCommit操作。

假如协调者从所有的参与者获得的反馈都是YES响应，那么就会执行事务的预执行：

1、发送预提交请求：协调者向参与者发送PreCommit请求，并进入Prepared阶段。

2、事务预提交：参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。

3、响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

假如有任何一个参与者向协调者发送了NO响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。

1、发送中断请求：协调者向所有参与者发送abort请求。

2、中断事务：参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况。

如果协调证收到所有参与者的事务执行后的ACK响应，则发生如下事情：

1、发送提交请求：协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。

2、事务提交：参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。

3、响应反馈：事务提交完之后，向协调者发送Ack响应。

4、完成事务：协调者接收到所有参与者的ack响应之后，完成事务。

如果协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。

1、发送中断请求：协调者向所有参与者发送abort请求

2、事务回滚：参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

3、反馈结果：参与者完成事务回滚之后，向协调者发送ACK消息

4、中断事务：协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

还有一种情况，如果参与者无法及时接收到来自协调者的doCommit或者abort请求时，会在等待超时之后，会继续进行事务的提交。

以上，就是3PC的三个主要阶段的操作流程。

3PC比2PC好在哪？

1、降低同步阻塞。

在3PC中，第一阶段并没有让参与者直接执行事务，而是在第二阶段才会让参与者进行事务的执行。大大降低了阻塞的概率和时长。并且，在3PC中，如果参与者未收到协调者的消息，那么他会在等待一段时间后自动执行事务的commit，而不是一直阻塞。

2、提升了数据一致性

2PC中有一种情况会导致数据不一致，如在2PC的阶段二中，当协调者向参与者发送commit请求之后，发生了网络异常，只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

这种情况在3PC的场景中得到了很好的解决，因为在3PC中，如果参与者没有收到协调者的消息时，他不会一直阻塞，过一段时间之后，他会自动执行事务。这就解决了那种协调者发出commit之后。

另外，2PC还有个问题无法解决。那就是协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

这种情况在3PC中是有办法解决的，因为在3PC中，选出新的协调者之后，他可以咨询所有参与者的状态，如果有某一个处于commit状态或者prepare-commit状态，那么他就可以通知所有参与者执行commit，否则就通知大家rollback。因为3PC的第三阶段一旦有机器执行了commit，那必然第一阶段大家都是同意commit的，所以可以放心执行commit。

3PC无法解决的问题

在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者abort请求时，会在等待超时之后，会继续进行事务的提交。

所以，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

所以，我们可以认为，无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。

Google Chubby的作者Mike Burrows说过：

there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos。

意即世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。

关于作者：漫话编程，是一个通过漫画+音频的形式讲解枯燥的编程知识的公众号。致力于让编程变得更有乐趣。

有道无术，术可成；有术无道，止于术

欢迎大家关注Java之道公众号

好文章，我在看❤️