一.写在前面 分布式系统一致性专题本期该写 3PC 协议了，上周太忙没有时间更新，就拿了之前的旧文章做了一些调整重发了一下，还望各位读者海涵。 后面大约还有3期：Paxos 协议、Raft 协议等，先预热一下。 温馨提示：本篇文章并不会枯燥，换了个画图工具，对于我这种建筑专业出身的IT狗来说，画图简直是最开心的事情了，所以放心看吧！ 图(网络)|猎户座大星云 二.3PC的出现 之前文章中提到了 2PC 协议存在的协调者单点、参与者阻塞超时、网络分区、容错性等问题，这些在某些程度上是做优化和调整的，并不是致命问题。 我们对 2PC 协议的异常情况做了拆解，但是那是个m*n的组合问题，我们尽量去分析主要矛盾，于是发现在协调者和唯一接收指令的参与者都出现不可恢复宕机时，即使后面选举了新的协调者，仍然可能出现数据的不一致性。 3PC 的出现可能是多种因素促成的。 但是基本上可以确定 3PC 将对 2PC 存在的问题进行修正和优化，但是这样并不意味着 3PC 不会引入新的问题。 本文将从 3PC 的协议过程来阐述这两大块内容: 三. 3PC协议的基本过程 3PC协议 Three-Phase-Commit 又称三阶段提交协议，相比 2PC 协议增加了一个阶段，因此我们普遍把 3PC 协议看作是 2PC 协议的改进版本。 3PC 协议将 2PC 协议的准备阶段一分为二，从而形成了三个阶段： 协调者和参与者等待超时情况单独说，先看正常情况的基本过程，要不然容易混淆。 3.1 CanCommit阶段 在2PC准备阶段中，协调者向参与者发送指令后，参与者如果具备执行条件，则获取锁并执行动作，只不过未真正提交，可以认为参与者就差临门一脚了，还得等协调者信号。 如果是 commit 信号那还好，如果是 rollback 信号，那么对于一些本地执行了动作的参与者来说白白浪费了，所以从这个角度来说，2PC 有点激进了，但是这么做也是有原因的，在复杂的网络环境中多一轮交互意味着性能的损耗。 3PC来说更加合理，先由协调者向参与者发送询问信号，兄弟们有档期吗？？然后开始收集反馈，相比来说更加轻量。 这个阶段参与者并不真实获取锁占用资源，只是对自身执行事务状态的检查，查看是否具备执行事务的条件，进而回复询问。… Continue reading 浅谈分布式系统一致性之3PC协议