Pulsar 核心架构详解

原创于 2025-08-05 00:17:27 发布 · 1k 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#Pulsar #核心架构 #学习

MQ 专栏收录该内容

156 篇文章

订阅专栏

Apache Pulsar 是一个开源的分布式消息与流处理平台，由 Apache 软件基金会维护。它最初由 Yahoo 开发，现已被广泛应用于大规模、高吞吐、低延迟的实时数据处理场景。Pulsar 的核心架构设计具有高可扩展性、高可用性、多租户支持、持久化存储以及灵活的消息模型（如发布/订阅、队列、流式处理）等优势。

以下是 Pulsar 核心架构的详细解析：

一、Pulsar 整体架构概览

Pulsar 采用 分层架构（Layered Architecture），将消息的 服务层（Broker） 与 存储层（BookKeeper） 解耦。这种设计是其高性能和高可扩展性的关键。

Pulsar 的核心组件包括：

Broker（服务层）
Apache BookKeeper（存储层）
ZooKeeper（元数据与协调服务）
Pulsar Client（生产者与消费者）
Pulsar Proxy（可选，用于安全隔离）

二、核心组件详解

1. Broker（消息服务层）

功能：

接收来自生产者（Producer）的消息。
将消息转发给消费者（Consumer）。
管理主题（Topic）的订阅、路由、负载均衡。
与 BookKeeper 交互，持久化消息。
提供协议支持（如 Pulsar 协议、Kafka 兼容协议等）。

关键特性：

无状态设计：Broker 本身不存储消息数据，只负责消息的中转和协调，因此可以轻松水平扩展。
负载均衡：通过 ZooKeeper 或内置的负载均衡机制，自动将 Topic 分配到不同的 Broker。
多租户支持：支持命名空间（Namespace）级别的隔离，实现租户资源隔离。

示例：一个 Topic 的数据由 Broker 接收后，写入 BookKeeper，而 Broker 只保留元数据和连接状态。

2. Apache BookKeeper（持久化存储层）

功能：

提供高吞吐、低延迟、持久化的日志存储。
存储 Pulsar 的消息数据，确保数据不丢失。
支持副本（Ensemble）机制，实现数据高可用。

核心概念：

Ledger（账本）：一个只追加（append-only）的逻辑日志单元，每个 Ledger 包含多个 Entry（消息条目）。
Bookie：BookKeeper 的存储节点，负责存储 Ledger 数据。
Ensemble：一组 Bookie，用于存储一个 Ledger 的多个副本（默认 3 副本）。
Quorum：读写时需要确认的副本数量（如 writeQuorum=3, ackQuorum=2）。

优势：

分布式日志存储，支持并行读写。
数据自动复制，容错能力强。
支持尾部读取（tail reading）和任意位置读取，适合流处理。

举例：当 Broker 接收到消息时，会将其写入一个 Ledger，该 Ledger 的数据被复制到多个 Bookie 上，确保即使部分节点宕机，数据仍可恢复。

3. ZooKeeper（协调与元数据管理）

功能：

存储集群元数据（如 Broker 列表、Topic 配置、命名空间、权限等）。
实现分布式协调（如 Leader 选举、配置同步）。
管理 BookKeeper 的元数据（如 Ledger 位置、Bookie 注册信息）。

关键作用：

全局配置存储：所有组件通过 ZooKeeper 获取集群状态。
服务发现：Broker 启动时向 ZooKeeper 注册，客户端可通过 ZooKeeper 发现可用 Broker。
一致性保证：基于 ZAB 协议，确保元数据一致性。

注意：ZooKeeper 不参与消息的实时传输，仅用于元数据和协调，因此性能压力较小。

4. Pulsar Client（生产者与消费者）

生产者（Producer）：

将消息发布到指定的 Topic。
支持同步、异步、批量发送。
可配置消息路由策略（如轮询、键哈希等）。

消费者（Consumer）：

从 Topic 订阅消息。
支持多种订阅模式：
- Exclusive：单个消费者独占订阅。
- Shared：多个消费者共享订阅，消息负载均衡。
- Failover：主备模式，主消费者失败后切换。
- Key_Shared：按消息 Key 分配，相同 Key 的消息由同一消费者处理。

消费者组：多个消费者可以组成一个订阅组（Subscription），实现队列语义。

5. Pulsar Proxy（可选组件）

功能：

位于客户端与 Broker 之间，提供统一接入点。
支持 TLS 加密、认证、ACL 控制。
在云环境或 Kubernetes 中常用于简化网络配置。

优势：

客户端无需知道 Broker 的具体地址。
支持多租户网络隔离。
可集成到服务网格（如 Istio）中。

三、核心概念模型

1. Topic（主题）

消息的逻辑通道，命名格式如 persistent://tenant/namespace/topic。
支持两种类型：
- Persistent Topic：消息持久化存储在 BookKeeper。
- Non-Persistent Topic：消息仅在内存中传递，不持久化（适用于低延迟、可丢弃场景）。

2. Namespace（命名空间）

是租户（Tenant）下的逻辑分组，用于组织 Topic。
可配置策略：如配额、TTL、副本数、消息保留策略等。

3. Tenant（租户）

支持多租户，每个租户有独立的命名空间和配额。
适用于 SaaS、企业多部门隔离等场景。

4. Subscription（订阅）

消费者通过订阅（Subscription）消费消息。
每个订阅有独立的游标（Cursor），记录消费位置。
支持重置消费位点、延迟消费、死信队列等高级功能。

四、消息存储与读写流程

消息写入流程（Producer → Broker → BookKeeper）：

Producer 连接 Broker，发送消息到 Topic。
Broker 检查 Topic 路由，选择对应的 Ledger（或创建新 Ledger）。
Broker 将消息写入 BookKeeper 的多个 Bookie（通过 Ensemble）。
Bookie 返回确认（Ack），Broker 返回确认给 Producer。
消息持久化完成。

消息读取流程（Consumer 从 BookKeeper 读取）：

Consumer 订阅 Topic，Broker 根据订阅模式分配消息。
Broker 从 BookKeeper 读取 Ledger 中的消息（基于游标位置）。
消息推送给 Consumer（Pulsar 支持 Push 和 Pull 模式）。
Consumer 处理消息后发送 Ack，Broker 更新游标。

注：Pulsar 支持 游标持久化，即使消费者重启，也能从上次位置继续消费。

五、高可用与容错机制

机制	说明
Broker 故障转移	Broker 无状态，宕机后客户端可重连其他 Broker，Topic 会自动重新加载。
Bookie 故障	数据多副本存储，单个 Bookie 宕机不影响读写；BookKeeper 支持自动恢复（Autorecovery）。
ZooKeeper 高可用	ZooKeeper 集群部署，避免单点故障。
数据持久化	所有消息写入 BookKeeper，确保不丢失。
复制支持	支持跨地域复制（Geo-Replication），实现多数据中心容灾。

六、Pulsar vs Kafka 架构对比

特性	Pulsar	Kafka
架构	分层架构（Broker + BookKeeper）	单层架构（Broker 自带存储）
存储与计算分离	✅ 是	❌ 否
扩展性	Broker 和存储可独立扩展	扩展需同时增加 Broker 和磁盘
多租户支持	原生支持	较弱
订阅模式	多种（Exclusive, Shared, Key_Shared）	主要为 Consumer Group
消息保留	可配置 TTL 和保留策略	基于日志段删除
跨地域复制	原生支持 Geo-Replication	需 MirrorMaker