旋大爷的博客

消息队列04：Pulsar

从分层存储、多租户隔离到跨地域复制，拆解 Pulsar 在云原生消息场景下的架构设计和企业级能力。

字数 1942 阅读时长 ≈ 6 分钟 2026-7-13 2026-7-13
#Java #后端开发 #中间件
消息队列04：Pulsar

Pulsar 不是”又一个消息队列”，而是”云原生消息平台”。它的核心场景是跨地域复制、多租户隔离、分层存储和无限消息保留，适合企业级 SaaS、跨国业务、数据湖和流处理平台。

这篇文章围绕三个核心机制：分层存储、多租户、跨地域复制，把 Pulsar 与 Kafka 的差异和云原生场景下的选型逻辑讲清楚。

为什么选 Pulsar，而不是 Kafka

先定位清楚：Pulsar 的核心场景是云原生企业级消息，支持分层存储、多租户、跨地域复制和无限消息保留，适合 SaaS 平台、跨国业务、数据湖和长周期消息存储。

与 Kafka 的核心差异：

维度PulsarKafka
架构计算存储分离，Broker 无状态 + BookKeeper 存储Broker 和存储耦合，Broker 有状态
消息保留分层存储，冷数据下沉到 S3/HDFS，无限保留基于时间/大小清理，保留时间有限
多租户原生多租户，Tenant/Namespace 隔离不原生支持，需自己实现隔离
跨地域复制原生 Geo-Replication，跨集群异步复制MirrorMaker 2.0，需额外部署
一致性强一致性，Quorum 写入ISR 机制，最终一致性
运维复杂度Broker 无状态，易扩展Broker 有状态，运维复杂
生态成熟度相对较新，生态正在发展成熟，社区生态丰富

简单判断：跨地域复制、多租户隔离、消息长周期保留 → Pulsar 合适。日志采集、实时计算、吞吐优先、社区生态成熟 → Kafka 合适。

核心架构：Broker、BookKeeper、ZooKeeper

Pulsar 的架构是计算存储分离：

  • Broker：无状态计算层，负责消息路由、协议适配、消费管理，不存储消息
  • BookKeeper：分布式日志存储层，负责消息持久化，支持多副本和 Quorum 写入
  • ZooKeeper：元数据存储，存储 Broker、Topic、Schema 等元信息
  • Producer/Consumer：生产者和消费者，通过 Broker 接入

核心设计思路：Broker 无状态易扩展，BookKeeper 存储层独立扩展，ZooKeeper 管理元数据。

Broker 无状态的好处：

  • Broker 故障后快速恢复，不涉及数据迁移
  • Broker 扩展只需启动新实例，自动注册到 ZooKeeper
  • Broker 不存储消息，不会因为 Broker 故障丢失数据

这与 Kafka 不同：Kafka 的 Broker 既做计算又做存储，Broker 故障后需要等待副本同步，恢复时间较长。

分层存储：热数据 SSD，冷数据 S3

Pulsar 的分层存储（Tiered Storage）是它最核心的能力之一：热数据在 SSD，冷数据下沉到 S3/HDFS，无限保留。

分层存储的工作方式

每个 Topic 的消息首先写入 BookKeeper（SSD），称为 Hot Storage。当数据老化或达到阈值后，自动下沉到冷存储（S3、HDFS、GCS），称为 Cold Storage。

  • Hot Storage（BookKeeper）：热数据，最近写入的消息，读写频繁
  • Cold Storage（S3/HDFS）：冷数据，历史消息，读少写少，成本更低

配置分层存储策略：

# 设置 Topic 的保留策略
pulsar-admin topics set-retention persistent://tenant/namespace/topic \
  --size 100G \
  --time 7d

# 设置分层存储策略（自动下沉到 S3）
pulsar-admin topics set-offload-policies persistent://tenant/namespace/topic \
  --size 10G \
  --time 1d

消费者读取历史消息时，Broker 自动从 S3 拉取数据，对消费者透明。

与 Kafka 的差异

Kafka 的消息保留基于时间或大小，超过阈值后清理，不支持分层存储。如果需要长周期保留（如 1 年），只能依赖磁盘容量，成本高。

Pulsar 的分层存储可以无限保留，冷数据下沉到 S3，成本可控。适合数据湖、历史数据分析、合规审计等场景。

适用场景：金融数据需要长期保留、数据分析需要历史数据、合规审计需要完整日志。

多租户：Tenant、Namespace、Topic 三级隔离

Pulsar 原生支持多租户，从架构层面隔离不同租户的资源、权限和配额。

多租户层级

