Pulsar Overview

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

关键特性

• 跨地域复制（ 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）中

概念框架

• apache pulsar中基本的消费模型就是 producer-topic-consumer，其中消费者consumer订阅消息的模式有四种：独占（exclusive）， 共享（shared），故障转移/灾备（failover）和 键共享（key_shared）。不同的消息订阅模式会有不同数量的消费者消费topic的消息（exclusive：1，shared：N，failover：1+N，key_shared：N）。
• 逻辑实现上，Broker消息服务器是真正处理消息的模块，用来收发消息、负载均衡， 每个topic属于某一个broker（或者说被某个broker处理），为了提高topic的消息处理能力，有一个「分区topic（Partitioned topics）」的概念，使得某个topic可以被多个broker处理，具体地，某一个topic有多个分区partition（可以理解为多个内部的topic），这些分区被pulsar自动分配给多个broker处理。
• 管理层级上，主要是「集群cluster——租户tenant——命名空间Namespace——主题Topic」四个等级，一个pulsar cluster有一个或多个租户tenant，一个租户tenant有一个或多个命名空间Namespace，一个命名空间Namespace管理多个相关联的topic。
• 架构上，一个pulsar cluster包含三个要素：一个或多个broker，一个BookKeeper，一个ZooKeeper。其中BookKeeper做消息的存储，broker做消息的处理计算，pulsar依靠BookKeeper，实现了「存储计算分离」的架构，这是有别于其他MQ最大的一点。还有一个ZooKeeper主要是负责存储broker和BookKeeper的元数据，以及pulsar clusar的集群配置协调工作。
• 单独再看BookKeeper，
  • BookKeeper将数据存储至集群中的节点上，每个BookKeeper节点称为Bookie。
  • 一个Topic由多个Ledger构成，一个Ledger由一个或多个Fragment组成，每个Fragment有多个条目Entry组成，每个Entry上包含的就是消息Message。
  • Fragment是BookKeeper集群中最小的分布单元，Ledger是最小的删除单元。
  • Topic是Pulsar中的概念。Ledger和Fragment是BookKeeper中的概念。
  • 每个Pulsar Broker都需要跟踪每个Topic所包含的Ledgers和Fragments。这个元数据存储在Zookeeper中。
  • Fragments分布在Bookie集群中，跨多个Bookies带状分布。存储可以单独扩展。如果存储是瓶颈，那么只需要添加更多的Bookies，他们会自动承担负载，不需要Rebalance。
  • 当Bookie不可用时，自动恢复模式将自动进行数据重新复制到其他的Bookies。

基本概念

Topic

主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由broker分发到不同的订阅者，实现消息的广播

cluster & Multi Tenancy

• Property/tenant——租户（Pulsar 2.0中已经移除了"property"的术语）；Namespace——命名空间

• Pulsar 的多租户性质主要体现在 topic 的 URL 中，其结构如下：

  Pulsar 2.0版本之前：{persistent|non-persistent}://property/cluster/namespace/topic
  Pulsar 2.0版本：{persistent|non-persistent}://tenant/namespace/topic

  其中persistent代表持久消息存储，persistent/tenant代表租户；

• Namespace将相关联的 topic 作为一个组来管理，是管理 Topic 的基本单元。 大多数对 topic 的管理都是对Namespace的一项配置。 每个Property可以有多个Namespace。

消息订阅模式

Pulsar 中有 4 种可用的订阅模式： 独占（exclusive）， 共享（shared），故障转移/灾备（failover）和 键共享（key_shared）。 下图展示了这四种模式：

Exclusive（独占）

只能有一个Consumer消费topic的消息，超过一个Consumer会收到错误

Failover（灾备）

同一时刻只有一个有效的Consumer，其余的Consumer作为备用节点，在Master Consumer不可用后进行替代

Shared（共享）

• 可以同时存在多个Consumer，每个Consumer处理Topic中一部消息
• 消息通过轮询机制分发给不同的消费者，并且每个消息仅会被分发给一个消费者
• 当某个消费者断开连接，所有被发送给它但没有被确认的消息将被重新安排，分发给其它可用的消费者
• 注意：
  • 当使用shared模式时，消息的顺序不被保证
  • 不能在共享模式下使用累积确认（cumulative acknowledgment）
    

Key_Shared（键共享）

• 类似于shared模式，但是相同键（key）的消息会传递给同一个消费者
• 注意：
  • 需要为消息指定一个 key 或 orderingKey
  • Key_Shared 模式不能使用累积确认（cumulative acknowledgment）
    

分区 topic（Partitioned topics）

• 单个topic的消息一般是由单个broker处理，这限制了top的最大吞吐量，为了提高topic的消息处理能力，pulsar提供了partitioned topic的支持，这样使得某个topic可以被多个broker处理
• 具体地，某一个topic有多个partition（可以理解为多个内部的topic），每个partition由不同的broker处理，在消费时，单个partition可选择exclusive, failover和shared模式
• 下图中，Topic1有5个分区（P0~P4），由pular自动分布给3个broker，其中有两个broker要处理两个分区。第三个broker则只处理一个

架构

一个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

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 分层存储

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

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