4 一致性模型：线性/顺序/最终

第 3 章把同一份数据放到了多个副本上。副本解决了耐久性和读扩展，却留下一个新问题：当一次读到达某个副本时，它允许看到哪个版本？ 第 3 章只回答了「写去哪里、怎么复制」，没有回答「读返回什么才算对」。这一章补上这个判定标准。

先看一个真实形状的事故。账户 A 的余额是 100，用户发起一笔 100 元的转账。主库在 09:41:02.140 提交，A 变成 0，响应在回程丢失。客户端在 800 ms 后超时，自动重试。重试请求落到一个尚未应用这笔写的只读副本，读到 A 还是 100，余额检查通过，于是又扣了一次。09:41:05，A 的余额是 -100，收款方收到 200。这里没有哪台机器宕机，也没有哪段代码「写错」：主库提交了，副本只是还没追上，重试只是「再试一次」。事故的根源是系统对「读到的 100 意味着什么」没有定义。

「强一致」「最终一致」这些词在日常讨论里几乎无法证伪：每个人都能找到自己满意的解释。本章换一种写法：先记录一段 history，再给出一个判定条件，最后用检查器跑一遍。一个模型只有能说清「哪段 history 违反它」，才值得写进设计文档。

路线是这样：4.1 建立 history、实时序和三种操作的词汇；4.2–4.5 依次给出线性一致、顺序一致、因果/会话保证、最终一致的定义、反例和代价；4.6 把 CAP 还原成 Gilbert–Lynch 的精确版本，并补上 PACELC；4.7 把副本一致性和事务隔离级别拆成两个维度；4.8–4.11 用分区陈旧读、etcd 观测、Jepsen 案例和二次转账把理论落到故障上；4.12 给出业务选型表，4.13–4.14 收束成陷阱清单与出口检查。读完这一章，你应该能指着一张时序图说：「这里违反的是线性一致，不是隔离级别。」

4.1 历史、实时序与三种操作

一致性模型不是对「数据库性格」的描述，而是对一段可观测历史的约束。先把历史写成表。下面是一段单寄存器 x 上的六个操作，时间单位是毫秒，inv 是客户端发出调用的时刻，resp 是客户端收到响应的时刻：

这张表里已经藏着几个容易读错的点：

• 操作 1 和操作 2 的时间区间重叠（4 < 10），它们是并发的。并发不等于「同时执行」，只表示一个操作返回之前另一个已经发起。
• 操作 3 在操作 2 返回之后才发起（8 < 12），所以操作 2 在操作 3 之前。这是实时序，不是「谁的时间戳小」。
• 操作 5 和操作 6 都来自 P3，且不重叠；操作 6 的 CAS 期望值是 2，但操作 5 已把 x 改成 3，所以返回 false 是合法的。
• 操作 4 读到了 2，发生在操作 3 返回之后，符合直觉；如果它读到 1，这段历史就有问题了。

把同样的信息写成 JSON Lines，方便程序读取：

{"proc":"P1","op":"write","key":"x","value":1,"inv":0,"resp":10,"ret":"ok"}
{"proc":"P2","op":"read","key":"x","inv":4,"resp":8,"ret":1}
{"proc":"P1","op":"write","key":"x","value":2,"inv":12,"resp":16,"ret":"ok"}
{"proc":"P2","op":"read","key":"x","inv":18,"resp":22,"ret":2}
{"proc":"P3","op":"cas","key":"x","expected":2,"value":3,"inv":20,"resp":25,"ret":true}
{"proc":"P3","op":"cas","key":"x","expected":2,"value":4,"inv":26,"resp":30,"ret":false}

这六条记录对应三种最小操作。很多教材只讲读和写，但检查真实系统时 CAS 不可少：只用读/写建模，「读-改-写」会被拆成两个独立操作，丢失更新就看不见了；CAS 把「比较并替换」建模成一个原子操作，才能表达「只有版本仍是 7 才扣款」这类语义。

为什么一定要用客户端观测到的 inv/resp，而不是服务端日志里的提交时间？因为一致性模型约束的是客户端能观察到什么。服务端在 t=5 提交，客户端在 t=9 才收到响应；另一个客户端的读在 t=7 发起。若用服务端提交时间排序，会错误地认为写已经在读之前完成；实际上读的调用早于写的响应，二者并发，读返回旧值完全合法。反过来，如果服务端在 t=9 提交，客户端 t=10 收到响应，另一个读在 t=11 发起却返回旧值，这才是真的违反线性一致。提交时间在操作区间内部，响应时间才是区间右端。

记录历史时有四个坑：

1. 不要用墙上时钟跨机器比较。time.time() 会被 NTP 调整，两台机器的偏差可能是毫秒，也可能是秒。用 time.monotonic_ns() 在单机记录；跨客户端时先测偏差，只有偏差远小于操作间隔才敢比较。
2. 不要只记录服务端的开始/结束。服务端处理时间只是区间的一部分，无法替代客户端的 resp。
3. 不要丢掉失败的 CAS。false 也是一次合法的返回；把它当「没发生」会掩盖顺序错误。
4. 不要把 pending 操作当成功。超时后服务端可能已提交；检查器应允许把它补全或删除，而不是强行赋一个结果。

真实系统通常还会在响应里带一个版本号（revision、applied_index、LSN）。记录历史时一并保存，后面判断「读到的是不是旧版本」会容易得多：

09:41:02.140  write A=80   rev=58  resp=ok
09:41:02.221  read  A=100  rev=57  applied=57   <- 比写返回的 rev 旧

这两行不需要复杂的理论，已经能说明一次陈旧读。4.2 要做的，是把「rev 旧」升级成「整段历史是否可能存在一个合法全序」。

4.1.1 从单对象到多对象：先确定「被检查的对象」

4.2 节的检查器只处理一个 key。真实系统里还有多 key 事务、跨行约束和「先读 A 再读 B」的业务逻辑。把它们塞进单对象模型，会得到两种相反的错误。

第一种错误是把一个事务拆成若干个单 key 操作，分别检查线性一致，然后宣布「每个 key 都线性一致，所以系统一致」。4.7 节会给出反例：每个 key 的读都合法，拼起来却不是任何时刻的快照。事务的原子性不是「每个 key 各自原子」，而是「整组操作在同一时刻可见」。

第二种错误是把事务内部读到的中间值当成客户端可见的操作。事务在提交前读到的值，外部客户端看不到；把它放进 history 会增加不必要的实时序约束，甚至把正确实现误判为错误。

所以动手判定前先问：这段 history 的操作粒度是什么？ 如果业务不变量跨多个 key，单 key 检查器只能证明「每个 key 没退步」，不能证明「业务不变量没被破坏」。本章后面的检查器明确只做单 key；跨 key 的检查需要把事务当成一个复合操作，或者使用快照/串行化检查器（第 6 章）。

4.2 线性一致性：定义与判定

