2.3 BookKeeper 与 Ledger：真正的货仓

2.3 BookKeeper 与 Ledger：真正的货仓

本节摘要：消息字节最终住在 BookKeeper 的账本里。本节讲清货仓的两个基本量词——账本（Ledger）与条目（Entry），解释账本如何通过条带化摊到多台 Bookie 上实现并行写入与故障容错，并回答一个关键问题：它和"Kafka 分区当存储单元"到底差在哪。

Ledger：货仓里的集装箱

BookKeeper 的世界只有两样东西值得先记：**Ledger（账本）**是追加式记录的容器，**Entry（条目）**是账本里的一行记录。Pulsar 把一个主题分区的消息流切成一段段账本来存——比如分区写到一定量或一定时间就开新账本，旧账本封存。这个"分段"思想与日志系统的段文件类似，但关键差别在后头：一段账本不归属任何一台机器。

创建账本时，Pulsar 会指定它由一组 Bookie 共同承载：比如从集群里挑三台 Bookie，账本的条目轮流写进这三台（这叫条带化），每条写两份、确认一份（Quorum 参数，第 4 章细算）。于是"账本在哪"这个问题没有单点答案——它同时活在几台机器上，任何一台挂了，账本还完整。这正是 2.2 节"Broker 换管家、字节不动"的字节层面保障：字节不是躺在某台机器上，而是躺在一个跨机器的协议里。

一、条带化写入：把顺序写的好处和副本的可靠拼在一起

看一眼条带化的直觉。设账本由 Bookie 甲、乙、丙三台承载，条目依序进入：

Entry 0 -> 甲        Entry 1 -> 乙        Entry 2 -> 丙
Entry 3 -> 甲        Entry 4 -> 乙        Entry 5 -> 丙
...（每台机器都只承担三分之一的写入量，三台磁盘并行转）
​

三条盘同时顺序追加，写吞吐接近单盘的三倍；而任何一台当机，剩余两台上的条目仍凑得出完整历史（配合副本补齐，账本自我修复）。对比传统主从复制——写入压在主节点一条盘上，从节点只做镜像等待——条带化把"多副本"从纯粹的冗余开销变成了吞吐资源。

写入的落盘路径也讲究分家：每台 Bookie 把新条目先写进预写日志（Journal，顺序写、保证断电可恢复），再异步整理到账本存储文件里。生产部署的黄金法则就是把这两类 IO 放在不同的物理盘上，互抢磁头是性能杀手——这条铁律在第 6 章部署形态里会再次出现。

二、和"Kafka 分区"对比：存储单元的不同性格

把表读薄：Kafka 的存储单元"认机器"，BookKeeper 的账本"认协议"。认机器的系统，机器变化就是数据变化；认协议的系统，机器变化只是协议参与者的换班。这一差异向上传导，就成了第 1 章对比矩阵里"弹性扩容"一栏的分差来源。

三、从命令行看账本

BookKeeper 提供独立的管理命令行（bookkeeper shell），在部署机上可以直接查货仓的库存：

# 列出集群里存活的 Bookie
$ bookkeeper shell bookies list
# 输出示意：
# 10.0.0.11:3181  RW（可读写）
# 10.0.0.12:3181  RW
# 10.0.0.13:3181  RW

# 查看某个账本的详情：写了几份、确认几份、摊在哪些机器
$ bookkeeper shell ledgerinfo -ledgerid 47
# 输出示意：
# ledger 47: ensemble=[11, 12, 13] writeQuorum=3 ackQuorum=2 state=CLOSED
# 含义：三台承载，每条写三份，两份确认即成功，账本已封存

# 查一台 Bookie 上压着哪些账本（排查磁盘热点时常用）
$ bookkeeper shell listledger -bookie 10.0.0.12:3181 | head
​

ensemble、writeQuorum、ackQuorum 这三组数字是账本协议的全部灵魂，第 4 章会专门用一节做算术与取舍演练。此刻你只需要建立条件反射：看到账本详情，先找这三个数。

⚠️ 常见坑：测试环境常见"Bookie 单节点部署"，即一台机器既当货仓又当全体副本。这能跑通功能，却让"账本跨机器容错"完全不成立——单节点模式下那台机器的磁盘就是唯一真相。凡是准备上生产的容量与可靠性验证，请至少三台 Bookie 起步。

账本的一生：开账、在账、封账、销账

用生命周期把账本相关的零散概念串起来。开账：主题分区的写入方（Broker）向 BookKeeper 申请新账本，指定三参数（承载组、写份数、确认份数）并从集群选出健康 Bookie 组成承载组。在账：条目按条带持续追加，期间任一承载 Bookie 故障，写方申请新承载组无缝接力——对外只有一次短暂的写切换，账本号不变。封账：写满条数上限或到达时长窗口，账本转为只读；Pulsar 侧通常会封存旧账、另开新账。销账：消息被删除策略或过期机制标记回收时，账本被删除，空间由后台压平回收。

这条生命周期解释了两个运维现象。其一，为什么"改副本策略"要等新账本：三参数是开账时定死的，在账的账本不回头改——想全量生效，得等所有旧账自然封存或手动触发切换。其二，为什么删除消息不等于立即释放磁盘：删除是记账（标记），真正的空间回收在后台压平时完成，所以磁盘水位的下降总是滞后于删除动作，监控上别把滞后当泄漏。

生命周期还藏着一个容量规划的锚点：账本越短（条数或时长窗口越小），封账越频繁、账本元数据越多，但单账本的故障影响面与重开新承载组的灵活性越好；账本越长则相反。多数场景用默认值就好，超大吞吐主题可以考虑调短账本时长，让"账"切得更勤——这个旋钮在第 4 章的存储复盘里会再次出现。

本节要点回顾

• Ledger 是追加式容器，Entry 是其中一行；主题分区按量或按时切成一段段账本；
• 账本不认机器：条带化摊到一组 Bookie，写吞吐与容错同时达成；
• Journal 预写日志与账本存储分盘，是 Bookie 落盘的第一铁律；
• 账本详情里的三个数（ensemble、写份数、确认份数）是第 4 章的主角；
• 与"分区认机器"的系统相比，账本"认协议"，机器换班不动字节。

下一章消息正式下水：它进哪种主题、走过怎样的生命周期、被哪种订阅接走、又如何签收——漂流启程。