给你女朋友解释一下什么是2PC（两相传输）？

玩了几局，终于休息了，准备继续看综艺，女朋友却过来给我解释什么是两步退出。

分布式一致性

还好我们给女朋友介绍了什么是分布式，不然这个话题就说来话长了。

前面介绍配送时，我们以酒店厨房为例。今天我们继续前面的例子来谈谈什么是分布式一致性。

随着酒店的发展，慢慢从一个厨师演变为几个厨师，再演变为洗碗工、副厨、厨师等多重角色。

当有多个分工时，这些人之间的配合必须协调。

比如，餐厅客人点了西红柿炒鸡蛋，厨房开始准备，洗碗机开始洗西红柿，副厨开始准备鸡蛋，厨师开始加油。煎锅。这是非常正常的情况。

不过，如果消息传达不好，或者师傅暂时不在厨房等等，有的人已经开始准备，有的人还没有。

这就像一个分布式系统。当我们在电商网站下订单时，需要同时服务几个去中心化的服务，比如支付系统、红包减免的红包系统、仓库系统等。库存减少、物流系统更新物流信息等。

但是如果其中一个系统在执行过程中出现故障或者由于网络原因没有收到请求，整个系统可能会出现不一致的情况，即钱到账了，红包减少了，但库存没有减少。

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

两步提交

之所以现在的例子存在一致性问题，是因为每个员工只专注于自己正在做的事情，而无法关注其他人。那么，为了保证整体的一致性，就需要在厨房中引入一个新的角色来协调和协调大家。

然后引入一名协调员来协调所有参与者的工作。这实际上是X/Open组织定义的分布式系统中的分布式事务处理模型，两阶段提交就是从这个模型衍生出来的。

比如，五个人聚在一起玩王者荣耀。如果他们想一起玩，需要以下步骤：

一个人想让无黑玩王者荣耀，于是他开始与朋友联系。

主办方：小A，我们玩王者荣耀。如果您能来参加，请立即登录游戏并告诉我您的游戏好友。

小A登录自己的游戏账号，然后告诉主办方：小A就位。

在小B、小C、小D的组织下，我们要玩王者荣耀。如果你能来参加，请立即登录游戏并在游戏好友上回复我。

小B、小C、小D登录自己的游戏账号，然后告诉主办方：小B、小C、小D就位。

主办方发现大家都就位了，就一一向大家宣布了比赛，

主办方：小A，我叫你了，进来吧。

小A接受邀请主办方：小B、小C、小D，我邀请你们了，进来吧。

小B、小C、小D接受了邀请

于是，他们五个人就开始在国王峡谷里快乐地玩耍了。

在五个人打开黑洞的交易操作中，五个人闲来无事，忙着自己的事情，才开始准备。经主办方协调后，大家必须达成一致，即有以下两种情况之一：

• 1。五个人开始一起快乐的游戏
• 2。五个人全部退出游戏或者忙于自己的事情。

如果最终有些人在游戏中等待，而另一些人没有进入游戏，数据就会不一致。

上述过程是典型的两阶段确认过程（2PC）。去中心化系统也存在同样的问题，可以实施同样的解决方案。

在去中心化系统中，每个节点可以知道自己操作的成功或失败，但无法知道其他节点操作的成功或失败（它只知道自己有时间玩王者荣耀，但不知道其他节点操作的成功或失败）。不知道别人有没有）。

当事务跨越多个节点时，为了保留事务的ACID属性，必须实现一个组件作为协调器，统一控制所有参与者的操作结果，并最终指示这些节点操作是否真正提交。结果。 （主办方邀请所有参赛者一起来到游戏室）。

因此，两步发送的算法思想可以概括为：参与者通知协调器操作成功或失败，之后协调器决定每个参与者是否要发送操作或中止操作手术。该操作基于所有参与者的反馈。

所谓两个阶段是指：第一阶段：准备阶段（投票阶段）第二阶段：提交阶段（执行阶段）

准备阶段事务协调器向每个事务发送Prepare消息参与者，每个参与者要么直接返回错误（通知组织者他没有时间，不能一起玩游戏），要么在本地运行事件（登录王者荣耀）但不发送（还没有）。开始游戏）。

准备阶段又可分为以下三个阶段：