线性一致（linearizability，也叫原子一致、atomic consistency）的直觉是：每个操作看起来都在它的调用与响应之间某个瞬间原子地生效，整个系统像只有一个副本。 直觉很好用，但判断事故时不够精确。精确版本需要存在一个全序。

图里只画了一个写和一个读，但已经包含判定所需的全部信息：写 x=1 在 t1 返回，读在 t2 > t1 才开始，读必须返回 1（或更新的值）。读返回 0 就是陈旧读，违反线性一致；读超时只是 unknown，不构成反例，因为待定操作可以被丢弃。

并发允许两种结果。 如果读在写返回之前就发起了（区间重叠），读返回 0 或 1 都可能是线性一致的：把读的线性化点放在写之前，它看到 0；放在写之后，它看到 1。很多人把「线性一致」误读成「读必须立刻看到正在进行的写」，这是错的。线性一致只要求存在某一个合法的全序，不要求读偏向新值。

反例的最小结构是「写已返回，读才开始，却读到旧值」：

历史 D 是另一个常见形状：没有写，读却从 2 退到 1。线性一致要求所有操作共享一个全序，读只能沿着这个全序前进，不可能倒退。「单次读都合法」不等于「整段历史线性一致」，这是 4.8 节陈旧读的核心。

4.2.1 判定：枚举所有尊重实时序的全序

有限历史可以暴力判定。思路是深度优先搜索所有「线性扩展」：每一步从尚未放置、且其所有实时序前驱都已放置的操作中选一个，应用到一个寄存器状态上；如果操作是读，读到的值必须等于当前状态；如果是 CAS，返回值必须与当前状态一致。只要找到一条走完全部操作的路径，历史就是线性一致的。

下面是一个可运行的单寄存器检查器。它接受 Op 列表，返回 (是否线性一致, 见证全序或 None)：

from __future__ import annotations

from dataclasses import dataclass


@dataclass(frozen=True)
class Op:
    proc: str
    kind: str          # "write" | "read" | "cas"
    key: str
    arg: object        # write: 新值；read: None；cas: (期望值, 新值)
    ret: object        # write: "ok"；read: 读到的值；cas: True/False
    inv: int           # invocation 时间
    resp: int          # response 时间


def is_linearizable(history, initial=None):
    """单寄存器检查器：返回 (是否线性一致, 见证全序或 None)。"""
    ops = list(history)
    n = len(ops)
    # preds[j] 中的操作必须在 j 之前：a.resp < b.inv 即 a <rt b
    preds = [
        {i for i, a in enumerate(ops) if i != j and a.resp < b.inv}
        for j, b in enumerate(ops)
    ]
    placed = [False] * n
    order = []

    def apply(state, op):
        s = dict(state)
        if op.kind == "write":
            s[op.key] = op.arg
            return s, True
        if op.kind == "read":
            return s, s.get(op.key) == op.ret
        if op.kind == "cas":
            expected, new = op.arg
            if s.get(op.key) == expected:
                s[op.key] = new
                return s, op.ret is True
            return s, op.ret is False
        raise ValueError(op.kind)

    def dfs(state, done):
        if done == n:
            return True
        for i, op in enumerate(ops):
            if placed[i] or any(not placed[p] for p in preds[i]):
                continue
            nxt, ok = apply(state, op)
            if not ok:
                continue
            placed[i] = True
            order.append(i)
            if dfs(nxt, done + 1):
                return True
            order.pop()
            placed[i] = False
        return False

    ok = dfs(dict(initial or {}), 0)
    return ok, ([ops[i] for i in order] if ok else None)


def show(name, history):
    ok, order = is_linearizable(history, initial={"x": 0})
    print(f"{name:8s} linearizable={ok}")
    if ok:
        print("         witness: " + " -> ".join(
            f"{o.proc}.{o.kind}({o.ret})" for o in order))


H_OK = [
    Op("A", "write", "x", 1, "ok", 0, 10),
    Op("B", "read", "x", None, 1, 12, 20),
]
H_STALE = [
    Op("A", "write", "x", 1, "ok", 0, 10),
    Op("B", "read", "x", None, 0, 11, 20),
]
H_SC = [  # 顺序一致，但不线性一致；4.3 节解释
    Op("A", "write", "x", 1, "ok", 0, 5),
    Op("B", "write", "x", 2, "ok", 6, 10),
    Op("C", "read", "x", None, 1, 11, 15),
    Op("C", "read", "x", None, 2, 16, 20),
]
H_CAS = [
    Op("A", "write", "x", 1, "ok", 0, 5),
    Op("A", "cas", "x", (1, 2), True, 6, 10),
    Op("B", "read", "x", None, 2, 11, 15),
]

for name, h in [("H_OK", H_OK), ("H_STALE", H_STALE), ("H_SC", H_SC), ("H_CAS", H_CAS)]:
    show(name, h)

把它保存为 linearizability.py 并运行，输出是：

H_OK     linearizable=True
         witness: A.write(ok) -> B.read(1)
H_STALE  linearizable=False
H_SC     linearizable=False
H_CAS    linearizable=True
         witness: A.write(ok) -> A.cas(True) -> B.read(2)

四点读法：

1. H_OK 的读在写返回之后开始，见证全序只有一种合法排列。
2. H_STALE 的读返回 0，但写已完成；任何全序都必须把写放在读前，读应返回 1，所以搜索失败。
3. H_SC 在 4.3 节会看到它顺序一致；检查器返回 False 只说明「不线性一致」，不说明「不一致」。判定器回答的是某个模型，不是笼统的『一致/不一致』。
4. H_CAS 说明 CAS 成功会改变状态，后续读必须看到 2；CAS 不是「读一下再写」，而是一个原子操作。

4.2.2 复杂度与工程判定

暴力搜索最坏是 n!，而判定线性一致性在一般情况下是 NP 完全的（Wing 与 Gong, 1993）。真实历史动辄百万操作，不能直接套上面的代码。工程上有四类优化：

Jepsen 的 Knossos 用的是这类搜索加剪枝；它报告的是一个具体反例（哪几个操作无法排列），而不是一个概率。工程上更实用的做法是：先用 session 保证、版本号和业务不变量做粗筛，再把可疑窗口喂给检查器。检查器不是证明系统正确，它只能证明「这段有限历史存在/不存在合法全序」。没有反例不等于正确，只等于这段历史没暴露问题。

4.2.3 边界：线性一致不保证什么

线性一致只约束单对象的读/写/CAS 历史，不自动提供下面这些东西：

• 跨对象的原子读。分别线性一致地读 A 和 B，合起来可能不是某个时刻的快照。
• 事务的隔离。两个线性一致的写仍可能丢失更新，如果它们是「读-改-写」而不是 CAS。
• 低延迟。线性一致读通常要一次 leader/quorum 往返；跨地域时这往返就是几十毫秒。
• 分区期间的可用性。4.6 节会证明，分区时线性一致和可用性不能同时成立。
• 会话保证的跨副本版本。线性一致对单对象已经蕴含读己之写和单调读（同一客户端的操作在实时序上不重叠）；但如果你用的是「每个副本各自线性一致」，把多个副本的读拼起来，会话仍可能回退（4.8 节）。

