本周 TGIP-CN 直播中，StreamNative 翟佳为大家讲解了《Pulsar Storage on BookKeeper》。演讲内容来自 Pulsar Summit，原讲人是 Verizon Media 的 Joe Francis 和 Rajan。
2012 年，因为数据规模较大，雅虎想打造一个系统来满足内部多场景的需求，Pulsar 由此诞生。
在开发 Pulsar 之前，雅虎内部已经开始做 BookKeeper 项目，主要是为了适配 message 最佳写并提供 IO。所以 Pulsar 也跟 BookKeeper 结合有了分层存储的架构，保证了后续的高带宽和低延迟等特性。
Verizon 公司在其内部应用 Pulsar 时也专门做了一些 Benchmark。之所以利用 Pulsar 进行 benchmark 是因为现有的大部分 benchmark 不容易测试线上生产场景。
其次就是 Pulsar 的一些特性刚好满足了「全功能替换能力」，线上负载状态下运行良好。主要表现在：
-
当后置的 consumer 进行重复读取时，Pulsar 会从磁盘读取积压文件。
-
当磁盘和 broker 出现崩溃/失败时，Pulsar ack guarantee 会使数据从 2 台以上的主机同步到磁盘，保证了数据的一致性。
-
使用 Pulsar 时，延迟不受负载变化的影响。因为它可以进行 backlog 读取和故障瞬时恢复，这与 Pulsar 的读写分离有很大的关系。
🎙️ Pulsar 的读写分离
上图为大家展示了 Pulsar 系统内的数据读写动态。黑线箭头为第一动态列，首先发起数据变动。Producer 生产消息传输到 broker 内部的 BookKeeper client，然后由此再并发写入到底层多个存储节点。
绿色箭头代表第二动态列，bookie 收到消息后通过 bookie journal 将「写成功」的命令返回到 bookie — broker，通过这一系列的数据传输，就可以将数据放入到 broker 的写缓存内。最后再通过 broker 将 ack 状态传达给 producer。
消息读取动态可以参考红色箭头和蓝色箭头。一种是在 broker 收到写成功指令后，consumer 进行读取消息。另一种就是「cold reads」，数据请求从 broker 端走下来，没有数据的话就一层层路径找回去，最后从 bookie data 里找到数据后再原路返回进行数据读取。
通过以上我们也可以看出来数据写过程主要发生在 journal 内，而读过程则是发生在灰色数据盘或者内存内。这就是 Pulsar 内部的读写分离状态。
在上边提到的 Pulsar 读写过程中，当数据传输到存储节点后，writer 就会将数据传输给 journal，jounal 会定期进行数据传送到 journal device 内。最后将 write ack 结果返还给 writer，告知数据「已落盘」。
同时当数据传输到 journal 时，数据也会放入到 write cache 里，用 journal 结构保证里数据持久化的同时还有低延迟特性，主要体现在读过程。
数据盘里主要有两种类型：Index 和 entry log。Entry log 是真正放数据的地方，index 的主要功能则是索引。所以 consumer 会先去 index 查看这条消息存放在了哪个 entry 然后再去读取 entry log。
🎙️ Pulsar 在 Verizon 的更迭
下图则简单用时间线方式让大家看一下 Pulsar 在 Verizon 内部使用时的一些更新细节。
第一代的存储设备都是采用 HDD 模式，第二代的存储设备则是采用 SSD/NVMe 模式，目前使用的 PMEM 模式。下图简单对比了这几代磁盘存储性能。
为什么会有这样的变化呢？从价格梯度上看，HDD 价格是相对便宜的，NVMe 采用 PCI-E 的总线，可以提供更多队列，这样 IOPs 就可以更高，支持更高的带宽。
而 PMEM 价格最高、表现性能最好，但 PMEM 是最贴合 BookKeeper 的存储架构。可以看出从 NVMe 到 PMEM 的性能提升了 5 倍。
在这里，他们主要介绍了
「要实现和 Kafka 一样的性能效果，在 Pulsar 端会呈现什么样的对等关系」
。
迁移前，Kafka 集群内有 33 个 brokers
迁移后，Pulsar 集群只用了 10 个 bookies 和 16 个 brokers
Pulsar broker 是一个无状态的组件，成本是 BookKeeper 存储价格的四分之一
按照总价格和数量平均计算下来，替换后，Pulsar 成本为 Kafka 价格的二分之一
一是可以使用 PMDK API 访问持久内存。因为这个模式下可以绕过文件系统，并拥有更好的吞吐量，达到更好的性能效果。
二是将 tiered-storage 的分层存储利用起来。因为 tiered-storage 可以放宽延迟需求，降低成本花销。同时在适用场景上，也可以适配更多，比如：ML模型培训、审计和取证等。
Q：线上场景的 benckmarking 与 mock，请问有“时光隧道、Monkey test”等的现成方案或者推荐实现方式吗？因为我们想基于 BookKeeper 做永久存储，但是没有一个时光隧道的机制，没法测试几个月、几年后是否能继续读。还有就是我们对顺序与 0 丢失要求非常严格，需要模拟各种故障的场景。
A：类似 Monkey test，我们公司内部也在做一些尝试，目前使用的是 PingCap 开源的 chaos-mesh。像时光机测试等，是一个很好的需求，后期可以考虑合作等。
对于文中提到的顺序和 0 丢失，其实是 Pulsar 的强项。所以可以多尝试 Pulsar 哦。
Q：我看文档 Message deduplication 可以留一个数据的最新版本，这里有没有考虑可以设置保存最近 N 个版本呢？我们需要保留多个版本用于问题跟进等处理，但是又不想无止境的存储历史版本，只想存储最新的 N 个版本。
A：这个情形其实跟 message compact 有关系。每个 topic 可以对应多个消息版本，可以把前边所有消息的 key 压缩掉，只保留 key 的最新消息。后续可以考虑在 message compact 里添加类似参数进行设置。
Q：我们生产环境中 topic 的保留时间都是 3 天，对于 SSD 作为 ledger 盘而言，可能一时难以做替换升级，目前还是采用 journal 盘 SSD、ledger 盘 HDD，请问有比较好的优化策略，比如让 cache 命中率更高。
A：用 HDD 的话，在读写中可能对 index 的影响会大一些。比较直观的策略是可以把 RocksDB 读写的配置扩大一些。
本周我们分享了 Verizon 公司如何使用 Pulsar ，进一步展示了 Pulsar 的优势和功能。
大家可以观看下方直播回放查看更多细节。同时关于此 topic slides 可以复制链接进行查看或下载：
https://www.slidestalk.com/ApachePulsar/tgipcn016
本周末我们将继续为大家带来 TGIP-CN 的直播，为大家介绍
Pulsar 2.6.0 版本中的更新细节
，点击阅读原文进行新一期的 TGIP-CN 报名吧！
