5000字阐述云原生消息中间件Apache Pulsar的核心特性和设计概览

Apache Pulsar 是 Apache 软件基金会顶级项目，自称是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。

Pulsar 是一个用于服务器到服务器的消息系统，具有多租户、高性能等优势。Pulsar 最初由 Yahoo 开发，目前由 Apache 软件基金会管理。

目前的Pulsar社区发展十分迅速，Pulasr的版本也在不断的更新迭代，目前大版本的迭代已经到了2.8，本文是结合我个人在Github和Pulsar社区中对Pulsar的探索过程中总结的，云原生的时代，Pulsar能否大放异彩，值得我们期待。

本文是一个引子，后续我会对Pulsar进行非常详细的介绍。

Pulsar中的核心概念

这部分你可能会看到非常多的概念跟Kafka相关，我们一起来看一下：

• Topic

是不是很熟悉，在Kafka中也有Topic的概念。

Topic 是一个消息目录或者说存放消息的命名空间，也就是消息发布（生产）的位置。一个 topic 可以有一个或多个 producer 和/或 consumer。Producer 向 topic 写入消息，consumer 从 topic 消费消息。图 1 展示了三者之间如何协同工作。

• Bookie

Apache Pulsar 使用 Apache BookKeeper 作为存储层。Apache BookKeeper 针对实时工作负载进行优化，是一项可扩展、可容错、低延迟的存储服务。客户端发布的消息存储在 BookKeeper 的服务器实例中，即 bookie。

Ledger 是 BookKeeper 中的基本存储单元。一系列的 entry 组成一个 ledger，entry 被顺序写入 ledger。

Journal 文件包含 BookKeeper 中的消息写入日志。在更新 ledger 前，bookie 确保已经将更新的交易（交易日志 entry）写入非易失存储。在 bookie 第一次运行或旧的 journal 文件大小达到指定阈值时，会创建新的 journal 文件。

Entry log 文件用于管理 BookKeeper 客户端写入的 entry。来自不同 ledger 的 entry 会被依次写入一个或多个 entry log 中，而偏移量则作为指针保存在 ledger 缓存中，以进行快速查找。

• Broker

和Kafka一样，在 Pulsar 中，broker 是一个无状态服务器，用于协助读写数据。一个 topic 不能同时被多个 broker 管理，但是 topic 可以存储在多个 bookie 服务中。

• Entry

Entry是存储到bookkeeper中的一条记录

• Ledger

可以认为ledger是用来存储Entry的，多个Entry序列组成一个ledger

• MetaData Storage

元数据存储，是用于存储bookie相关的元数据，比如bookie上有哪些ledger，bookkeeper目前使用的是zk存储，所在在部署bookkeeper前，要先有zk集群

• Journal

其实就是bookkeeper的WAL(write ahead log)，用于存bookkeeper的事务日志，journal文件有一个最大大小，达到这个大小后会新起一个journal文件

• Entry log

存储entry的文件，我理解ledger是一个逻辑上的概念，不同ledger中的entry会先按ledger聚合，然后写入entry log文件中。同样，entry log会有一个最大大小，达到最大大小后会新起一个新的entry log文件

• Index file

ledger的索引文件，ledger中的entry被写入到了entry log文件中，索引文件用于对entry log文件中每一个ledger做索引，记录每个ledger在entry log中的存储位置以及数据在entry log文件中的长度

• Ledger cache

用于缓存索引文件的，加快查找效率

• 数据落盘

内存中会存储一个LastLogMark，其中包含txnLogId(journal文件的id)和txnLogPos(journal文件中的位置)，entry log文件和index文件都会先在内存中被缓存，当内存达到一定值或者离上一次刷盘过期了一段时间（定时线程）后，会触发entry log文件和index文件的刷盘，之后再将LastLogMark持久化，当lastLogMark被持久化后，表示在lastLogMark之前的entry和索引都已经写到了磁盘上，这个时候可以将lastLogMark之前的journal文件清掉，如果LastLogMark在持久化前出现了宕机，可以通过journal文件做恢复，保证了数据不丢

• Data Compaction

数据的合并，有点类似于hbase的compact过程。在bookie上，虽然entry log在刷盘前会按ledger做聚合，但是因数数据会不断的新增，每个leadger的数据会交差存储在entry log文件中，而bookie上有一个用于做垃圾回收的线程，该线程会将没有关联任何ledger的entry文件进行删除，以便回收磁盘空间，而compaction的目的则是为了避免entry log中只有少数的记录是有关联的ledger的情况，不能让这样的entry log文件一直占用磁盘空间，所以垃圾收集线程会将这样的entry log中有关联ledger的entry复制到一个新的entry log文件中（同时修改索引），然后将老的entry log文件删除。与hbase类似，bookkeeper的compaction也分为两种：

• Minor compaction

当entry log中有效的entry只占20#以下时做compaction

• Major compaction

当entry log中有效的占到80%以下时就可开始做compaction

关键特性

• 跨地域复制（ geo-replication），单个实例原生支持多个集群（跨集群复制）
• 极低的发布延迟和端到端延迟
• 可无缝扩展到超过一百万个 topic
• 简单的客户端API，支持Java、Go、Python和C++
• 支持多种topic订阅模式：独占订阅、共享订阅、故障转移订阅、键共享（exclusive, shared, failover, key_shared）
• 通过 Apache BookKeeper 提供的持久化消息存储机制保证消息传递
• 由轻量级的无服务器（serverless ）计算框架 Pulsar Functions 实现流原生的数据处理
• 基于 Pulsar Functions 的无服务器连接器框架 Pulsar IO 使得数据更易移入、移出 Apache Pulsar
• 分层式存储可在数据陈旧时，将数据从热存储卸载到冷/长期存储（如S3、GCS）中

