一致性与共识

5.1一致性模型：一把从强到弱的梯子

第 04 章给出了一个旋钮：写到几个副本（W）、读几个副本（R）、同步还是异步。旋钮拧到不同位置，一次读看到的"新鲜度"就不同。把所有可能的新鲜度按强弱排成一列，就是一致性模型（consistency model）——它是系统对外承诺的"读保证"，定义了一次读最坏会看到多旧的数据、几个并发读之间会不会互相矛盾。

一致性模型不是"对错"的开关，而是"系统答应你看到多新的数据"的等级；越强的等级要求副本之间协调得越紧，协调要花延迟、要等多数派，分区时还可能根本无法满足。

从强到弱，常用的五级是：线性一致（linearizable）> 顺序一致（sequential）> 因果一致（causal）> read-your-writes（读到自己刚写的）> 最终一致（eventual）。逐级拆开看它们各自承诺了什么、又靠放弃什么换来更便宜：

• 线性一致：存在一个全局实时顺序，每次读都返回"此刻之前最后一次写"的结果——对外表现得像只有一份数据，副本是透明的。代价：写必须等到足够多副本达成一致才能返回，每次读要么走多数派要么靠租约，延迟最贵；分区时一侧根本拿不到多数派，无法满足。
• 顺序一致：所有节点看到的操作顺序一致，但这个顺序不必和真实时间对齐（你的写可能"晚一点"才对别人可见，只要大家看到的相对顺序相同）。比线性一致松一点——不要求实时性，于是不必为每次操作做实时对齐。
• 因果一致（causal）：只对存在 happens-before（因果先后，如"先发帖再有人回帖"）关系的操作排序；互不相关的并发操作允许在不同副本上以不同顺序出现，即允许分叉。正因为它不强求给并发操作定一个全局顺序，它能在网络分区下继续工作，而线性一致不能——这是因果一致在工程上格外重要的原因。
• read-your-writes：只保证同一个客户端能读到自己刚提交的写，不管别人。这是把"全局一致"缩小到"单条会话内一致"的廉价折中——第 04 章里"用户发完评论刷新却看不到"的复制延迟问题，就是这一级被破坏。
• 最终一致（eventual）：只承诺"如果停止写入，所有副本最终会收敛到同一值"，但不保证"最终"是多久，期间读到任意旧值都合法。最便宜、最高可用，绝大多数无主/异步复制系统的默认级别。

5.2CAP 精读：它到底说了什么、没说什么

CAP 是 Eric Brewer 2000 年提出、Gilbert 与 Lynch 2002 年证明的一条定理。它常被压缩成一句口号"一致性、可用性、分区容忍三选二"——这句口号是误读，而且是会把人引到错误权衡上的那种误读。先把它准确地说清楚。

CAP 里的三个字母有非常具体的含义，含义错了整条推理就错：

• C（一致性）= 线性一致，注意不是泛泛的"数据正确"，而是 5.1 梯子最顶端那一级：每次读都见到全局最新写。
• A（可用性）= 每个非故障节点对收到的请求都返回非错误响应（哪怕数据是旧的）。这个定义很严格——多数派系统在少数派那一侧会直接返回错误，按 CAP 的字面定义它在那一侧"不可用"，尽管工程上大家仍称这类系统高可用。
• P（分区容忍）= 系统在节点间消息任意丢失/延迟时仍能继续运转。

关键在于：P 在真实网络里不是一个可选项。网络一定会丢包、会延迟、会断链，分区迟早发生，没有哪个分布式系统能选择"不容忍分区"——选了就等于宣布断网即全挂。所以"三选二"里把 P 当成可放弃的一项，是空想。CAP 真正说的是一条条件取舍：

把它接回本教程的主线：CAP 的全部难题，正是 03 章的切分加 04 章的复制共同制造出来的。没有复制就没有"另一侧的新写"，也就没有"陈旧 vs 拒绝"的两难——一致性问题是"状态被切分又被复制"的下游产物，而不是凭空冒出来的新麻烦。

5.3PACELC：CAP 漏掉的另一半

Daniel Abadi 在 2010 年指出 CAP 只描述了一半的世界——它只谈"分区时怎么办"，对"不分区时（绝大多数时间）怎么办"只字未提。PACELC 把这一半补上，读作"P-A-C / E-L-C"：

如果发生分区（Partition），在可用性（A）与一致性（C）间取舍；否则（Else，网络健康时），在延迟（Latency）与一致性（C）间取舍。