4.2.4 一次搜索的回溯记录

把 H_STALE 的搜索过程写出来，比看代码更容易理解「为什么不存在全序」：

H_SC 的回溯更能说明「实时序」和「程序序」的差别：

如果只保留程序序、去掉实时序，H_SC 就能找到 4.3 节给出的见证全序。检查器的差别不在搜索算法，而在 preds 里放了哪些边。 把 a.resp < b.inv 换成「同一进程的前一个操作」，得到的就是顺序一致检查器；这正是 4.3 节的形式差别。

成功时返回的 witness 是一个证书：它给出每个操作在线性化顺序中的位置。失败时返回 False 只对这段有限历史成立；换一段更长的历史、加上没记录到的 pending 操作，结论可能改变。判定器的输出要连同 history 一起存档，否则无法复核。

4.3 顺序一致性：差在哪

顺序一致（sequential consistency，SC）是 Lamport 1979 年提出的模型。它保留了「所有操作存在一个全序」，但删掉了「全序必须尊重实时序」这一条。

最小的「顺序一致但不线性一致」历史就是上面的 H_SC：

C 的两次读有明确的程序序：先读到 1，再读到 2。顺序一致的见证全序是：

write(x,1) -> read(x)=1 -> write(x,2) -> read(x)=2

这个全序尊重每个进程的程序序（A 只有写 1，B 只有写 2，C 的两次读顺序不变），也满足寄存器语义：第一次读之前最后写的是 1，第二次读之前最后写的是 2。它唯一的问题是：B 的写 write(x,2) 在 [6,10] 已经返回，而 C 的第一次读在 11 才开始，实时序要求写 2 排在读 1 之前；一旦如此，读 1 就不可能返回 1。 所以这段历史顺序一致，但不线性一致。

实时轴 0     5  6    10 11   15 16   20
A      [W=1]
B              [W=2]
C                        [R=1]  [R=2]
                          ↑
                  W=2 已返回，R=1 才开始；
                  SC 可以把 W=2 排到 R=1 之后，
                  线性一致不允许。

两者的差别可以压成一张表：

两个常见误解需要当场拆掉。

误解一：顺序一致比线性一致「便宜很多」。 顺序一致仍然要求一个全局全序，通常仍要单点序列化或共识；它省掉的是「等待实时确认」，不是「协调所有操作」。一个系统如果连全局日志都没有，往往连顺序一致也给不了，只能给因果或最终一致。

误解二：顺序一致就是「串行化」。 串行化（serializability）是事务层面的性质：并发事务的结果等价于某个串行执行顺序；顺序一致是单对象读写的可见性顺序。两者正交，4.7 节会展开。把「sequential consistency」翻成「顺序一致性」时，尤其容易和数据库的「串行隔离」混在一起。

4.3.1 顺序一致也不是免费的

一个常见的实现是「单点序列器 + 全序广播」：所有写提交给序列器，序列器分配一个递增序号并广播；每个副本按序号应用。读可以在本地按已应用的前缀回答，不必等序列器确认。这样得到的全局顺序尊重每个客户端的程序序（客户端按序号提交），但读可能被排在一个已经返回的写之前，所以是 SC，不一定是线性一致。为了让同一客户端的读不退步，读还要固定副本或带上「已见前缀」令牌；否则第二个读打到更落后的副本，程序序就被破坏了。

注意第三行：「顺序一致」和「线性一致」的差别往往就是读要不要等确认。 等确认就把读放进了实时序，不等就只保证「存在某个全序」。这也解释了为什么很多系统把「强读」做成一个显式选项：默认本地读是 SC/陈旧读，关键读才付一次往返。

顺序一致的另一个代价是全序本身。没有全局日志、没有序列器、没有共识，就没有 SC；多个副本各自按本地顺序应用，得到的是因果或最终一致。SC 不是「不协调的强一致」，它只是「不要求实时确认的强顺序」。

4.4 因果一致性与会话保证

线性一致和顺序一致都要求全序，代价是协调。很多系统退一步：只要求有因果关系的操作被所有副本以相同顺序看到，并发操作可以各排各的。 这就是因果一致（causal consistency）。

先看它要防的那个经典反例。论坛里，Alice 发帖 P，Bob 读到 P 后回复 R，Carol 读到了 R 却读不到 P：

Carol 看到了回复却看不到被回复的帖子，这是「因果倒置」。因果一致禁止的正是这种形状；它不禁止 Carol 在 Bob 回复之前看不到 P（那时 P 和 R 并发），也不要求 Carol 看到 P 的那一刻 Bob 的回复已经存在。

因果一致比线性一致弱在哪？它不要求实时序，也不要求全局唯一顺序。Alice 发帖后，Carol 可以过一会儿才看到；Bob 和 Dave 对两条并发评论的先后可以不同。它比最终一致强在哪？它禁止「回复先于原帖」这种不可解释的顺序，而最终一致允许副本在收敛前任意乱序。

因果一致在工程上常和「会话保证」一起出现。因果一致是跨客户端的性质，实现成本不低（要传播依赖关系，例如向量时钟）；会话保证是单客户端的性质，实现便宜得多，但只保护这个客户端自己。复制 lag 的成因和读己之写的工程做法在 第 3 章 已经出现过；本节换一个角度，把会话保证当成一组可判定的承诺来检查。

一个最小实现是给会话发一个 token，里面放「本会话最后一次写产生的 applied index」；读副本只有追到这个 index 才允许返回：

import time


def read_your_writes(replicas, key, token, timeout_ms=200):
    """token 是写返回时拿到的 applied_index。"""
    deadline = time.monotonic() + timeout_ms / 1000
    while time.monotonic() < deadline:
        for replica in replicas:
            value, applied = replica.get_with_version(key)
            if applied >= token:          # 该副本已经包含我的写
                return value
        time.sleep(0.005)
    raise TimeoutError("no replica caught up; fall back to leader")

这段代码的关键不是循环，而是 applied >= token 这个条件。没有它，replicas 列表里的任何一个副本都可能返回旧值；有了它，最坏情况是等待或回退到主库，而不是悄悄破坏读己之写。get_with_version 需要副本暴露「已应用的日志位置」，这也是为什么第 3 章强调复制日志索引：没有版本，就没有会话保证的锚点。

4.4.1 向量时钟：把因果依赖带在请求上

会话 token 是一个标量，只能表达「我这个客户端见过哪些写」。跨客户端的因果需要更完整的依赖：Bob 的回复依赖 Alice 的帖子，Carol 的副本必须先应用 Alice 的写，才能应用 Bob 的回复。向量时钟（vector clock）就是做这件事的。

每个副本维护一个 {node: counter}；本地事件递增自己的计数器；发送消息时带上整个向量；接收方逐项取最大值。比较规则：

