Apache Pulsar 是一款开源的分布式消息系统，它设计用于高性能、可靠的云原生环境，可支持大规模、多租户的消息与流数据传输。在深入理解 Pulsar 之前，我们先从它的整体架构说起。
1、Pulsar 是什么？
Pulsar 本质上是一个分布式消息与流处理平台。它与 Kafka 等系统类似（对比如下），但提供了更加灵活的架构设计，例如存储与计算分离、原生支持多集群复制、以及多租户管理等。
| 对比维度 | Kafka | Pulsar |
|---|---|---|
| 存储模型 | 基于 Partition 分区+副本存储 | 基于 Ledger→Segment→Entry 分层存储 |
| 消费模型 | 消费者组模式，1 分区对应 1 消费者 | 订阅+Cursor 模式，多订阅独立消费 |
| 部署复杂度 | 去除 ZK 后部署简单 | 依赖 ZK+BookKeeper，部署较复杂 |
| 多租户支持 | 无原生支持 | 原生 Tenant+Namespace 三级隔离 |
| 吞吐量（2c4g） | 20 万级 QPS | 100 万级 QPS |
2、 Pulsar 体系结构总览
Pulsar 的总体架构可以粗略分为以下几个层级：
- Pulsar 实例（Instance）：可以包含多个物理或逻辑上的 Pulsar 集群。
- Pulsar 集群（Cluster）：是一个完整的 Pulsar 单元，包含消息处理与存储组件。
-
跨集群复制：集群之间默认是互不干扰的，可以通过开启Geo-replication让集群间的数据进行复制同步（比如可以让topic1 在 cluster-a、cluster-b各自有一份数据）。
Pulsar 总体架构
本篇我们主要聚焦 Pulsar 的核心架构组件以及它们之间如何协同工作。
3、 核心组件解析
3.1 Broker（入口及核心）
Broker 是 Pulsar 的“入口”和“调度中心”。它负责：
- 接收生产者（Producer）发送的消息；
- 将消息分发给消费者（Consumer）；
- 维护客户端连接；
- 与 ZooKeeper 和存储服务（BookKeeper）协调。
Broker 本身是无状态的，它不直接存储消息，而是负责管理流转与缓存。只有在本地缓冲不足时它才会从存储系统拉取数据。
3.2 BookKeeper（又名Bookie，持久存储）
Pulsar 使用 Apache BookKeeper 作为消息的持久化存储层。它的优势包括：
- 将每个主题的数据写入多个独立的日志（称为 ledgers）；
- 支持高可靠性数据复制；
- 横向扩展能力强，并且读写性能良好。
消息由 Broker 写入 BookKeeper，只有成功写入后才被认为是可靠的持久消息（除非使用非持久消息）。
3.3 ZooKeeper（协调与元数据）
Pulsar 使用 ZooKeeper 作为元数据管理与协调服务，包括：
- 集群配置和负载信息；
- 主题所有权与分区信息；
- Broker 与 BookKeeper 之间的协调。
整个 Pulsar 系统至少会有两个 ZooKeeper 集群：
- 配置存储（Configuration Store）：负责跨集群配置；
- 本地集群 ZooKeeper：协调同一集群内部的 Broker 与 BookKeeper。
PS: 新版本的pulasr可被 etcd 替代了
3.4 Pulsar Proxy（可选入口）
在某些场景下，客户端不能直接访问 Broker，例如：
- 受到网络策略限制；
- 使用云环境、Kubernetes 等平台。
这时可以使用 Pulsar Proxy，作为客户端与 Broker 之间的中间入口，处理连接代理和负载，Pulsar 支持用一个统一的服务 URL，让客户端只需接入这个入口即可与整个 Pulsar 实例互动。背后会将请求路由到正确的 Broker。
4、Pulsar 的工作流程
下面是一条消息从生产到消费的核心路径：
- 生产者发送消息给 Broker；
- Broker 将消息写入 BookKeeper 持久存储；
- BookKeeper 将日志记录到多个 Bookie（存储节点）；
- 消费者从 Broker 拉取消息，Broker 使用缓存或从存储读取数据。
Pulsar 工作流程
这种存储与处理分离的架构使得 Pulsar 在负载激增、集群扩容时表现稳定且可预测。
