Apache Pulsar：云原生消息与流平台

Apache Pulsar 是一个面向云原生和多租户场景的分布式消息与流平台。
它和 Kafka、RabbitMQ 最大的不同在于：Broker 无状态，消息存储交给 Apache BookKeeper，天然支持存储计算分离和多租户治理。

一句话理解

Pulsar 像一个“多租户消息平台”：业务按 Tenant/Namespace 隔离，Broker 负责接入和调度，BookKeeper 负责持久化日志，消费者通过不同订阅模式读取消息。

mermaid

flowchart LR
  Producer[Producer] --> Broker[Pulsar Broker]
  Consumer[Consumer] --> Broker
  Broker --> BK[(BookKeeper Bookies)]
  Broker --> Meta[(Metadata Store)]
  Admin[Admin API / pulsar-admin] --> Broker

适合与不适合

适合：

多业务线共用一套消息平台。
需要租户、命名空间、配额和权限治理。
需要存储和计算独立扩展。
需要多订阅模型、跨地域复制、分层存储。

不适合：

团队只需要简单任务队列，RabbitMQ 更轻。
主要依赖 Kafka 生态和 Kafka Streams，Kafka 更成熟。
运维团队暂时不想维护 Broker + BookKeeper + 元数据组件。

核心对象模型

对象	说明
Tenant	租户，最高级别的管理和隔离单位
Namespace	租户下的逻辑空间，用于配置策略、配额、权限
Topic	消息主题
Partitioned Topic	分区主题，提高并行度
Subscription	订阅，保存消费进度和分发语义
Producer	生产者
Consumer	消费者
Reader	类似低级别读取 API，可从指定位置读

Topic 命名格式：

txt

persistent://tenant/namespace/topic
non-persistent://tenant/namespace/topic

架构组件

mermaid

flowchart TD
  subgraph Client[客户端]
    P[Producer]
    C[Consumer]
    R[Reader]
  end

  subgraph Serving[服务层]
    Proxy[Pulsar Proxy 可选]
    Broker1[Broker]
    Broker2[Broker]
  end

  subgraph Storage[存储层]
    B1[Bookie 1]
    B2[Bookie 2]
    B3[Bookie 3]
  end

  Meta[(Metadata Store)]

  P --> Proxy --> Broker1
  C --> Proxy --> Broker2
  Broker1 --> B1
  Broker1 --> B2
  Broker2 --> B2
  Broker2 --> B3
  Broker1 --> Meta
  Broker2 --> Meta

Broker

Broker 主要负责：

客户端连接。
Topic lookup。
消息路由和分发。
订阅和游标管理。
权限、限流、配额。

BookKeeper

BookKeeper 负责持久化存储：

消息写入 ledger。
多副本复制。
高可用和故障恢复。
支持历史数据分层存储。

Metadata Store

保存集群元数据：

租户、命名空间、Topic。
Schema。
Broker 负载。
BookKeeper ledger 元数据。

四种订阅模式

模式	分发方式	顺序性	场景
Exclusive	单消费者独占	强	严格单消费者处理
Failover	主备消费者	强	有序 + 高可用
Shared	多消费者轮询/分摊	弱	高吞吐任务处理
Key_Shared	同 key 到同消费者	key 内有序	订单/用户维度保序

mermaid

flowchart TD
  Topic[Topic] --> Sub[Subscription]
  Sub --> Exclusive[Exclusive: 1 个活跃消费者]
  Sub --> Failover[Failover: 主备切换]
  Sub --> Shared[Shared: 多消费者并行]
  Sub --> KeyShared[Key_Shared: 同 key 保序]

消息写入与消费流程

mermaid

sequenceDiagram
  participant P as Producer
  participant B as Broker
  participant BK as BookKeeper
  participant C as Consumer

  P->>B: send(message)
  B->>BK: append to ledger
  BK-->>B: write ack
  B-->>P: send ack
  B->>C: dispatch message
  C-->>B: ack
  B->>B: 更新 subscription cursor

Pulsar 通过 subscription cursor 保存每个订阅的消费进度。不同订阅之间互不影响。

Schema 能力

Pulsar 内置 Schema Registry，支持：

Avro
JSON
Protobuf
KeyValue
Bytes/String 等基础类型

Schema 的价值：

生产端和消费端共享消息结构。
防止不兼容字段变更。
支持 schema 演进和版本管理。

高级能力

