Pulsar中的逻辑存储体系使用的是Apache BookKeeper。本文仅在Pulsar的背景下介绍BookKeeper。
BookKeeper将数据存储至集群中的节点上，每个BookKeeper节点称为Bookie。Pulsar和BookKeeper都使用Apache Zookeeper来存储元数据和监控节点健康状况。
Bookkeeper自身就可以组成一个集群，这个集群是 Client-Server 模型，集群的 metadata 可以利用一个 Ledger 语义存储（参考），在 Client 层面保证 各个 Bookie 之间的数据一致性。Pulsar 则是一种 Client-Proxy-Server 模型，基于 Broker 这个 Proxy 来保证一个 Topic Parition 内的数据一致性。
Pulsar 的底层数据 以 Ledger（上图中的 Segment 就是 Ledger） 形式存储在多个 BookKeeper 上，当集群扩容添加 Bookies 后，Pulsar 会在新的 Bookie 上创建新的 Segment(即 Bookeeper 的 Ledger)，所以不需要再扩容时候像 Kafka 一样进行 Rebalance 操作，其结果就是 Fragments跨多个Bookies以带状分布。但是这样的结果就是同一个 Ledger 的 Fragments 分布在多个 Bookie 上，导致读取和写入会在多个 Bookies 之间跳跃。Topic的 Ledger 和 Fragment 之间映射关系等元数据存储在 Zookeeper 中，Pulsar Broker 需要实时跟踪这些关系进行读写流程。
Pulsar 有一个 Ledger的所有权(ownership) 的概念，其意义为某个 Ledger 数据所在的 Bookie。除去创建新 Ledger 的情况，当集群扩容 Pulsar 把数据写入新的 Bookie 或者 当前Fragment使用Bookies发生写入错误或超时 时，Ledger的所有权 都会发生改变。
上图描述了 Bookie 集群扩容的情况。图中 Bookie X 和 Bookie Y 被添加到集群中，Broker 根据 IDC、机架、各个 Bookie 的容量等信息根据各种策略把 Segment X+1 和 X+2 存储到两个 Bookie 节点中，最终确保群集中各个 Bookie 之间的流量均衡。
上图描述了 Bookie 2 发生故障时，其 Segment 4 的修复过程。Broker 2 选取 Bookie 1 作为 Segment 4 的副本集，然后由 Bookie 自己的 Auditor 线程完成数据复制工作，整个过程对 Broker 和应用透明，功能的可用性不受影响。
每个Ledger有三个关键配置：
Ensemble Size (E)
Write Quorum Size (Qw)
Ack Quorum Size (Qa)
这些配置应用到Topic级别，然后pulsar会在Topic使用的BookKeeper Ledgers/Fragments上设置。
注意：Ensemble表示将要写入的实际的Bookies数量，以下用E表示。E表示Pulsar需要使用的Bookies数量。在配置时您至少需要E个bookies才能正常的使用。默认情况下，从可用的bookies列表中随机选取E个bookies(每个bookie在Zookeeper中注册自己)。
Ensemble Size (E) 决定了Pulsar写入Ledger可用的Bookies池的大小。每个Fragment可以有不同的Bookies列表，Broker将在创建Fragment时选择一组Bookies，E的数量是一致的。必有足够的Bookies数量(> E)。
Write Quorum (Qw) 是Pulsar将要写入的实际的Bookies数量。可以等于或者小于E。
当Qw小于E时，以条带化的方式分配读/写即每个Bookie只提供读写请求的子集。
如上图，Bookie Ensemble 数目是 5，Qw 为 3，Broker 可以用这种条带化方式把数据 Entry x 写入各个 Bookie。每个 Bookie 有一个 Auditor 线程跟踪自身负责的 Entry 集合是否有数据副本缺失【如当 Bookie 1 接收到 Entry 6 时，Auditor 会检测 Entry 5 是否已经收到】，当其发现数据有缺失的时候会从副本集中其他副本复制数据。
Ack Quorum (Qa) 是确认写入Bookies的数量，Pulsar Broker将确认发送给客户端。为了一致性，Qa应该是：(Qw + 1) / 2 或者更大。
(Qa == Qw) 或(Qa == Qw - 1) ---> 这样避免单节点响应缓慢而改善写入延迟。
当创建一个新的Topic或者Ledger滚动时会创建一个新的Ledger。Ledger在以下这些情况会发生滚动并创建新的Ledger：
- 已达到Ledger的大小或时间限制。
- Ledger的所有权(Pulsar Broker的所有权)发生变化(稍后会详细介绍)。
以下情况会创建新的Fragment：
- 创建新的Ledger。
- 当前Fragment使用Bookies发生写入错误或超时。
对比
1 kafka
kafka模型的优点在于简单快捷。所有读写都是顺序的。不好的是，单个节点必须有足够的磁盘空间来处理副本，因此非常大的副本可能会迫使你是用非常大的磁盘。第二个缺点是，在集群扩展时必须做Rebalance。这个过程是比较痛苦的，需要良好的计划和执行来保证没有任何故障的情况下分散节点的存储压力。
2 pulsar
Pulsar + BookKeeper模型。Topic中的数据分布在多个Bookies上。Topic被分割成Ledgers，Ledgers被分割成Fragments分布在Fragment使用的Bookies上。当需要做集群扩展时，只需添加更多Bookies，它们就会在创建新的Fragment时开始在的Bookies上写入数据，不再需要kafka的Rebalance操作。但是，读取和写入是在Bookies之间跳跃。