一个最小判断函数：

def happens_before(a, b):
    keys = set(a) | set(b)
    return all(a.get(k, 0) <= b.get(k, 0) for k in keys) and a != b

Bob 读完 Alice 的帖子后，写回复时携带 {A:1, B:1}；Carol 的副本如果只有 {B:1}，就不能应用这条回复，要先等 A:1 到达。这就是「因果交付」（causal delivery）。代价是向量随写入者数量增长；工程上用依赖集合、版本向量压缩或混合逻辑时钟来控制大小。

向量时钟只解决因果顺序，不解决实时序：Alice 的帖子可能很久以后才到 Carol，只要顺序对，因果一致就满足。要实时，仍然需要线性一致读/写。

因果一致和会话保证都不能免费升级成线性一致：

• 读己之写只保护「自己写的」，别人写的最新值仍可能看不到；
• 单调读只保证不回退，不保证看到最新；
• 因果一致不保证实时，Alice 的帖子可能几秒后才对 Carol 可见；
• 所有这些都不提供跨对象的原子快照。

它们适合什么？社交动态、评论、购物车、用户资料这类「顺序错了很怪，但晚一点没关系」的场景。余额、库存、配置开关这类「错了要赔钱」的场景，仍然要更强的模型或原子写。

4.5 最终一致性：收敛的条件

最终一致（eventual consistency）是最容易被口号化的模型。它的正式承诺其实很短：如果不再有新的写，所有副本最终会返回同一个值。 注意三个词：最终（没有时间上界）、所有（每个副本）、同一个（收敛，不是「都最新」）。

这个定义单独看几乎不约束实现：一个永远不复制、但也不接受读的系统也「最终一致」。工程上说的最终一致，通常隐含了下面六个条件；缺一个，收敛就可能不成立，或者只在 PPT 上成立。冲突解决的具体机制（LWW、版本向量、CRDT）在 第 3 章 已经展开；这里把它们当成「收敛条件」逐条检查。

把这六条压成一句话：最终一致 = 停止写 + 送到 + 确定合并 + 不复活删除 + 读路径可达 + 不丢更新。 其中任何一条都需要工程实现，不是选一个数据库就自动获得的。

「最终」到底有多最终？没有上界。一个每小时跑一次反熵的系统，收敛时间可能接近一小时；hinted handoff 保留三天，节点宕机三天内回来还能补，超过三天就可能丢。收敛时间不是 SLA，除非你用机制给它加上界，例如「读修复在 200 ms 内完成」「反熵每 30 秒一轮」「副本 lag 超过 5 秒就摘除读流量」。把这些机制写进 SLO，才谈得上「最终一致的延迟」。

一个具体的时钟陷阱：LWW（last-write-wins）用时间戳决定胜者，但时间戳来自各节点的墙上时钟。

W2 在真实时间上更晚，却因为 W1 的节点时钟快而输掉。最终两个副本都收敛到 1，收敛了，但收敛到了错误的值。这就是为什么条件 3 要求「确定性」还不够，还要说明时间戳的语义：LWW 的「最后」是「时间戳最大」，不是「真实最后」。如果业务不能接受这种错序，就需要版本向量/因果序，或者把冲突交给应用合并。

CRDT 走的是另一条路：把状态设计成可交换、可结合、可幂等的合并结构，这样到达顺序不影响结果。一个 Grow-only Counter 的最小实现：

class GCounter:
    def __init__(self, node):
        self.node = node
        self.counts = {}

    def inc(self, n=1):
        self.counts[self.node] = self.counts.get(self.node, 0) + n

    def merge(self, other):
        for node, value in other.counts.items():
            self.counts[node] = max(self.counts.get(node, 0), value)

    def value(self):
        return sum(self.counts.values())


a, b = GCounter("a"), GCounter("b")
a.inc(2)
b.inc(3)
a.merge(b)
b.merge(a)
print(a.value(), b.value())   # 5 5

merge 对每个节点取最大值，满足交换律、结合律、幂等律；无论 a.merge(b) 和 b.merge(a) 谁先执行，结果都是 5。这就是「强最终一致」（strong eventual consistency）：所有看到同一组更新的副本，不需要协调就处于相同状态。代价是数据模型受限：计数器可以这样合并，但「把余额设为 100」这种覆盖写不能；它需要 LWW 或应用层冲突解决，也就重新引入了时钟/顺序问题。

4.5.1 反熵、读修复与删除：收敛的实际时间线

「最终」不是一个瞬间，而是一条由多种机制拼起来的时间线。假设 key x 在副本 A 上从 0 改为 1：

读修复只在「读到的副本比另一个副本新」时有用；如果读打到落后副本，它没有新值可修。真正兜底的是反熵或 hinted handoff：

删除比写入更危险。删除通常写一个 tombstone；如果 tombstone 在分区恢复前被 GC，落后副本会把旧值当成「缺失的新值」读修复回来，出现「删除复活」。所以 tombstone 的保留时间必须大于最大可能分区时长 + 反熵周期，而不是「几天应该够了」。

收敛时间的粗糙上界可以写成：

T_converge <= max(反熵周期, hinted handoff 投递时间, 读修复触发间隔) + 传播/应用时间

这个式子里的每一项都必须有监控；没有这些项，「最终一致」只是一个没有上界的承诺。4.12 节会把「有界陈旧」作为选型的一档，而不是把「最终」当成一个可承诺的延迟。

4.6 CAP 的精确版本与 PACELC

CAP 被引用得最多，也被误读得最多。先把三个字母还原成定义。2000 年 Brewer 提出猜想，2002 年 Gilbert 与 Lynch 给出证明；他们证明的「C」不是「所有副本一样」，而是线性一致（原子对象）。

证明只需要一个两节点反例。节点 N1、N2 组成系统，初始 x=0，网络把它们分区。客户端向 N1 写 x=1，N1 返回成功（否则不满足 A）。接着客户端向 N2 读 x：

• 若 N2 返回 1，它必须在分区期间知道 N1 的写，但消息被丢弃，矛盾；
• 若 N2 返回 0，读不是线性一致的（写在读之前已返回），违反 C；
• 若 N2 等待到超时，违反 A；若 N2 返回错误，工程语义下也算不可用。

三者不可能同时成立。注意这里没有假设「N2 一定知道 N1 写过」；恰恰因为分区，它不可能知道。

这个证明经常被转述成「CAP 三选二」，但精确的含义要窄得多：

所以更有用的问法不是「这个数据库是 CP 还是 AP」，而是：在这次请求、这个对象、这个故障场景下，我放弃的是线性一致还是可用性？放弃的边界在哪里？

PACELC 补上了 CAP 没说的另一半。Abadi 在 2012 年把它写成：If Partition, choose A or C; Else, choose Latency or Consistency. 没有分区时，强一致仍然要付协调/等待的延迟；这个代价天天都在，不是故障时才出现。

