Ledgers和Fragments是在Zookeeper中维护和跟踪的逻辑结构。物理上数据不存储在Ledgers和Fragments对应的文件中。BookKeeper中存储的实现是可拔插的，Pulsar默认使用名称为DbLedgerStorage的存储实现。
Pulsar 的数据最终是靠 Bookkeeper(Bookie) 存储的，各个 Pulsar Bookie 之间是平等的，kafka 的存储节点在 Partition 层次上有主从之分。
pulsar单个 Broker 数据写流程如下：
- 1 将写请求记入 WAL【类似于数据库的 Journal 文件】
一般把 WAL 和数据存储文件分别存储到两种存储盘上，如把 WAL 存入一个 SSD 盘，而数据文件存入另一个 SSD 或者 SATA 盘。
-
2 将数据写入内存缓存中。
-
3 写缓存写满后或达到时间阈值时，进行数据排序并刷盘，排序时将同一个ledger的数据聚合后按照时间先后进行排序。
-
4 将 <(LedgerID, EntryID), EntryLogID> 写入 RocksDB
LedgerID 相当于 kafka 的 ParitionID，EntryID 即是 Log Message 的逻辑 ID，EntryLogId 就是 Log消息在 Pulsar Fragment文件的物理 Offset。
这里把这个映射关系存储 RocksDB 只是为了加快写入速度，其自身并不是 Pulsar Bookie 的关键组件。
image.png
读：
1 从写缓存读取数据【因为写缓存有最新的数据】；
2 如果写缓存不命中，则从读缓存读取数据；
3 如果读缓存不命中，则根据 RocksDB 存储的映射关系查找消息对应的物理存储位置，然后从磁盘上读取数据；
4 把从磁盘读取的数据回填到读缓存中；
5 把数据返回给 Broker。
写：
Bookie 的整个写入流程除了自身把内存缓存数据批量刷盘一步外，整个流程几乎不需要跟磁盘进行IO，所以速度也是极快。
写入都按顺序写入日志文件可以存储在专用的磁盘上，并且可以批量刷盘以获得搞得吞吐量。除此之外从写入操作来看没有其他的同步磁盘IO操作，数据都是写入到内存的缓存区。
总结
DbLedgerStorage
上图为Pulsar默认使用的bookie架构
网友评论