前半句 PAC 就是 CAP；真正的新信息是后半句 ELC。它点破了一个天天发生、却被 CAP 框架完全遮住的事实：哪怕网络完全健康、根本没有分区，强一致依然不是免费的——要让一次读见到全局最新写，就得等一个 quorum 往返（5.1 已说明），这一来一回是实打实的延迟。想砍掉这段延迟，就只能放松一致性，让最近的副本不等协调、立即作答。

5.4多数派 overlap：共识为什么是安全的

从"该不该一致"转到"凭什么能一致"。第 04 章已经用过 quorum：写 W 个、读 R 个，令 W+R>N 则读集与写集必有交集，于是读到的副本里至少有一个带着最新版本。共识（多个节点对"哪个值/谁是 leader"达成一致并不再反悔）站在同一块地基上，只是把它用到了更要命的地方——选主和提交。这块地基就是多数派 overlap。

N 个节点里，任意两个多数派（各 ≥ ⌊N/2⌋+1 个节点）必然至少共享一个成员——因为 2×(⌊N/2⌋+1) > N，两个都超过半数的集合不可能完全不重叠（鸽巢原理）。这是集合相交，是确定性事实，不是"碰运气才会撞上"。

这一条确定性交集，撑起了共识的全部安全性：

• 选主不会选出两个 leader：当选 leader 需要拿到一个多数派的票。两个候选人都想当选，就各需要一个多数派，但两个多数派必相交——那个交集里的节点不可能把票同时投给两人（一个 term 内每个节点只投一票），所以同一任期里最多一个 leader。脑裂在这里被从根上掐死。
• 已提交的数据不会丢：一条日志被"提交"意味着它已写入一个多数派。下一任 leader 的选举多数派，与这个提交多数派必相交——交集里那个节点手上就有这条已提交日志，新 leader 必然看得到它，于是不会用一段缺了它的历史去覆盖。
• 少数派只能停摆，不能分叉：被分区切到少数派那一侧的节点凑不齐多数派，既选不出 leader 也提交不了新日志——它只能停下来等，而不会另起一段相互矛盾的历史。可用性在这一侧被牺牲（正对应 CAP 的 C>A），换来的是整个系统永不分叉。

5.5Raft：把共识拆成两件可理解的事

多数派 overlap 说明了共识"为什么安全"，但没说"具体怎么跑"。Paxos 给出过一套正确的跑法，却以晦涩著称，工程实现里 bug 频出。Raft（Ongaro & Ousterhout, 2014）的设计目标直白写在标题里——可理解的共识：它和 Paxos 拥有完全相同的多数派安全保证，但把整件事拆成两个相对独立、各自好懂的子问题。

Raft 今天已是事实标准，etcd（Kubernetes 的元数据存储）、Consul、TiKV、Kafka 的 KRaft 模式都用它，已经把 Paxos 挤到了教科书里。它把共识拆成的两件事是：

① 选主（leader election）

任何时刻最多一个 leader，所有写都先到 leader。每个节点有一个随机的选举超时；谁先超时谁就自增 term（任期号，单调递增的逻辑时钟）、变成候选人、向所有节点拉票，拿到一个多数派的票就当选。随机超时是点睛之笔：它让多个节点几乎不会同时超时去抢，避免选票被平分而反复流选——用随机性打破对称，而不是靠精确的时钟。安全则来自 5.4：一个 term 内多数派只会产生一个 leader。

② 日志复制（log replication）

leader 把每条写当作一个日志条目追加到自己的日志，再并行发给 followers。当一个条目被复制到多数派后，leader 才把它标记为 committed（已提交）并应用到状态机、回复客户端。又是同一条多数派规则：提交即"进了一个多数派"，于是 5.4 保证它跨越选主永不丢失。followers 的日志和 leader 不一致时，以 leader 为准强制对齐——单一强 leader 让整条日志被线性化成一个唯一序列，这正是 Raft 比 Paxos 好实现的根本原因（Paxos 允许多个提案者并发，日志不天然成线）。

5.6选型对比与两个常见陷阱

把全章拧成一张选型表。最核心的取舍是强一致 vs 最终一致——这是 5.1 梯子两端，也是 5.2 / 5.3 那两套框架真正落地的地方：

表里最容易被忽略的是"代价落在哪"这一行：强一致的痛主要落在健康时的延迟（天天付），最终一致的痛主要落在分区时的不一致窗口（偶发但要会兜底）。看错痛点，就会在错误的地方做优化。