「Else, Latency or Consistency」不是空话，可以用数字感受：同可用区一次 RTT 约 0.3–1 ms，跨地域 30–150 ms；线性一致读通常要多一次 leader/quorum 确认，quorum 写要多一次多数派落盘。这些延迟在系统完全健康时也会发生，而 CAP 只在分区时说话。选型时如果只问 CAP，就会漏掉 99.9% 时间里的性能代价。

4.6.1 分区不是一个二值事件

CAP 证明里的 P 是「任意消息丢失」，现实中的分区更复杂：可能单向、可能只影响部分链路、可能持续几百毫秒，也可能时断时续。系统通常用超时/心跳/quorum 来猜测分区，猜测本身会出错：

所以「分区时选 C 还是 A」在工程上还要加一问：我能不能及时、准确地检测到分区？ 检测太敏感会把正常抖动当分区，检测太迟钝会让旧 leader 继续服务。lease（租约）用时间换检测速度，fencing（第 9 章）用单调 token 把旧持有者挡在资源外；两者都不是 CAP 定理本身，而是把 CAP 的选择落到实现上。

最后一个常见错误：把 CAP 的 C 当成「所有副本数据相同」。副本相同是收敛（4.5 节），线性一致是读的可见性顺序。一个系统可以所有副本最终完全相同，却在收敛前返回陈旧读；也可以每次读都线性一致，却在分区时拒绝服务。两者不是同一个坐标轴。

4.7 一致性不是隔离级别

「一致性」这个词在分布式系统和数据库里指两件不同的事，混用会导致非常具体的错误。本节把两个维度拆开：

• 副本一致性（replica consistency）：同一个对象有多个副本时，一次读允许看到哪个版本？关键词是线性一致、顺序一致、因果、最终。
• 事务隔离（transaction isolation）：多个事务并发访问多个对象时，允许出现哪些交错？关键词是读未提交、读已提交、可重复读、快照隔离、串行化。

它们回答的问题不同：

线性一致不等于串行化。 一个每键都线性一致的 KV 存储，不提供跨键事务：转账时先读 A、再读 B，两个读各自线性一致，合起来仍可能不是同一时刻的快照。反过来，一个串行化的数据库如果允许从只读副本读，返回的仍可能是旧版本；串行化约束的是事务之间的等价性，不是副本的实时可见性。

一个具体的「不一致快照」：初始 A=100，B=100。事务 T1 把 50 从 A 转到 B，提交后 A=50、B=150。客户端在 T1 提交前线性一致地读 A 得到 100，在 T1 提交后线性一致地读 B 得到 150。两次读都合法，但把它们拼起来得到 A+B=250，而系统在任何时刻的总和都是 200。每一把钥匙都线性一致，不等于跨钥匙的读是一个快照。 要解决它，需要快照读/多对象事务（第 6 章），而不是把单键一致性调得更强。

事务隔离级别的常见异常可以用一张表对照（细节在第 6 章）：

这张表里最容易被忽略的是快照隔离下的写偏斜：两个事务各读一份「对方没动」的快照，各自写不同的行，合起来破坏不变量。它是隔离级别问题，不是副本问题；把读切到主库、把一致性调成线性，都不会修复它。反过来，4.8 节的陈旧读是副本问题，把隔离级别从 RC 调到 Serializable 也不会修复它，因为旧值本身是已提交的合法数据。

4.7.1 两个维度同时出错：一个组合反例

把两个维度放在同一个事故里，能看清它们各自负责什么。初始 A=100、B=100：

第 1 步的事务是串行化的，第 3 步读 B 也可能是线性一致的；但第 2 步读 A 已经是陈旧读，组合起来更不是任何时刻的快照。要修第 4 步，需要一致的快照读（同一 revision 读多个 key），而不是把事务隔离级别再调高。

反过来也成立：一个系统每 key 都线性一致，但两个并发事务各自读 A、读 B，然后写对方读过的行，仍可能产生写偏斜。副本一致性管「读到的版本」，事务隔离管「并发事务的交错」；一个维度的加强不能替代另一个。

两个维度可以组合，现实系统通常只各取一档：

最后一个术语：严格串行化（strict serializability）= 串行化 + 实时序。它要求事务的串行顺序尊重实时序，Spanner 的「外部一致性」就是它。线性一致是单对象的严格串行化；串行化是多对象的等价性。把这三个词排成一条线：

单对象：最终一致 < 因果一致 < 顺序一致 < 线性一致
多对象：串行化 < 严格串行化
严格串行化 = 线性一致（实时序）+ 串行化（多对象原子性）

这两条线不是同一个维度（因果和顺序的关系、会话保证的位置都有细节），但足以防止最常见的偷换概念：「我们用了 Serializable，所以读一定是最新的」是错的；「我们用了线性一致，所以转账不会丢更新」也是错的。

4.8 失败模式：分区期间的陈旧读

4.7 节把副本一致性和隔离级别拆开了。现在把镜头对准最典型的副本一致性故障：网络分区期间，客户端从落后副本读到了已提交但过期的值，并把这个值当成决策依据。 它和超时、重试、重复副作用是同一条链上的环节，只是这次「错误的数据」而不是「重复的动作」先出场。

把开头那个账户事故展开成时间线。集群三副本：leader L、follower F1、follower F2。F2 仍与 L 连通，F1 与 L 之间的复制链路在 09:41:02.130 被切断：

t(ms)  客户端                 leader L                 follower F1
  0    TX t-1  ----------->  A=100 B=0    rev=57      A=100  rev=57
 10                          ── F1 与 L 的复制链路断开（分区） ──
 20                          A=0   B=100  rev=58      A=100  rev=57
 21                          ack 在回程丢失            （收不到 rev=58）
800    timeout（800ms 预算）
804    重试 t-2 ----------->  （读请求被负载均衡到 F1）
805                          A=100  rev=57  <-------- 陈旧读：guard 通过
820    TX t-2  ----------->  A=-100 B=200 rev=59

这里有三份「真相」，每一份在自己的视角里都合理：

这就是第 1 章说的「部分失败」在数据面的版本：每个节点都只掌握了事实的一部分，但每个节点都在基于自己那部分事实做决定。 分区不会「制造旧数据」，它只是让旧数据的存在时间从毫秒级变成无界；真正造成事故的是客户端把「读到的值」当成了「当前的值」。

分区期间陈旧读的放大路径有五条，按出现频率排序：

第 3 条值得单独说，因为它经常被当成「读重试无害」。假设客户端连续两次读同一个 key：

read #1 -> F1：A=100  rev=57
read #2 -> F2：A=80   rev=55   （F2 比 F1 更落后）
read #3 -> F1：A=100  rev=57

每一次读都可能是「该副本自己的日志上线性一致」的读，但三次读合起来不是任何一致模型：三次读之间没有新的写，值却从 100 退到 80 再回到 100。「每个副本各自线性一致」不等于「整个系统线性一致」。 线性一致性是对整段 history 的判定；把多个独立副本的局部 history 拼起来，实时序可能根本无法满足（4.2 节的定义里，读 #2 在 read #1 返回之后发起，必须看到 100 或更新值）。

