4.2 Quorum 机制与一致性保障

4.2 Quorum 机制与一致性保障

本节摘要：账本详情里的三个数——承载组大小（ensemble）、写份数（writeQuorum）、确认份数（ackQuorum）——是存储可靠性的全部算术。本节把三参数的联动关系算给你看，推演故障时剩余副本如何维持可用，并给出按业务场景选参数的对照表。

写几份、确认几份：Quorum 的算术

三个参数各管一事。承载组大小 E：本账本的条目摊在多少台 Bookie 上，决定条带化宽度与写入并行度。写份数 Qw：每个条目实际写几份副本，决定磁盘空间放大与可容忍故障数。确认份数 Qa：写满几份就算成功并回复生产者，决定确认延迟与"已确认消息必在"的强承诺强度。

约束关系是 Qa 小于等于 Qw 小于等于 E。三者拉开差距各有含义：E 大 Qw 小，条带宽、空间省，但单副本条目多；Qw 大 Qa 小，副本铺得开、确认快，但确认时部分副本还在路上（这种"先回执后铺满"是允许的，铺满动作在后台补齐）；Qw 等于 Qa，确认即铺满，承诺最硬、延迟最高。

用一段 Python 把常见组合的属性算出来，跑一下比背结论有效：

combos = [
    ("默认档", 3, 3, 2),
    ("强承诺档", 3, 3, 3),
    ("空间友好档", 5, 3, 2),
    ("带宽档", 5, 5, 2),
    ("轻量档", 2, 2, 2),
]
print(f"{'组合':<8}{'E':<3}{'Qw':<4}{'Qa':<3}{'空间放大':<6}{'可容忍故障(不丢已确认)':<10}")
for name, e, qw, qa in combos:
    amp = qw  # 空间放大约等于写份数
    # 已确认消息的存活条件：至少 Qa 份存活；可容忍故障数 = Qw - Qa
    print(f"{name:<8}{e:<3}{qw:<4}{qa:<3}{amp:<6}{qw - qa:<10}")
​

运行输出会告诉你：强承诺档（三写三确认）任何一台 Bookie 掉线都会让写入暂停（凑不齐确认份数），但它没有"确认后还在路上"的窗口；默认档（三写两确认）允许一台机器失联时继续写入（剩余两份恰好够确认），这正是大多数集群的默认选择；带宽档五写两确认把条带拉宽到五台盘，写吞吐上去了，空间放大却高达五份——性能从来不是免费的。

图 4-2 Quorum 参数与故障容忍的关系

一、一致性从哪来：顺序与承诺

账本协议对一致性的担保有两层。第一层是写入顺序全局一致：同一账本的条目在任何 Bookie 上的编号与内容都严格一致，读端无论碰到哪台副本，看到的序列都相同——这是"账本"二字的字面含义，账页顺序不会因读的人不同而变化。第二层是确认承诺：拿到回执的条目，保证在"可容忍故障数"以内任何机器损坏后依然可读；没拿到回执的条目则不承诺，生产者应当重发。

第二层值得展开：日志类系统的"已确认必在"与"未确认可丢"边界画得很清楚，这让上层语义可以推理。配合第 3 章的投递闭环——发送失败重发送、消费失败靠重投——端到端就形成完整的不丢链条。链条上每个环节的参数都对应真实的开销，没有哪一环是白给的。

二、按场景选参数：对照表加推荐值

在 Pulsar 侧，这三参数按命名空间设定（也可细到策略粒度），命名空间新建账本即生效：

# 三参数按命名空间设置（persistence 策略），新建账本即按此执行
$ pulsar-admin namespaces set-persistence trade-order/transaction \
    --bookkeeper-ensemble 3 \
    --bookkeeper-write-quorum 3 \
    --bookkeeper-ack-quorum 2 \
    --marked-deleted-rate 0.1

# 用 internal-info 验证新账本的实际生效值：
$ pulsar-admin topics internal-info persistent://trade-order/transaction/order-events
# 观察输出里的 ensemble、writeQuorum、ackQuorum 三组数字是否与新策略一致
​

验证习惯值得强调：策略改完不等于生效，账本是"开新账时"读策略的，已在写的账本维持旧参数直到封存。变更后务必开个探针主题验一遍，再等自然切换。

故障演练：拔掉一台 Bookie 会发生什么

参数的最好学法是故障演练。在三 Bookie 测试集群上做"优雅下线"演练：让一台 Bookie 以受控方式退出（先停写入接入，再停进程），全程观察三件事——写入是否持续、已确认消息是否完整、集群何时自愈。

演练预期的时间线是这样的：Bookie 进入只读或退出的瞬间，正在写的新条目发现承载组缺员，Broker 侧的写方为受影响的账本申请新承载组（剩余健康节点加一台替补），这个过程通常亚秒到数秒；期间到达的少量写入可能收到短暂超时，生产者重试即愈——这正是第 5 章 send 超时重发要配幂等的场景。已确认的历史消息毫发无损：默认档三写两确认，两份存活满足确认承诺。演练最后看后台：BookKeeper 的自我修复机制会陆续把"只存在于失联机器上的唯一副本"补齐到健康节点，补齐速度可调，磁盘水位与网络带宽要给它留预算。

把演练换到强承诺档（三写三确认）重跑，现象立刻不同：缺一台即凑不齐确认份数，写入暂停，直到新承载组生效。两相对照，参数的工程含义不言自明——默认档用短暂的重试窗口换故障时的持续可用，强承诺档用可用性窗口换零悬空承诺。哪个更对，取决于业务读得到哪一边：交易审计读"承诺"，内容分发读"可用"。演练做一轮，比参数文档读十遍更记得住。

本节要点回顾

• 三参数各管一事：E 定条带宽度、Qw 定空间与容忍度、Qa 定承诺强度与延迟；
• 约束 Qa 不超过 Qw 不超过 E；拉开或对齐各有工程含义；
• 可容忍故障数等于 Qw 减 Qa，这是"已确认消息不丢"的边界；
• 一致性两层担保：条目顺序全局一致、已确认必在且未确认不承诺；
• 参数按命名空间挂、新账本生效，变更后必须用探针验证。

下一站算经营账：冷数据搬去远洋的对象存储，保留与过期各按什么规矩退房。