6.3 Quorum 读写票数艺术

6.3 Quorum：读写票数的艺术

一致性不必非得"全部节点点头"才能办到——只要"写凑够 W 票、读凑够 R 票，且 W+R 大于副本总数 N"，读就必然能撞见最迟的一次写。这就是 Quorum 机制把一致性做成"可配置的算术"。本节推导这条铁律、教你配料 W/R/N，以及它替你省下的那些节点。

学习目标

阅读完本节，你应当能够：

1. 用 N、W、R 三个参数描述一次读写需要凑多少票。
2. 推证 W+R 大于 N 为什么能保证读看到新写。
3. 根据一致性需求给出 W、R 的配置直觉，并说明它替你省下哪些节点。

一致性不用"全员点头"

上两节讲了"听谁的"，这一节更抠细节——"要听多少票"。一个挺反直觉但非常省心的事实是：**你根本不需要等所有副本都确认，也能稳稳保证"读到最新值"。**秘密就藏在 Quorum（法定数目）这个思想里：把"全体确认"放宽成"凑够一个法定数目"，只要配得好，安全性与效率可以兼得。它用三个数描述：副本总数 N、写要凑够的 W、读要凑够的 R。

一、那条 W+R 大于 N 的铁律

为什么这么配就行，它的的关键在一个直白断言上：任何一次成功的写，都已经让至少 W 个副本拥有了最新值；同时任何一次读，都要读够 R 个副本。当 W+R 大于 N 时，这两拨副本集合必然重叠——重叠处的那一个副本，必然是"最新值"的持有者。于是读只要把这个重叠副本的值取到，就百分百看到了最近一次成功的写。交集的保证来自"W 加 R 凑得比总数还多"，这正是 Quorum 全部魔力的来源。

二、W、R、N 怎么配料才顺口

配料跟着一致性需求走：

要强一致：让 W+R 大于 N，且 W 尽量追 N（比如 N=3 时选 W=2、R=2，读写都凑多数）。它意味着写不盲目快、读也能撞到新值，适合账务。

要读敏能配：读多写少的业务，把 R 调小（R=1）、W 调大（W=N），写贵但读极轻——也就是"牺牲写、便宜读"，适合高并发读。

要写敏能配：反过来，R 接近 N、W 调小，写快读稍重，适合写很重的业务。

有趣的边界是：W+R 若刚好等于或小于 N，读可能完全避开那批写过的副本，于是"读到最新"就不再有保证——这正是为什么你永远要让 W+R 严格大于 N。

交集的来源一图看穿

下面这张 SVG 用两片圆圈示意"写覆盖了 W 个、读覆盖了 R 个、二者必然相撞"：

Quorum 的灵魂：W 与 R 的交集

三、工程里最常见的配方：多数即纪律

到现场你会发现，绝大多数系统干脆不玩花哨，直接把 "W、R、N" 配成"多数" 这个稳字诀：N 是奇数（3、5、7），W=(N+1)/2、R=(N+1)/2。这个配法的好处是只求过半即允容错——N=3 时允许挂 1 台、N=5 时允许挂 2 台，写读都以"多数点头"为界，无需额外指定，实现也统一。这正是 Raft 等多数派共识最常取的基底。需要微调一致性/性能比例时，再按需求动 W 或 R。

四、一个立刻能算的手把手续

配料不是玄学，用一组数走一遍你就彻底懂。假设副本总数 N=3。你配 **W=2、R=2**：写要等 2 台确认、读要等 2 台返回，W+R=4 大于 N=3，读必然撞见最新值——这就是"多数读写"的强一致配方，N=3 时可容忍 1 台挂掉。若把**读**调成 R=1：写仍 W=2，读只问 1 台，W+R=3 恰好等于 N，不再保证"必读到新值"——这时候读可能撞上没被写覆盖的那台，拿到旧值。这一升一降，正是"**要强一致，得让 W+R 严格越线；要读得快，就做好读到旧值的心理准备**"最直白的算术版。把这三组数（2,2 / 2,1 / 3,1）在空格上各画一次圆，你对 Quorum 的直觉就建立了，比死记公式耐用得多。

五、Quorum 偷了个什么懒，又没偷什么懒

最后别把 Quorum 神话了：它替掉的，是"等所有节点确认"这个笨办法，换来"凑够法定数目就敢返回"的灵活；但它没有替掉的，是"多数里的那台，一定是持有最新值"这个前提——这个前提靠的仍是最底层那一套"写要过半、读要过半、交集继承"的安全机制。换句话说，Quorum 是把你上一节在 Paxos/Raft 里学到的"多数交集"，翻译成了一组读写可配的参数而已。所以工程里二者常一起出现：多数派共识负责"谁说了算"，Quorum 参数负责"我说了算的程度定在几档"。分清这两层，你就既不会把 Quorum 当成万能的，也不会在看架构图时把它和共识算法混为一谈。

六、三组最容易配错的配方，逐个拨正

Quorum 的坑，九成出在"看着合理、其实配错"的三组数上，逐个帮你拨正：

**配方一：N=3、W=2、R=1。** 写要 2 台、读只问 1 台，W+R=3 恰好等于 N。它"读最快"，但读可能撞上没被写覆盖的那台、读到旧值——**这是一个不保证强一致的读敏配置**，只有业务能容忍旧值时才用。

**配方二：N=3、W=1、R=2。** 写只等 1 台就返回、读要凑 2 台。它"写极快"，但读又贵又弱，通常只在"写比天大、读可以忍"的极端场景才敢用。

**配方三：N=3、W=2、R=2。** W+R=4 大于 N，读写都能撞见最新值、且能容 1 台挂。**这是最稳妥的"强一致且容错"配方**，也是 Raft 等多数派共识的基底，绝大多数系统都从这里起步。

记住一条口诀：优先从"奇数 N + 两边过半"起步，真要调性能，再小心地把 W 或 R 往一边压，同时在心里明确你放弃了哪一档一致性——别只看见省了延迟，看不到丢了保证。

本节要点回顾

• 三个数：副本总数 N、写票 W、读票 R。
• 铁律 W+R>N：保证读必撞见写的最新值。
• 配方看负载：强一致多数、读敏调小 R、写敏调小 W。
• 多数纪律最常见：N 奇数、W=R 过半，容错与实现两相宜。

一致性在 Quorum 这里被量化成算术，但容错还有更"暗黑"的一层——万一不是节点宕机，而是有节点在撒谎呢？那就要上拜占庭模型了。下一节 6.4 我们从"崩溃容错"一路看到"拜占庭容错"，再回看故障怎么检测、怎么自愈。