• 1）协调节点向所有参与节点询问是否可以进行发送操作，并开始等待各参与节点的响应。（问能不能一起玩游戏）
• 2）参与者节点执行所有事件操作，直到调查开始，并将Undo和Redo信息写入日志。 （登录王者荣耀游戏）
• 3）各参与节点响应协调节点发起的轮询。如果参与节点的交易函数确实执行成功，则返回“同意”消息； （通知组织者已登录成功）如果参与者节点的事件操作失败，则返回“abort”消息。 （通知主办方暂时无法一起进行游戏，例如账号被限制，无法进行排位赛）

提交阶段

如果协调员收到参赛者的失败通知或超时（有人无法玩）一起玩游戏或未应答），直接向每个参与者发送回滚消息（通知其他人暂时取消游戏）；否则，发送广播消息（邀请所有人进入游戏室）；参与者根据协调员的指示完成传输或取消动作（进入房间一起玩游戏或离开游戏去做其他事情）。

接下来我们分两种情况来讨论发送阶段的流程。

当协调者节点收到来自所有参与者节点的对应消息为“我接受”时：

• 1）协调者节点向所有参与者节点发送“正式广播请求”（要求所有登录的好友加入游戏）房间）。
• 2）参与节点正式执行操作，释放整个活动期间预留的资源（接受邀请，进入房间）。
• 3）参与者节点向协调节点发送“完成”消息（点击“准备”进入准备模式）。
• 4）当协调节点收到所有参与节点的“完成”消息后，事件完成（到达国王峡谷）。

如果第一步中某个参与节点返回的响应消息被“中断”或者协调节点在第一步查询超时之前无法收到所有参与节点的响应消息：

• 1 ）协调者节点向所有参与节点发送“返回动作”请求（邀请所有人取消游戏）。
• 2）参与者节点使用之前写入的Undo数据进行回滚，释放整个事件期间保留的资源（退出游戏，做自己的事情）。
• 3）参与者节点向协调者节点发送“返回完成”消息（告诉组织者它知道，如果以后有机会的话将再次播放）。
• 4）当协调节点收到所有参与节点的“返回完成”消息后，取消交易（取消本次游戏操作）。

2 PC 的缺点

上述过程实际上存在一些缺点，例如

1。参与者收到组织者的消息后，必须登录游戏并等待组织者再次邀请他加入游戏。这个过程相当耗时。

2。如果在这个过程中组织者突然打断什么事情，已经参加游戏的参与者可以继续等待。

3。当每个人登录游戏时，组织者会通过邀请邀请每个人加入他们的房间。目前，如果网络出现异常或者参与者不在手机前，部分用户可以加入。房间的某些部分没有添加。

4。如果组织者开始邀请所有参与者加入游戏，则在他邀请第一个人之后，他和他邀请的人都会离线。此时，其他三人已经不知道该怎么办了。

上述问题在分布式系统的2PC阶段也会出现，对应以下问题：

1、同步阻塞问题。

执行过程中，所有参与节点都会阻塞事件。当参与者使用公共资源时，必须阻止其他第三方节点使用公共资源。

2，一个瑕疵。

由于协调器的重要性，当协调器出现故障时。参与者仍处于封锁状态。特别是在第二阶段，如果协调者发生故障，所有参与者仍处于事务资源锁定状态，无法继续执行事务操作。 （如果协调员挂断，可以重拨协调员，但不能解决协调员不在时参与者被屏蔽的问题）

3、数据不一致。

在两阶段传输的第二阶段，协调器向参与者发送承诺请求后，本地网络发生异常或协调器在传递请求传输过程中失败。这次只有部分参与者接受了。发出请求。这部分参与者收到发货请求后，进行发货操作。然而，其他未收到传送请求的机器无法完成交易传输。这样一来，整个分布式系统是数据一致的。

4。第二步无法解决的问题：

协调者再次发送确认消息后宕机，同时唯一的参与者也收到了该消息。那么即使协调者通过选举协议创建了一个新的协调者，这个事件的状态也是不确定的，没有人知道这个事件是否已经被发送了。

综上所述，2PC 并不完美。存在同步阻塞、单点故障、无法保证100%数据一致性等问题。

作者：漫画编程
链接：https://juejin.im/post/5d6c7821518825415d062509
来源：掘金属于作者商业转载请联系作者获得许可。非商业转载请注明出处。