业务后果不是抽象的「不一致」，而是可以计价的：

• 余额检查通过，实际余额不足，账户透支 100 元；
• 库存显示 1 件，三个分区各自卖出 1 件，超卖 2 件；
• 优惠券在旧副本上显示「未使用」，同一张券被核销两次；
• 权限撤销写到 leader，读副本仍返回旧 ACL，被撤销的用户多访问了几分钟；
• 调度器基于旧状态做决策，把同一个任务派给两个 worker。

这些场景的共同点是：读不是终点，而是下一个写/副作用的输入。 如果读只用于展示，陈旧最多让人困惑；如果读用于 guard（余额够不够、库存有没有、锁是否空闲），陈旧读就会变成重复副作用。4.11 节会把这条链接到二次转账。

修复要分层，不能只喊「读主库」：

4.8.1 读路由策略与代价

同一个「读余额」请求，路由策略不同，得到的新鲜度和可用性完全不同：

选择不是「哪个最强」，而是这个读能不能接受旧值、能接受多旧、分区时能不能失败。余额 guard 选第一行；商品详情选第二/第六行；购物车选第四行；配置读选第一行 + watch。把策略写进接口（例如 read(key, mode=...)），而不是藏在负载均衡器里，否则调用方无法判断自己拿到的是什么。

前面那张修复手段表的最后一行——原子条件写——是陈旧读的兜底，不是替代品。即使读到了旧值，只要写是「余额 ≥ 100 才扣」的原子操作，第二次扣款会被拒绝；但用户仍会看到错误的余额，体验和客服成本还在。读的一致性和写的原子性要一起设计。

观测上，至少要能回答「这次读来自哪个副本、它的 applied index 是多少、和写回执差多少」。如果响应里只有值，没有版本，事故复盘时只能猜。4.9 节用 etcd 演示如何把这两个数字读出来。

4.9 观测：etcd 的 linearizable vs serializable read

etcd 把「读的一致性」做成了每个请求的显式选项，非常适合观察。下面以 etcd 3.5 的 etcdctl 为例；etcdctl get 的 --consistency 有两个取值：

• l（linearizable，默认）：读必须经过 leader 确认（ReadIndex/心跳），保证返回的是集群已提交的最新值；
• s（serializable）：读由本地成员直接服务，可能落后于 leader，但延迟低、分区少数派也能读。

先准备一个三节点集群（本机示例端口 2379/22379/32379），写入一个余额，然后看三个成员的状态：

etcdctl --endpoints=http://127.0.0.1:2379 put /ledger/alice 100

etcdctl --endpoints=http://127.0.0.1:2379,http://127.0.0.1:22379,http://127.0.0.1:32379 \
  endpoint status -w json \
  | jq -r '.[] | [.Endpoint, .Status.header.revision, .Status.raftIndex, .Status.raftAppliedIndex, .Status.leader] | @tsv'

输出示例（字段顺序：endpoint、当前 revision、raftIndex、raftAppliedIndex、leader id）：

http://127.0.0.1:2379    51    51    51    10276657743932975437
http://127.0.0.1:22379   51    51    51    10276657743932975437
http://127.0.0.1:32379   51    51    51    10276657743932975437

现在向 leader 写 80，制造一次版本推进：

etcdctl --endpoints=http://127.0.0.1:2379 put /ledger/alice 80

OK

从 leader 做一次线性一致读，确认写已经可见：

etcdctl --endpoints=http://127.0.0.1:2379 get /ledger/alice --consistency=l -w json

{"header":{"cluster_id":14841639068965178418,"member_id":10276657743932975437,"revision":52,"raft_term":4},"kvs":[{"key":"L2xlZGdlci9hbGljZQ==","create_revision":51,"mod_revision":52,"version":2,"value":"ODA="}],"count":1}

value 是 base64 的 80，mod_revision=52 是这次写的版本。接下来把 follower 22379 与集群的 peer 流量切断。可以用防火墙/网络策略，或直接用第 13 章项目的 /admin/partition：

# 隔离 22379 的 peer 流量（任选其一）：
#   1) 在 22379 所在节点用防火墙/网络策略切断它与 2379、32379 的 peer 连接；
#   2) 用第 13 章项目的 /admin/partition 接口（macOS/CI 可复现）。
# 本机三进程部署时，peer 端口通常是 2380/22380/32380。

再查一次状态，会看到 22379 停在旧 revision：

http://127.0.0.1:2379    52    52    52    10276657743932975437
http://127.0.0.1:22379   51    51    51    10276657743932975437
http://127.0.0.1:32379   52    52    52    10276657743932975437

此时从 22379 做 serializable 读，它会用本地状态回答：

etcdctl --endpoints=http://127.0.0.1:22379 get /ledger/alice --consistency=s -w json

{"header":{"cluster_id":14841639068965178418,"member_id":11276657743932975437,"revision":51,"raft_term":4},"kvs":[{"key":"L2xlZGdlci9hbGljZQ==","create_revision":51,"mod_revision":51,"version":1,"value":"MTAw"}],"count":1}

revision=51、mod_revision=51、value=100：这是 4.8 节说的陈旧读。再从同一个 22379 做 linearizable 读：

etcdctl --endpoints=http://127.0.0.1:22379 --command-timeout=2s \
  get /ledger/alice --consistency=l -w json

{"level":"warn","ts":"2026-10-19T09:41:07.812Z","logger":"etcd-client","caller":"v3/retry_interceptor.go:63","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0000e8000/127.0.0.1:22379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = context deadline exceeded"}
Error: context deadline exceeded

具体错误文本随 etcdctl 版本和超时设置略有差异；关键是它没有返回旧值，而是失败。这正是 CAP 的现场演示：serializable 读在分区少数派上仍然可用，但返回旧值；linearizable 读拒绝返回旧值，代价是不可用。没有哪个选项「更好」，只有这次读能不能接受旧值。

批量对比三个成员的读，可以一眼看出谁落后：

for ep in 2379 22379 32379; do
  etcdctl --endpoints=http://127.0.0.1:$ep get /ledger/alice --consistency=s -w json \
    | jq -r --arg ep "$ep" '[$ep, .header.revision, (.kvs[0].mod_revision // -1), (.kvs[0].value // "")] | @tsv'
done

2379   52  52  ODA=
22379  51  51  MTAw
32379  52  52  ODA=

怎么读这些数字：

三条读法：

1. 线性一致读成功时，结果不能比已经返回的写旧。 如果写回执是 rev=52，读却返回 rev=51，这不是「最终一致」，而是线性一致读的实现 bug（或者你以为发的是 l，实际发的是 s）。
2. serializable 读落后多少，要有一个上界。 例如「读流量只允许打到 applied lag ≤ 5 s 的副本」；超过就摘除或降级。没有上界的 s 读，在分区时可能落后几分钟。
3. linearizable 读超时不是数据丢失。 它说明当前成员无法确认最新值，因此拒绝回答；这比返回旧值安全。复盘时要把它计入可用性，而不是一致性错误。

