漫话：如何给女朋友解释什么是2PC（二阶段提交）？
周末晚上，正在家里面看综艺节目，突然女朋友跑过来找我打《王者荣耀》。
打了几把游戏，终于可以歇息一会了，准备继续看我的综艺，可是女朋友过来找我给他讲讲到底什么是二阶段提交。
还好我们之前专门给女朋友介绍过什么是分布式，要不然这个话题说来就话长了。
在之前介绍分布式的时候，我们以饭店的后厨为例，今天继续之前的例子来说说什么是分布式一致性。
随着饭店的发展，慢慢的从只有一个厨师演变成有多个厨师，进而演变成有洗菜工、配菜师、厨师等多个职位。
当有了多种分工之后，就势必需要协调这些人之间的合作。
比如餐厅客人点了一份番茄炒蛋，然后后厨开始准备起来，洗菜工开始洗西红柿，配菜师开始准备鸡蛋，厨师开始向锅内加油准备炒菜。这是一种很正常的情况。
但是，如果消息传达的不到位，或者洗菜师傅临时不在厨房等，就会导致有的人已经开始准备起来，但是有的人并没有准备。
这就像是一个分布式系统一样的，当我们在电商网站下单的时候，需要有多个分布式服务同时服务，如支付系统进行支付、红包系统进行红包扣减、库存系统扣减库存、物流系统更新物流信息等。
但是，如果其中某一个系统在执行过程中失败了，或者由于网络原因没有收到请求，那么，整个系统可能就有不一致的现象了，即：付了钱，扣了红包，但是库存没有扣减。
这就是所谓的分布式系统的数据一致性问题。
之所以刚刚的例子中会出现一致性问题，就是因为每一个员工都只关注自己所做的事情，无法关注到其他人，那么，要想保证整体的一致性，就需要在后厨中引入一个新的角色，负责统筹，这个角色来进行协调和调配所有人。
那么，引入一个协调者负责协调所有参与者的工作，这个在分布式系统中其实就是X/Open组织定义的分布式事务处理模型，而二阶段提交就是根据这一模型衍生出来的。
举个例子，五个人相约打王者荣耀，想要一起玩需要以下几个步骤：
有一个人想要五黑玩王者荣耀，于是他开始联系自己的小伙伴们。
组织者：小A，我们准备玩王者荣耀，你要是可以来参加的话，现在你就登录游戏，然后在游戏好友上给我回复个消息。
小A登录自己的游戏账号，然后告诉组织者：小A已就位。
组织者：小B、小C、小D，我们准备玩王者荣耀，你要是可以来参加的话，现在你就登录游戏，然后在游戏好友上给我回复个消息。
小B、小C、小D分别登录自己的游戏账号，然后告诉组织者：小B、小C、小D已就位。
组织者发现所有人都就位了，于是在游戏上逐一通知大家，
组织者：小A，我邀请你了，你进来吧。
小A接受邀请
组织者：小B、小C、小D，我邀请你了，你进来吧。
小小B、小C、小D接收邀请
于是，5个人在王者峡谷愉快的玩耍了起来。
对于五个人开黑这个事务操作，在开始准备前五个人都是空闲状态，忙着自己的事情。在组织者协调过之后，大家也要达成一个一致的状态，即以下两种情况之一：
1、五个人愉快的开始一起玩游戏
2、五个人都退出游戏，还是去忙自己的事情。
如果最后有一部分人在游戏里一直等，另外一部分并没有进入游戏，那么就是数据不一致了。
以上过程，就是一个典型的二阶段提交（2PC）的过程，在分布式系统中，也有同样的问题，并且可以采用同样的解决办法。
在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败（只知道自己有时间可以玩王者荣耀，不知道其他人有没有）。
当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有参与者的操作结果并最终指示这些节点是否要把操作结果进行真正的提交（组织者通知各位参与者一起进入游戏房间）。
因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）
准备阶段
事务协调者给每个参与者发送Prepare消息，每个参与者要么直接返回失败（告知组织者自己没时间，不能一起玩游戏），要么在本地执行事务（登录王者荣耀），但不提交（先不开始游戏）。
可以进一步将准备阶段分为以下三个步骤：
1）协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。（询问是否可以一起玩游戏）
2）参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（登录王者荣耀游戏）
3）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；（告知组织者自己已经登录成功）如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。（告知组织者自己暂时无法一起玩游戏，如自己的账号被限制无法打排位）
提交阶段
如果协调者收到了参与者的失败消息或者超时（有人不能一起玩游戏，或者一直没有回复），直接给每个参与者发送回滚消息（告知其他人，暂时取消游戏）；否则，发送提交消息（邀请大家进入游戏房间）；参与者根据协调者的指令执行提交或者回滚操作（进入房间一起玩游戏或者退出游戏去做别的事情）。
接下来分两种情况分别讨论提交阶段的过程。
当协调者节点从所有参与者节点获得的相应消息都为”同意”时:
1）协调者节点向所有参与者节点发出”正式提交”的请求（要求所有已登录的朋友加入游戏房间）。
2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源（接受邀请，进入房间）。
3）参与者节点向协调者节点发送”完成”消息（点击"准备"，进入准备状态）。
4）协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务（进入王者峡谷）。
如果任一参与者节点在第一阶段返回的响应消息为”中止”，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：
1）协调者节点向所有参与者节点发出”回滚操作”的请求（告知所有人取消游戏）。
2）参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源（退出游戏，去做自己的事情）。
3）参与者节点向协调者节点发送”回滚完成”消息（告诉组织者自己知道了，后面有机会再玩）。
4）协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务（取消本次游戏活动）。
以上过程其实是有一些缺点的，如
1、当参与者收到组织者的消息之后，需要登录游戏，在游戏中等待组织者的再次邀请，这个过程比较浪费时间。
2、如果在这个过程中，组织者突然有什么事情被打断了，那么那些已经进入游戏的参与者就可能一直等下去。
3、在所有人都登录游戏之后，组织者通过邀请要求所有人加入他的房间，这时候如果有一些网络异常、或者参与者没在手机前面等情况，可能会有一部分用户加入了房间，有一部分没加入。
4、如果组织者在游戏中开始邀请所有参与者的时候，他邀请了第一个人之后，他和这个被他邀请的人都掉线了。这时候另外三个人就不知道到底应该怎么办了。
以上问题，分布式系统的2PC阶段一样存在，分别对应以下问题：
1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
总结一下，就是说2PC并不是完美的，他存在着同步阻塞问题、单点故障问题、无法100%保证数据一致性等问题。
推荐阅读：
好文章，我 在看