共计 2256 个字符，预计需要花费 6 分钟才能阅读完成。
原作者：Ivan Kelly
翻译：StreamNative——Sijia
之前咱们谈到了 Apache Pulsar 如何利用 BookKeeper 多正本的工作形式以及 BookKeeper 中不同的 I/O 模式。本文将探讨在 Pulsar 中多正本怎么与不同的 I/O 模式交互，以及 Pulsar 如何通过这种交互实现分层存储等。从实质上看，Pulsar 采纳分层架构，而这种分层架构使得每种 I/O 模式都能够独立工作，因而读写之间永远不会互相烦扰。分层还简化了以与 Pulsar 齐全集成的形式增加存储层的操作，从而在对应用 Pulsar 的开发者不产生任何影响的条件下，升高减少存储层的老本，并进步新增存储层的可扩展性。
Pulsar 是一个提供公布 - 订阅和排队语义的音讯零碎。客户端能够是 producer 或 consumer，也能够是两者组合。生产客户端向 broker 发送音讯，生产客户端从 broker 生产音讯。Pulsar 将音讯整顿寄存在 topic 中，并把 topic 调配给 broker。在一个 topic 内，Pulsar 保障全序原子播送（Total Order Atomic Broadcast），也就是说，一旦 Pulsar broker 向 producer ack topic 中某音讯的公布，绝对于同一 topic 中的其余音讯，此音讯将永远不会失落、被复制或被从新排序。并且，音讯程序完全相同，所有 consumer 读取音讯的程序也完全相同。
Pulsar 应用 BookKeeper 作为 topic 积压音讯的后备存储。Pulsar broker 作为 BookKeeper 存储顶部的无状态服务层。当 producer 向 Pulsar 发送音讯时，Pulsar 立即将此音讯写入 BookKeeper。一旦 BookKeeper ack 写操作，broker 便能够向 producer ack 音讯公布，并且 consumer 能够读音讯。
音讯零碎中通常有三种 I/O 模式。
- 写 ：公布音讯到音讯零碎；
- 追尾读 ：写入后，立刻发送音讯给沉闷订阅者；
- 追赶读 ：新 consumer 想从最新消息之前的某个点开始读取，或现有 consumer 长时间离线后返回时，consumer 从日志后缀中读取大量音讯以进行追赶。
不同于大多数其余音讯零碎，Pulsar 中每种 I/O 模式之间互相隔离。
最乏味的 I/O 模式是写模式，所有其余模式都遵循该模式。当 Pulsar broker 想为某个 topic 长久化音讯时，broker 会将此音讯写入一组 BookKeeper 节点，这组节点就定义为该 topic 日志的写入 quorum。每个接管音讯的 BookKeeper 节点都将此音讯增加到节点的日志文件中，而节点的日志文件寄存于专用磁盘上。当足够多的节点 ack 写入以满足日志的多正本（即 ack quorum）要求时，则认为写操作已提交，并已向 producer ack。从这一点开始，该音讯不可变，并且该音讯将会始终占用日志偏移量。其余音讯都不能够占用这个偏移量，此音讯也不可再更改。
能够利用音讯的不可变性无效地服务于音讯零碎的其余 I/O 模式。在 BookKeeper 节点日志中写入音讯是标准的，并且如果用户停在这里，依然能够拜访此音讯。然而，这样做效率不高，因为每次读都须要扫描所有日志以查找所需音讯，并且不能截断日志来开释磁盘空间。不过已提交音讯的不可变性容许在多个地位缓存该音讯，以无效地进行读操作。
第一级缓存是 Pulsar broker，可用于追尾读。提交音讯后，能够间接将音讯发给所有与此 topic 相干的订阅者，而不用应用磁盘。
下一级缓存是 BookKeeper 节点上的 ledger 存储磁盘。将音讯写入 BookKeeper 节点上的日志时，同时也写入到定期 flush 的 ledger 存储磁盘的内存缓冲区。BookKeeper 节点应用此磁盘提供读操作。在 Pulsar 中，从内存缓冲区读音讯很少见。追尾 consumer 通常间接从 Pulsar 的缓存中读音讯。追赶 consumer 通常申请很早之前的音讯，因而这些音讯个别不存储在内存缓冲区。Ledger 存储磁盘服务于追赶读。Ledger 存储磁盘采纳的存储音讯的格局不仅保障在同一 topic 上尽可能按程序读取，还优化了在同一磁盘上存储多个不同 topic 的能力。因为 ledger 存储磁盘与日志磁盘互相隔离，读操作不会影响日志磁盘中按程序写入的性能。
如果为 Pulsar 配置了“分层存储”，则最初一级缓存为长期存储。分层存储容许用户对 topic backlog 中的较旧局部采纳更节约老本的存储模式。分层存储利用了音讯的不可变性，但粒度更大，因为在长期存储中独自存储每条音讯会很节约空间。Pulsar topic 日志由分片组成，每个分片默认对应一个蕴含 50000 条音讯的序列。沉闷分片只有一个，沉闷分片之前的分片将敞开。当分片敞开时，无奈持续增加新音讯。假设分片中的单条音讯不可变，并且单条音讯的偏移量不可变，则此分片不可变。因而能够复制不可变对象到想要的任何地位。
要在 Pulsar 中应用分层存储，用户必须应用基于工夫或基于大小的策略来配置 topic 命名空间以卸载分片。当命名空间中的 topic 达到策略中定义的阈值时，Pulsar broker 将 topic 日志中最旧的分片复制到长期存储中，直到该 topic 低于策略阈值。通过一段时间后，Pulsar 从 BookKeeper 中删除原来的分片，以开释磁盘空间。
Pulsar 反对将 Amazon S3 和 S3 兼容的对象存储用于长期存储，也反对 Azure 存储，并且从 Pulsar 2.2.0 起反对谷歌云存储。