两个容易忽略的边界：

• --consistency 只作用于 get（以及基于 get 的命令），不作用于 watch。watch 从指定 revision 之后按序推送已提交事件，但一个从旧 revision 开始的 watch 会先收到旧事件；它不是线性一致读。
• endpoint status 的 revision 是该成员本地看到的 revision，不是全局最新值；比较时要以 leader 的 header.revision 或写回执为准，不能拿两个 follower 互相比较。

4.9.1 把读模式写进客户端契约

etcd 的 --consistency 是一个好示范：一致性是请求的属性，不是集群的属性。客户端应该能显式表达：

{"key":"/ledger/alice","consistency":"bounded_staleness","max_lag_ms":50}

服务端根据模式选择读路径，并在响应里带回证据：

关键在最后一列：降级必须是显式的。如果客户端请求 linearizable，服务端因为分区偷偷返回本地旧值，调用方会把陈旧读当成最新值，4.11 节的事故就会重演。反过来，bounded_staleness 超界时返回错误或升级，也比静默返回旧值好。

如果手边没有 etcd，第 13 章的项目二提供了同构接口：kv_client.py get k --consistency linearizable 与 --consistency serializable，底层分别是 ReadIndex 读和本地读。命令不同，读法相同：看返回的 revision/applied index 与写回执的差。

4.10 真实案例：Jepsen 对 MongoDB 3.4 的分析

2017 年 2 月 7 日，Jepsen 发布了针对 MongoDB 3.4.0-rc3 的分析。这份分析的重要性不在于「MongoDB 有 bug」，而在于它用一个可复现的 history 证明了：在 majority write concern 和 linearizable read concern 都打开的情况下，系统仍然可能丢失已经被确认的写。 这两个选项的名字听起来已经是最强保证，但一致性是端到端的，选举协议的一个假设就能把它击穿。

分析的测试环境是五节点副本集，工作负载包含读、写和 CAS；故障注入不是简单的「杀节点」，而是专门制造有时钟偏斜的隔离主库：

MongoDB v0 复制协议的选举用 optime 比较「谁更新」。optime 是单调递增的，但它被锚定在节点的本地墙上时钟上。于是出现了分析里的经典场景：

1. 节点 A 是 primary，与集群隔离 10 秒，期间接受 w1、w2，optime 记为 10、11，但无法复制给多数派。
2. 另一侧 B 当选 primary，接受 w3，optime 记为 10，并以多数派写确认；w3 复制到了 C。
3. 隔离解除，A 与 C 选举。A 的 optime 11 大于 C 的 10，A 当选。
4. A 的日志里没有 w3；为了让日志一致，系统回滚 w3。w3 已经被多数派确认，却从系统中消失了。

时钟偏斜不是「小概率的脏数据」，它直接扩大了「隔离主库的 optime 超过多数派」的窗口。分析指出，v0 的这个缺陷是设计性的，不是某个版本的实现 bug；包括 3.4.1 在内的所有 v0 部署都存在，修复方式是切换到 v1 协议。

Jepsen 的第一组数字：v0 协议下，4525 次插入尝试中，322 条最终保留，93 条被确认后丢失。这不是「写失败了」，而是「客户端收到了成功，数据后来没了」。

v1 协议借鉴了 Raft 的 term 概念，把 optime 换成 (term, timestamp)，理论上应该修复 v0 的选举缺陷。但 v1 在 3.4.0-rc3 与 rc4 上仍然暴露了多个 bug：

• primary 在确认写时只检查「我是否还是 primary」，没有检查 term 是否已经变化，于是可能确认上一个 term 的写（SERVER-27053）；
• 心跳消息可能让一个过期 primary 推进 commit point，确认尚未真正持久的写；
• 3.4.0-rc4 中，secondary 复制时没有检查对方是否是更新的节点，仍然用时间戳而不是 term 比较（SERVER-27149）。

结果：v1 下 6078 次插入尝试，932 条被确认，417 条最终丢失——接近已确认写的一半。这两个 bug 的根因都可以追溯到 v0 时代的假设：代码里仍然相信「时间戳更大 = 日志更新」，而 v1 的 term 才是逻辑时钟。

修复与验证：

这份分析给出的教训可以直接迁移到任何系统：

1. 「多数派确认」是一个条件承诺，不是无条件事实。 它依赖选举协议不会让一个缺少该写的节点当选；如果选举依赖墙上时钟，时钟偏斜就是数据丢失的故障注入项。
2. 读一致性不能修复写丢失。 如果已确认的写被回滚，linearizable 读再强也只能返回「当前存在的值」；它无法让不存在的写复活。
3. 协议版本是配置的一部分。 同一个 MongoDB 版本，v0 与 v1 的一致性行为不同；升级/切换协议要和升级代码一样做验证。分析特别指出 v1 不是 Raft，保留了 rollback 等额外复杂度。
4. 测试要注入时钟偏斜和分区，而不只是杀进程。 只测「节点崩溃后重启」会漏掉「隔离主库 + 快时钟赢得选举」这条路径。Jepsen 的 nemesis 之所以有效，是因为它针对协议的假设设计故障，而不是随机搞破坏。

4.10.1 把案例变成自己的测试

不必复现 Jepsen 的五节点集群，也可以在自己的项目里验证同一类假设。第 13 章的项目二提供了分区注入接口，按下面的表设计用例：

每条用例都要记录 history：操作的 inv/resp、返回值、revision。测试的断言不是「最终一致了」，而是「在注入期间，线性一致读要么返回最新值，要么失败；serializable 读允许旧值，但不能在同一会话中回退」。这比「跑一遍没报错」强得多。

对本书的读者来说，这个案例还有一个方法论意义：第 4.2 节的检查器不是玩具。 把上面的插入/读/CAS 操作记录成 history，检查器（或 Jepsen 的 Knossos）就能给出「不存在合法全序」的反例。没有 history 和判定器，你只能看到「监控显示写入成功」，看不到「成功之后又消失」。

4.11 重试导致重复副作用：陈旧读后的二次转账

现在把 4.8 节的陈旧读和重试接起来。这是全书最值得背下来的事故形状之一：读到的旧值让 guard 通过，重试让同一个意图执行两次。 它同时违反了两条设计原则：读没有版本约束，写也没有幂等身份。

场景：账户 A 初始 100 元，向 B 转账 100 元。服务端的处理函数是典型的「先查再写」：

1. balance = read(A)            # 读请求走只读副本
2. if balance < amount: 拒绝
3. debit(A, amount); credit(B, amount)
4. 返回 transfer_id