能力	说明	场景
Delayed Delivery	延迟投递消息	超时任务、延迟通知
Message TTL	消息过期	控制堆积与生命周期
Retention	消息保留	回放与审计
Backlog Quota	堆积配额	防止租户占满资源
Geo-Replication	跨集群复制	多地域容灾
Tiered Storage	分层存储	历史数据低成本保存
Pulsar Functions	轻量流处理	消息转换、过滤、富化
Pulsar IO	Source/Sink 连接器	对接数据库、文件、其他 MQ

分层存储

Pulsar 可以把已经封存的 BookKeeper ledger 下沉到对象存储，例如 S3、GCS、Azure Blob。

mermaid

flowchart LR
  Producer --> Broker
  Broker --> BK[(BookKeeper 热数据)]
  BK -->|offload| Object[(S3/GCS/Azure Blob 冷数据)]
  Consumer --> Broker
  Broker --> BK
  Broker --> Object

这样可以在保留长期历史消息的同时降低热存储成本。

Pulsar Functions 与 IO

mermaid

flowchart LR
  Source[Source Connector] --> TopicA[Input Topic]
  TopicA --> Fn[Pulsar Function]
  Fn --> TopicB[Output Topic]
  TopicB --> Sink[Sink Connector]

典型用途：

消息过滤。
字段转换。
数据富化。
轻量实时 ETL。
从数据库导入或导出到外部系统。

统一案例：订单超时关闭 + 支付成功发券

资源规划

层级	示例
Tenant	`commerce`
Namespace	`order-prod`
Topic	`persistent://commerce/order-prod/order-created`
Topic	`persistent://commerce/order-prod/order-timeout-check`
Topic	`persistent://commerce/order-prod/order-paid`
Topic	`persistent://commerce/order-prod/coupon-issue`

流程图

mermaid

flowchart LR
  Order[订单服务] -->|delayed message| Timeout[order-timeout-check]
  Timeout -->|Key_Shared orderId| TimeoutC[超时检查消费者]
  TimeoutC --> OrderDB[(订单库)]

  Payment[支付服务] --> Paid[order-paid]
  Paid -->|Shared| CouponC[发券消费者]
  CouponC --> CouponDB[(券库)]

订阅设计

order-timeout-check 使用 Key_Shared，同一个 orderId 的检查和状态事件尽量落到同一消费者。
coupon-issue 使用 Shared，提高发券并行度。
发券服务仍然要幂等，避免重复投递导致重复发券。

监控指标

指标	含义
backlog	订阅堆积
msgRateIn/msgRateOut	生产/消费速率
publish latency	生产延迟
dispatch rate	broker 分发速率
BookKeeper write latency	存储写入延迟
storage size	存储占用
subscription ack rate	ack 速率

常见坑

Shared 订阅用于要求同 key 顺序的业务。
Tenant/Namespace 没规划好，后期权限和配额混乱。
不设置 backlog quota，单业务堆积影响整个平台。
只关注 Broker，忽略 BookKeeper 磁盘和写延迟。
Schema 演进不受控，下游消费失败。
把 Functions 当复杂计算平台，导致职责过重。

参考资料整理

Pulsar Overview：Pulsar 总体能力。
Architecture Overview：Broker、BookKeeper、Metadata Store 架构。
Messaging Concepts：Topic、Subscription、ack、retention 等消息概念。
Schema Overview：内置 Schema Registry。
Tiered Storage：分层存储。

Apache Pulsar：云原生消息与流平台 ​

一句话理解 ​

适合与不适合 ​

核心对象模型 ​

架构组件 ​

Broker ​

BookKeeper ​

Metadata Store ​

四种订阅模式 ​

消息写入与消费流程 ​

Schema 能力 ​

高级能力 ​

分层存储 ​

Pulsar Functions 与 IO ​

统一案例：订单超时关闭 + 支付成功发券 ​

资源规划 ​

流程图 ​

订阅设计 ​

监控指标 ​

常见坑 ​

参考资料整理 ​

Apache Pulsar：云原生消息与流平台

一句话理解

适合与不适合

核心对象模型

架构组件

Broker

BookKeeper

Metadata Store

四种订阅模式

消息写入与消费流程

Schema 能力

高级能力

分层存储

Pulsar Functions 与 IO

统一案例：订单超时关闭 + 支付成功发券

资源规划

流程图

订阅设计

监控指标

常见坑

参考资料整理