6.1 什么是共识

业内讨论 Paxos 或 Raft 算法时，常使用“分布式一致性协议”或“分布式一致性算法”来描述。例如，Google Chubby 系统的作者 Mike Burrows 曾评价 Paxos：“There is only one consensus protocol...”，这一句话常被翻译为“世界上只有一种一致性算法”。

尽管“共识”和“一致”在汉语中含义相近，但在计算机领域，这两个术语具有截然不同的含义：

• 共识（Consensus）：指所有节点就某项操作（如选主、原子事务提交、日志复制、分布式锁管理等）达成一致的实现过程。
• 一致性（Consistency）：描述多个节点的数据是否保持一致，关注数据最终达到稳定状态的结果。

本书第五章介绍的 CAP 定理中的 C 和数据库 ACID 模型中的 C 描述的是数据“一致性”属性。而 Paxos、Raft 或者 ZAB 等算法研究的是如何达成一致。因此，将 Paxos 等算法归类到“共识算法”更准确。

在分布式系统中，节点故障不可避免，但部分节点故障不应该影响系统整体状态。通过增加节点数量，依据“少数服从多数”原则，只要多数节点（至少 $\mathit{N/2+1}$）达成一致，其状态即可代表整个系统。这种依赖多数节点实现容错的机制称为 Quorum 机制。

Quorum 机制

• 3 节点集群：Quorum 为 2，允许 1 个节点故障；
• 4 节点集群：Quorum 为 $\mathit{⌈4/2⌉+1 = 3}$，允许 1 个节点故障；
• 5 节点集群：Quorum 为 $\mathit{⌈5/2⌉+1 = 3}$，允许 2 个节点故障。

节点个数为 $\mathit{N}$ 的集群，能容忍 $\mathit{(N-1)/2}$ 个节点故障。你注意到了么？3 节点和 4 节点集群的故障容忍性一致。所以，一般情况下，以容错为目的的分布式系统没必要使用 4 个节点。

根据上述的讨论，基于 Quorum 的机制，在不可靠的环境下，通过“少数服从多数”协商机制达成一致的决策，从而对外表现为一致的运行结果。这一过程被称为节点间的“协商共识”。

一旦解决共识问题，便可提供一套屏蔽内部复杂性的抽象机制，为应用层提供一致性保证，满足多种需求，例如：

• 主节点选举：在主从复制数据库中，所有节点需要就“谁来当主节点”达成一致。如果由于网络问题导致节点间无法通信，很容易引发争议。若争议未解决，可能会出现多个节点同时认为自己是主节点的情况，这就是分布式系统中最棘手的问题之一 —— “脑裂”。
• 原子事务提交：对于支持跨节点或跨分区事务的数据库，可能会发生部分节点事务成功、部分节点事务失败的情况。为维护事务的原子性（即 ACID 特性），所有节点必须就事务的最终结果达成一致。
• 分布式锁管理：当多个请求尝试访问共享资源时，共识机制可确保所有节点一致认定“谁成功获取了锁”。即使发生网络故障或节点异常，也能避免锁争议，从而防止并发冲突或数据不一致。
• 日志复制：日志复制指将主节点的操作日志同步到从节点。在这一过程中，所有节点必须确保日志条目的顺序一致，即日志条目必须以相同顺序写入（顺序非常重要，笔者将在下一节详细说明）。

Star 关注

总字数:940字