第一次请求 t-1 在 leader 上提交：A=0、B=100，rev=58。响应在回程丢失，客户端 800 ms 超时。客户端重试，但重试逻辑生成了新的 transfer_id=t-2；同时读请求被负载均衡到落后的副本，读到 A=100（rev=57）。于是：

注意两个错误是独立的，任何一个被修复都能阻止事故：

• 如果 t-2 复用 t-1 的幂等键，服务端的唯一约束会发现「这个意图已经执行」，直接返回原结果；
• 如果 t-2 的读是线性一致的（或读己之写），它会看到 A=0，guard 拒绝；
• 如果扣款是原子条件写（balance >= 100），即使 guard 通过，第二次扣款也会失败；
• 如果对账把流水与用户授权关联起来，能在 t4 之后立即发现并冻结，或者扣款有「单日单账户最多转 100」的业务约束，也能兜住。

四个「如果」对应四层防御，不能只做一层。幂等键解决「同一个意图被执行两次」，条件写解决「基于旧值的写覆盖新值」，线性一致读解决「看到旧值」，对账解决「前三个都漏了」。 它们防的不是同一件事。

一个可运行的 SQLite 版本（Python 标准库，无需外部依赖）把前两层放在同一个事务里：

import sqlite3


def transfer(conn, tid, src, dst, amount):
    with conn:  # 事务：异常自动回滚
        cur = conn.execute(
            "INSERT INTO transfers(id, src, dst, amount, status) "
            "VALUES (?, ?, ?, ?, 'pending') ON CONFLICT(id) DO NOTHING",
            (tid, src, dst, amount))
        if cur.rowcount == 0:                 # 幂等键已存在
            return "duplicate"
        cur = conn.execute(
            "UPDATE accounts SET balance = balance - ?, version = version + 1 "
            "WHERE id = ? AND balance >= ?",   # 原子 guard
            (amount, src, amount))
        if cur.rowcount == 0:
            raise ValueError("insufficient funds")
        conn.execute(
            "UPDATE accounts SET balance = balance + ? WHERE id = ?",
            (amount, dst))
        conn.execute("UPDATE transfers SET status = 'done' WHERE id = ?", (tid,))
    return "ok"

配套的建表语句：

CREATE TABLE accounts (
  id      TEXT PRIMARY KEY,
  balance INTEGER NOT NULL,
  version INTEGER NOT NULL
);
CREATE TABLE transfers (
  id     TEXT PRIMARY KEY,
  src    TEXT NOT NULL,
  dst    TEXT NOT NULL,
  amount INTEGER NOT NULL,
  status TEXT NOT NULL
);

两次调用 transfer(conn, "t-1", "A", "B", 100) 的结果：第一次返回 "ok"，第二次返回 "duplicate"，A 只扣一次。示例为了简短返回 duplicate；生产实现应在命中幂等键时读出原 transfers 行，返回第一次的结果。再调用 transfer(conn, "t-2", ...) 会因 balance >= 100 不成立抛 insufficient funds，事务回滚，不会留下半条记录。注意这是单机 SQLite 的串行写模型；换成 PostgreSQL/MySQL 时，唯一约束和行锁的语义类似，但隔离级别、锁等待和死锁重试要按第 6 章处理。

还有一个更隐蔽的变体：客户端没有超时，但用户看到「处理中」后手动点了第二次。 这次是新的用户意图，客户端会生成新键，幂等键救不了；只有业务层的去重规则（同一用户、同一收款方、同一金额、时间窗）或条件写能挡住。幂等键识别「同一个意图的重试」，业务规则识别「看起来像新意图的重复点击」。 两者也不能互相替代。

最后，不要用「读主库」替代条件写。线性一致读只能保证「读的那一刻是最新」，读和写之间仍有时间窗；两个并发请求可以都线性一致地读到 100，然后都扣款。读一致性解决可见性，条件写/事务解决原子性。 这就是 4.7 节两个维度的分界线。

4.12 如何为业务选一致性

一致性选型不是「选一个最强的数据库」，而是按操作回答五个问题：读错了会怎样？写冲突能否合并？能接受多旧？分区时要不要可用？这个错误能否被对账修复？把答案落到机制上，而不是口号上。

这张表不是标准答案，而是一个论证模板：每一行都要能回答「为什么这一档够用」。如果答不上来，就往上加一档；如果加一档的延迟/可用性代价无法接受，就把业务改成能接受旧值（例如展示层加「可能延迟」提示），或者把关键判断移到写路径上。

成本可以粗略量化：

一个可执行的五问决策树：

1. 读错会不会直接造成资损、超卖、越权或不可逆的外部副作用？ 会 → 决策读走线性一致/leader，写走条件更新或事务。
2. 能不能用幂等 + 对账把错误变成可修复的？ 能 → 可以降一档，但必须真的实现对账和补偿，而不是写在文档里。
3. 能接受多旧？ 给出毫秒/版本上界；不能给出上界 → 不要选「最终一致」作为决策读。
4. 并发写是否可交换/可合并？ 可合并 → CRDT/版本向量；不可合并 → 单写者、CAS 或锁（第 9 章）。
5. 分区时业务要可用还是要正确？ 两者都要 → 把操作拆开：展示读降级、决策写失败关闭；不要指望一个开关同时满足。

4.12.1 一个走完流程的例子：库存扣减

假设 SKU 只有 1 件库存，两个用户同时下单。业务要求：不能超卖；下单接口在分区时宁可失败也不能卖重；商品详情页可以显示旧库存。

两个常见错误：

• 先读库存再扣：两个请求都读到 1，都通过 guard；除非扣减是原子条件写，否则超卖。读的一致性再强，也挡不住读写之间的窗口。
• 用 quorum 写就以为线性一致：W=2, R=2 只保证读写集合相交；如果读只是取第一个响应、没有版本比较/读修复，仍可能拿到旧值。即使读到了最新，也不自动等于线性一致（并发写、sloppy quorum、跨 key 都不在 R+W>N 的覆盖范围）。库存扣减要靠条件写或共识，不是靠「多数派」三个字。

这个例子也说明为什么本节开头的表要按操作拆：同一个 SKU，详情读和下单写的选择可以完全不同。

三个常见的过度设计也要避免：

• 所有读都走线性一致：跨地域延迟翻倍，读扩展消失，leader 成为热点；展示型读完全没必要。
• 所有写都用全局事务：跨地域 2PC 的延迟和阻塞代价很高；很多写可以用「单分区事务 + outbox + 幂等消费」解决（第 6、7 章）。
• 把「最终一致」当成「不用设计」：冲突解决、tombstone、反熵、对账都是实打实的代码；不写这些，最终一致只是「最终不一致」。

4.13 本章陷阱清单

4.14 本章出口检查

母本对应

下一站：知道了「读允许返回什么」，下一步要问「多个副本如何就同一个顺序达成一致」。进入 5 共识：Paxos 与 Raft，看 quorum 如何相交、term 如何阻止旧主、ReadIndex 如何把线性一致读落到协议上。