层级说明
Tenant（租户）最高层级，代表一个租户（如不同部门、不同客户）
Namespace（命名空间）租户下的逻辑分组，隔离 Topic、策略和权限
Topic（主题）具体的消息主题，格式：persistent://tenant/namespace/topic

资源隔离

不同 Namespace 可以配置不同的策略：

  • 消息保留策略：保留时间、保留大小
  • 配额限制：消息速率、带宽限制
  • 权限控制：生产者/消费者权限、管理权限
  • 集群隔离：不同 Namespace 可以部署在不同 Broker 集群

配置示例：

# 创建租户
pulsar-admin tenants create tenant-A \
  --admin-roles admin-A \
  --allowed-clusters cluster-1

# 创建命名空间
pulsar-admin namespaces create tenant-A/namespace-1 \
  --retention-time 7d \
  --retention-size 100G \
  --message-ttl 1d

与 Kafka 的差异

Kafka 不原生支持多租户，需要自己实现隔离：不同业务线使用不同 Topic 前缀，通过权限控制隔离。但这种隔离不彻底，资源配额、消息保留策略需要自己实现。

Pulsar 的多租户是从架构层面设计，租户之间的资源、权限、配额完全隔离，适合 SaaS 平台、企业内部多业务线。

跨地域复制：Geo-Replication

Pulsar 原生支持跨地域复制（Geo-Replication），不同地域的集群之间异步复制消息。

跨地域复制的工作方式

  • 异步复制：Producer 写入本地集群，Broker 异步复制到远程集群
  • 双向复制：支持双向复制，两个地域都可以生产和消费
  • 消费者订阅：消费者订阅本地集群，自动消费本地和远程复制过来的消息

配置示例：

# 配置集群间复制
pulsar-admin ns-isolation-policy set cluster-1 \
  --namespaces tenant-A/namespace-1 \
  --primary cluster-1 \
  --secondary cluster-2

# 启用 Topic 跨地域复制
pulsar-admin topics create persistent://tenant-A/namespace-1/topic-1 \
  --clusters cluster-1,cluster-2

与 Kafka MirrorMaker 的差异

维度Pulsar Geo-ReplicationKafka MirrorMaker 2.0
原生支持原生支持，无需额外组件需部署 MirrorMaker 组件
复制粒度Topic 级别，可配置Topic 级别，需配置
双向复制支持支持
运维复杂度低，原生功能中，需维护 MirrorMaker

Pulsar 的跨地域复制是原生功能，不需要额外组件，配置简单。Kafka 的 MirrorMaker 2.0 需要单独部署和运维。

适用场景：跨国业务、多地域容灾、数据湖同步。

消息模型：独占、故障转移、共享

Pulsar 支持三种订阅模式，对应三种消息模型：

订阅模式说明适用场景
Exclusive（独占）只有一个消费者，消息按顺序消费顺序消息、全局有序
Failover（故障转移）主备消费者，主故障备接管高可用顺序消息
Shared（共享）多个消费者，消息轮询分发并发消费、吞吐优先

与 Kafka 的 Consumer Group 对比：

  • Kafka：Consumer Group 内每个 Partition 只被一个 Consumer 消费，类似 Exclusive
  • Pulsar Shared：消息轮询分发给多个 Consumer，类似 Kafka Consumer Group
  • Pulsar Failover：主备消费者，主故障备接管，Kafka 不原生支持

常见误区

误区真实情况
Pulsar 吞吐比 Kafka 高吞吐接近，Pulsar 延迟更低，但吞吐不是核心差异
Pulsar 完全替代 Kafka生态成熟度、社区规模不如 Kafka，选型要看场景
分层存储等于持久化分层存储是消息保留策略，持久化依赖 BookKeeper 副本
跨地域复制是同步的异步复制，存在复制延迟，不适合强一致性场景

项目判断

引入 Pulsar 时，先回答三个问题：

  1. 消息保留周期：是否需要长周期保留（如 1 年以上）？
  2. 多租户需求：是否需要租户级隔离（如 SaaS 平台）？
  3. 跨地域复制：是否需要跨地域容灾或数据同步？

如果需要长周期保留、多租户隔离、跨地域复制 → Pulsar 合适。如果日志采集、实时计算、吞吐优先、社区生态成熟 → Kafka 合适。

线上排查 Pulsar 问题：

  • 消息积压：pulsar-admin topics stats 查看消息积压量，检查消费者状态
  • Broker 故障：Broker 无状态，重启即可恢复，检查 ZooKeeper 元数据
  • 存储压力：检查 BookKeeper 磁盘使用率，分层存储策略是否生效
  • 跨地域复制延迟：检查网络带宽、复制任务状态