复制与一致性

一句话

复制（replication）是为了可用，而一致性模型（consistency model）是为复制开出的账单。副本一多，「数据库返回了一个值」就不再自明——你必须先约定「哪些返回值算合法」。本章把这个约定做成一条可精确定义的谱系：从寄存器语义（safe / regular / atomic）到线性一致、顺序一致、因果一致、会话保证、最终一致，再到无需协调就能收敛的 CRDT。要建立的认知是：一致性不是性能旋钮，是合约——你调 quorum 调出来的，往往不是你以为的那一档。

Glossary · 术语表

坐标

本章属 Part II「分布式系统」，是 Ch8（分布式引论）→ Ch9（故障检测）→ Ch10（领导者选举）之后的第四站：前三章解决「谁还活着、谁说话算数」，本章追问「多副本之下，一次读该返回什么」。下接 Ch12（反熵与传播：只保证最终一致时，用 gossip / Merkle 树 / 读修复把副本拉回来）与 Ch13–14（分布式事务与共识：把最强那档真正实现出来）。对应现实里 Cassandra / DynamoDB 的一致性级别、ZooKeeper / etcd 的线性一致读、Spanner 的外部一致性。

这章要解决什么

可用性靠冗余，冗余意味着多份副本，而多份副本会短暂地不一样——于是一个看似无需定义的问题变成了必须定义的合约：读，该返回哪一份？

具体化：一个三副本、跨三可用区的键值存储，写入落到副本 A 成功即返回，紧接着一次读被路由到副本 B。跨 AZ 复制往返约 1–2 毫秒，而这 1–2 毫秒里 B 手上就是旧值。不解决会怎样？不是「偶尔有点旧」这么温和——是系统失去可推理性：同一请求重试两遍得到两个答案，你却无法判断哪个是 bug。所以本章做的事是：把「一致」这个形容词，拆成一组可判定、明码标价的合约。

核心内容，讲透

先把 CAP 摆正：它管的范围比你以为的窄

几乎所有关于一致性的误解都从「CAP 三选二」开始。Petrov 特意提醒：CAP 成立的前提是一个很窄的模型——异步网络、没有时钟、消息可任意丢失；它说的 C 专指线性一致性，A 专指「每个到达非故障节点的请求必须在有限时间内返回」，而非日常说的「高可用」。真正的结论是：只有分区真的发生时，你才被迫在 C 和 A 之间选一个；不发生分区的绝大多数时间，两者都能有。

更贴工程的替代提法是 Fox 与 Brewer 1999 年的收成与产出（harvest and yield）：产出是成功完成的请求比例，收成是答案的完整度。允许「只搜到 90% 索引分片的结果」，比「全或无」更接近真实系统的降级方式——你是在牺牲收成换产出，可用性由此从 0/1 变成连续量。

把存储想成一个格子：三种寄存器

要精确讨论「读到什么算合法」，得先有个最小模型。本章借用共享内存的视角：把整个分布式存储当成一个能读能写的格子（寄存器），然后问——一次读和一次写在时间上重叠时，读可以返回什么？三档：

• 安全寄存器（safe）：重叠期间的读可以返回任意值，哪怕从没写过。听着离谱，但它精确刻画了「毫无保证」这一档。
• 常规寄存器（regular）：读只会返回旧值或新值之一，不会返回垃圾——但两次连续的读可以先新后旧。
• 原子寄存器（atomic）：存在一个翻转点，一旦某次读看到新值，之后所有读都必须看到新值——这正是线性一致性落在单个对象上的样子。

这个阶梯的价值在于：它把「一致性」从形容词变成可判定的执行历史集合——给定一段读写历史，你能回答「合法吗」。

一致性谱系：线性 → 顺序 → 因果 → 最终

有了寄存器语义，常见模型就能排成一条谱系——越靠上，协调越多、延迟越高、分区时越脆。

• 线性一致性（linearizability）：所有操作落在一个与真实时间一致的全序上，每个操作在发起与返回之间某一点「生效」。直觉：整个集群装得像一台单机。它还可组合——各对象线性一致，放一起仍线性一致。代价：每次操作走一轮多数派协调，跨 AZ 约 1–2 毫秒，跨洲几十毫秒起。
• 顺序一致性（sequential consistency）：有全序，且与每个进程自己的程序序一致，但不必与真实时间一致。直觉：同一部电影，整场可能延后放映——别人仍可能读到旧值，但所有人看到的顺序一样。ZooKeeper 的读即此档：本地应答、可能落后，要线性一致得先调 sync。
• 因果一致性（causal consistency）：只要求有因果关系的操作在所有节点同序，并发操作可被不同节点以不同顺序看到，靠版本向量携带「我依赖哪些前序写」。直觉：不能让人先看到回复、后看到原帖。分量在于：坚持可用 + 分区容忍时，它是可达的最强模型（COPS、Eiger 一系的结论）。
• 最终一致性（eventual consistency）：只承诺「停写后终将收敛」，不给任何时间上界——最弱的有用保证，也是被滥用得最狠的词。

会话保证：把承诺从系统挪到「你这条会话」

谱系那几档都是系统级的全局性质，因此昂贵。工程上常见的折中是把承诺范围缩到单个客户端会话：这类会话模型（session guarantees）只对「你这条会话」成立，于是便宜得多：

• 读己之写（read your own writes）：你改完头像，你自己一定看到新的；别人晚一点无妨。
• 单调读（monotonic reads）：你读到的值不许往回退。
• 单调写（monotonic writes）：你先后发出的两次写，在所有副本上按你发出的顺序落地。
• 写跟随读（writes follow reads）：你基于读到的值写下去，这条因果链在别处也不倒序。

