分布式系统一致性之3PC协议

二.3PC的出现

之前文章中提到了 2PC 协议存在的协调者单点、参与者阻塞超时、网络分区、容错性等问题，这些在某些程度上是做优化和调整的，并不是致命问题。我们对 2PC 协议的异常情况做了拆解，但是那是个m*n的组合问题，我们尽量去分析主要矛盾，于是发现在协调者和唯一接收指令的参与者都出现不可恢复宕机时，即使后面选举了新的协调者，仍然可能出现数据的不一致性。3PC 的出现可能是多种因素促成的。但是基本上可以确定 3PC 将对 2PC 存在的问题进行修正和优化，但是这样并不意味着 3PC 不会引入新的问题。本文将从 3PC 的协议过程来阐述这两大块内容:

 

协调者和参与者等待超时情况单独说，先看正常情况的基本过程，要不然容易混淆。

3.1 CanCommit阶段

在2PC准备阶段中，协调者向参与者发送指令后，参与者如果具备执行条件，则获取锁并执行动作，只不过未真正提交，可以认为参与者就差临门一脚了，还得等协调者信号。如果是 commit 信号那还好，如果是 rollback 信号，那么对于一些本地执行了动作的参与者来说白白浪费了，所以从这个角度来说，2PC 有点激进了，但是这么做也是有原因的，在复杂的网络环境中多一轮交互意味着性能的损耗。3PC来说更加合理，先由协调者向参与者发送询问信号，兄弟们有档期吗??然后开始收集反馈，相比来说更加轻量。这个阶段参与者并不真实获取锁占用资源，只是对自身执行事务状态的检查，查看是否具备执行事务的条件，进而回复询问。

根据参与者对询问的反馈，在 CanCommit 阶段可能出现的两情况：

A.所有参与者均Ready的场景

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!