Pulsar的架构设计

一个Pulsar实例由一个或多个Pulsar集群组成。实例中的集群可以在它们之间复制数据。一个Pulsar cluster由三部分组成：

• 一个或者多个 broker ：负责处理和负载均衡 producer 发出的消息，并将这些消息分派给 consumer；Broker 与 Pulsar 配置存储交互来处理相应的任务，并将消息存储在 BookKeeper 实例中（又称 bookies）；Broker 依赖 ZooKeeper 集群处理特定的任务；
• 一个BookKeeper：包含一个或多个 bookie 的 BookKeeper 集群负责消息的持久化存储；
• 一个ZooKeeper：特定于某个Pulsar集群的ZooKeeper集群处理Pulsar集群之间的协调任务。

特别需要注意的是：集群间可以通过跨地域复制（Geo-Replication）进行消息同步。

ZooKeeper负责存储元数据，集群配置，协调：其中local zk负责Pulsar Cluster内部的配置，global zk则用于Pulsar Cluster之间的数据复制。

Bookie负责存储；Broker负责负载均衡和消息的读取、写入等；Global replicators负责集群间的数据复制。

Apache BookKeeper

在这里我们赵中介绍一下Apache BookKeeper。Pulsar用 Apache BookKeeper作为持久化存储，BookKeeper有以下几个特性：

• 利用多个ledger保存独立的日志
• 为按条目复制的顺序数据提供了非常高效的存储
• 保证了多系统挂掉时ledgers的读取一致性
• 提供不同的Bookies之间均匀的IO分布的特性
• 在容量和吞吐量上都可以水平扩展。通过向集群添加更多bookie，可以立即增加容量
• Bookies可以包含数千个具备同时读写功能的ledger。使用多个磁盘设备，一个用于日志，另一个用于一般存储，这样Bookies可以将读操作的影响和对于写操作的延迟分隔开
• 除消息数据外，游标（cursors）还永久存储在BookKeeper中；Cursors是消费端订阅消费的位置；BookKeeper让Pulsar可以用一种可扩展的方式存储消费位置

Ledgers

Ledger是一个只追加（append-only）的数据结构，并且只有一个写入器，这个写入器负责多个BookKeeper存储节点（就是Bookies）的写入。Ledger的条目（entries）会被复制到多个bookies。Ledgers具有以下特性：

• Pulsar Broker可以创建ledeger，添加内容到ledger和关闭ledger。
• 当一个ledger被关闭后，除非明确的要写数据或者是因为写入器挂掉导致ledger关闭，这个ledger只会以只读模式打开。
• 最后，当ledger中的条目不再有用的时候，整个legder可以被删除（ledger分布是跨Bookies的）。

Pulsar geo-replication

• 多个Broker节点组成一个Pulsar Cluster；多个Pulsar Cluster组成一个Pulsar Instance。
• Pulsar通过geo-replication支持一个Instance内在不同的集群发送和消费消息。

下图说明了 Pulsar 在不同集群之间跨地域复制的过程：

在上图中，每当P1，P2和P3生产者将消息分别发布到Cluster-A，Cluster-B和Cluster-C群集上的T1主题时，这些消息就会立即在群集之间复制。复制消息后，C1和C2使用者可以使用它们各自群集中的消息。没有geo-replication，C1和C2使用者将无法使用P3产生者发布的消息。

分层存储

通过使用分层存储（Tiered Storage），在 backlog 中的旧消息可以从 BookKeeper 转移到更廉价的存储中，不出其他问题，客户端将仍然可以访问 backlog，降低了存储成本。

Pulsar 当前支持 S3, Google Cloud Storage (GCS) 和文件系统（filesystem）来做长期存储（long term store）。可以将数据卸载（Offloading）到长期存储中。

Pulsar的核心设计

• 保证不丢失消息

我们直接饮用Pulsar官方博客中的总结：Pulsar Broker是无状态的，没有不能丢失的持久化状态，与存储层分开。

Bookeeper集群本身并不执行复制，每个Bookies只是一个跟随者被领导者人知做什么，领导人是Pulsar Broker。每个Topic都由一个Pulsar Broker拥有，该Broker提供Topic的所有读写操作。Pulsar通过让领导人(Pulsar Broker)没有状态，BookKeeper的fencing特性可以很好的处理脑裂问题。没有脑裂，没有分歧，没有数据丢失。

此外，当在Bookie上写入数据时，首先将该消息写入日志文件，这是一个预写日志(WAL)，它可以帮助BookKeeper在发生故障时避免数据丢失。它与关系型数据库持久化保证的机制相同。

• 强顺序性保证

Pulsar的顺序保证只在特定的模式下才能得到保证。BookKeeper容许将磁盘IO做读写分离。写入都按顺序写入日志文件可以存储在专用的磁盘上，并且可以批量刷盘以获得搞得吞吐量。除此之外从写入操作来看没有其他的同步磁盘IO操作，数据都是写入到内存的缓存区。

• 读写延迟

关于读写延迟测试你可以参考官方给出的文档：

https://blog.csdn.net/zhaijia03/article/details/111602732

这个文档包含了 Pulsar 和 Kafka 支持的各持久性级别，以及在同一持久性级别下两者的吞吐量和延迟的对比。