最便宜的实现是粘性会话（stickiness）：同一客户端固定路由到同一副本，前两条几乎白送。代价是副本一挂保证就断——严肃场景要靠版本号（「不早于我上次看到的版本」）而非路由技巧。

可调一致性：w + r > n 并不给你线性一致

Dynamo 一系（Cassandra、Riak、DynamoDB）把选择权交给每一次操作：写等 w 个副本确认、读等 r 个副本回答，副本总数 n。当 w + r > n 时读写集合必有重叠，至少一个应答者见过最新写。Dynamo 论文（SOSP 2007）给出的常用配置是 n=3, w=2, r=2。

这是本章最值得记住的坑：w + r > n 只保证「有人见过最新写」，并不保证线性一致。因为写可能中途失败（w 个里只成功一个便返回失败，而那个副本上的新值还在）或仍在进行中——两次连续的读就可能先新后旧，单调读被破坏。

要补上缺口，得让读把读到的最大值写回落后的副本（ABD 式两阶段读，工程上即读修复），读路径从一趟变两趟。换句话说：「调 quorum」调出来的是可用性与陈旧度的折中，不是谱系上那一档合约。

见证副本：只投票、不存数据

多数派容错要求副本数够多，但「够多」的成本大头是存储，不是投票。本章给了个精巧的省法：见证副本（witness replica）平时只存元数据、不存数据本体，却照样投票；只有全量副本失联时才临时接收数据、事后交还。于是 2 全量 + 1 见证保住了三副本的多数派容错，存储只花约 2/3。Cassandra 的 transient replication 与 Spanner 的 witness 副本就是这个思路。

强最终一致与 CRDT：不协调也能收敛

最终一致性的痛处是冲突要有人裁决。最常见的裁法是 LWW——比时间戳，大的赢。但时钟一回拨，赢的可能是旧值，而且输掉那条写被静默丢弃，连报错都没有。

CRDT（conflict-free replicated data type，无冲突复制数据类型）换了个思路：把数据类型设计成「合并本身不需要裁决」。要求合并满足交换律、结合律、幂等——于是乱序、重复、重发都不改变结果，副本只要收到同一组更新（不论顺序）就必然到达同一状态。这个性质叫强最终一致性（strong eventual consistency）：它把「收敛」从运维承诺变成数据类型的数学性质，完全不需要共识。

以增长计数器（G-Counter）为例：每个副本只增自己那一格，合并时逐格取最大值，总值是各格之和。

再加一格「减量」就是可增可减的 PN-Counter；集合类有 G-Set、观察-移除集（OR-Set）等变体。实现分两派：状态型（CvRDT）互传整个状态，操作型（CmRDT）只传操作、更省带宽但要求投递保证。

代价很实在：只有部分数据类型做得出 CRDT；为正确处理删除要留墓碑，元数据随时间膨胀；而且「收敛」不等于「语义正确」——副本完全可以一致地得出一个谁都没想要的结果。

关键权衡与选型

表 1 · 六档合约怎么挑

表 2 · 同一套三副本，配置不同差别有多大（n=3）

判据很朴素：先问「读到旧值会怎样」。答案是「用户看到旧头像」，会话保证就够；答案是「超卖 1000 件」或「两个节点同时以为自己是主」，就只能付线性一致的钱——而且得用共识实现，不是把 r 调大。

为什么重要 / 落到真实系统

本章的实用价值在于把含糊的需求翻译成可实现的合约。架构评审里最常见的错就是把一致性当性能旋钮：「感觉有点不一致，把 r 调到 3」——延迟涨了、异常还在，因为 r 治不了读倒退。面试同理：能说清「w + r > n 为什么不等于线性一致」，比背 CAP 三选二有分量得多。

对照真实系统：etcd（Kubernetes 的唯一真相源）默认线性一致读，也留了更快的可串行化读作逃生门；ZooKeeper 读是顺序一致，要线性一致得显式 sync；Cassandra / DynamoDB 把档位交给每次调用；Spanner 用 TrueTime 与提交等待做到外部一致性；MongoDB 3.6 起提供因果一致会话；Riak 与协作编辑引擎走 CRDT。

易错点与争议

• 「CAP 三选二」是个坏概括。不发生分区时 C 和 A 都能有，被迫选择只发生在分区期间——Brewer 本人 2012 年就写过修正文章。
• 最大的坑：w + r > n 不等于线性一致。它只保证重叠、不保证顺序；要线性一致得加读回写，或干脆用共识。
• 「最终一致」不是「一会儿就一致」。它没有时间上界——线上必须监测实际复制滞后，而不是相信这个词。
• 线性一致可组合，弱模型不一定。两个各自因果一致的子系统拼起来，跨系统的因果链可能断掉。
• LWW 会静默丢写。靠物理时钟定序，一次时钟回拨就能让旧值覆盖新值，且没有任何报错。
• CRDT 不是万能药。只覆盖特定数据类型，墓碑与版本元数据会膨胀；最关键的是收敛 ≠ 语义正确——Dynamo 论文举过购物车的例子：合并之后被删掉的商品可能又回来了。
• 本书的时代位置与反方。2019 年出版时 CRDT 一节偏理论，之后 local-first 那一波（Automerge、Yjs）把它工程化，也暴露出元数据体积这个真问题。反方观点一直在：不少人认为业务开发者其实想要线性一致，被迫在弱模型上打补丁反而更容易错。

要点