Apache Pulsar 的访问模式与分层存储

原作者：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 中消息流程图解

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 中不同级别缓存概览

第一级缓存是 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 起支持谷歌云存储。