别再只把 Pulsar 当 Kafka 平替了：主题分层、持久化和跨地域复制，才是它的杀手锏

大家好，我是 Echo_Wish。
说句实在的，这几年一提 Pulsar，很多人第一反应就是一句话：

“哦，那个 比 Kafka 多一层 的消息队列。”

这话吧，对，也不对。
对的是：它确实多了点结构；
不对的是：这点“多出来的结构”，恰恰是 Pulsar 的灵魂。

今天我就想掰开揉碎，聊三个 Pulsar 真正拉开差距的能力：

• 主题分层（Tenant / Namespace / Topic）
• 持久化设计（BookKeeper + Segment）
• Geo-replication 的真实用例

不吹概念，不堆名词，咱就站在一线工程视角聊：
👉 这玩意到底解决了什么问题？

一、先说句大实话：Pulsar 的“层级多”，不是为了炫技

很多人第一次看 Pulsar 的 Topic 名字，直接懵：

persistent://tenant/namespace/topic

心里 OS 一定是：

“我就发个消息，你给我整这么多层？”

但你如果做过 多团队、多业务、多集群 的消息系统，你就会明白：
这不是多余，这是“工程感”。

1️⃣ 三层结构，各司其职

Pulsar 的主题分层，本质上是 治理边界的设计：

这意味着什么？

👉 权限、限流、TTL、存储策略，全都不需要写在 Topic 上。

举个例子：

bin/pulsar-admin namespaces set-retention \
  my-tenant/orders \
  --size 100G \
  --time 7d

一句命令，整个 orders 命名空间的 Topic 全生效。

这在 Kafka 里？
你要么靠约定，要么靠脚本，要么靠祈祷同事别手滑。

2️⃣ 我的真实感受

我第一次在生产上用 Namespace 时，最大的感受是：

“终于不用和 Topic 名字较劲了。”

Kafka 时代，我们会看到这种 Topic：

order_pay_v2_prod_vip_regionA

不是因为我们爱这么命名，
而是所有治理信息只能塞进名字里。

Pulsar 把这些“脏活累活”收走了，你只关心：

order-pay

这事儿，真香。

二、持久化设计：Pulsar 为啥敢把“计算”和“存储”拆开？

这是 Pulsar 最容易被低估的一点。

1️⃣ BookKeeper 不是“另一个 Kafka 日志”

Pulsar 的消息存储，交给了 Apache BookKeeper。
Broker 只负责三件事：

• 接消息
• 发消息
• 管理元数据

真正的数据，写进 Ledger（日志段）。

Producer → Broker → BookKeeper

这一步拆分，带来一个非常关键的能力：

Broker 可以随便扩缩，不影响历史数据

2️⃣ 为什么这在现实世界很重要？

想象一个场景：

• 双十一
• 流量突然暴涨 5 倍
• 消费慢了，堆积暴涨

在 Kafka 里，你大概率要：

• 扩 Broker
• 重平衡分区
• 祈祷 rebalance 不翻车

而 Pulsar 呢？

👉 加 Broker 就行，Ledger 还在 Bookie 上。

这就是为什么 Pulsar 更适合：

• 突发流量
• 消费不稳定
• 冷热数据并存

3️⃣ 一段简单的生产者代码

Producer<String> producer = client.newProducer(Schema.STRING)
    .topic("persistent://order/prod/pay")
    .enableBatching(true)
    .batchingMaxMessages(1000)
    .create();

producer.send("order-123 paid");

这里你根本感知不到 Ledger、Segment、Bookie，
但系统已经在后台为你做了分段、复制和持久化保障。

三、Geo-replication：这不是“跨机房同步”，是系统级能力

说到这块，我得先泼个冷水。

90% 的人，不需要 Geo-replication。

但剩下的 10%，一旦需要，就非它不可。

1️⃣ Pulsar 的跨地域复制是“内建”的

不是 MirrorMaker。
不是额外同步程序。
而是 Namespace 级别的能力。

bin/pulsar-admin namespaces set-clusters \
  my-tenant/global-orders \
  --clusters us-east,eu-west,ap-south

配置完，消息就自动在多个集群间复制。

2️⃣ 一个非常现实的用例

我见过一个跨境电商的架构：

• 国内：订单写入
• 欧洲：风控与合规消费
• 东南亚：库存与物流消费

如果你用 Kafka，大概率是：

• 本地 Kafka
• 同步到海外 Kafka
• 再处理网络、顺序、延迟、重试

而 Pulsar 的思路是：

消息在哪产生不重要，重要的是“它最终在哪可见”。

每个区域本地消费，延迟低；
网络断了，恢复后自动追。

3️⃣ 你甚至还能“反向复制”

有些人以为 Geo-replication 只能单向。
实际上你可以：

• 主写在 A
• 灾备写在 B
• 通过策略避免循环

这在 容灾、数据主权 场景里，非常值钱。

四、说点不那么“官方”的观点

作为一个在一线踩过坑的人，我想说三句心里话：

1️⃣ Pulsar 的学习成本，确实高一点

• 概念多
• 组件多
• 运维要求高

但它换来的，是 长期的可控性。

2️⃣ 别一上来就全功能拉满

你完全可以：

• 先用单集群
• 不开 Geo
• 像 Kafka 一样用

等你真正遇到治理、扩展、跨地域问题时，再把能力打开。

3️⃣ Pulsar 更像“平台”，不是“中间件”

Kafka 是一把锋利的刀；
Pulsar 更像一套 模块化工具箱。

适合复杂系统，不一定适合小而美。

五、最后总结一句

如果你只想要：

• 简单
• 稳定
• 单集群高吞吐

👉 Kafka 很好。

但如果你面对的是：

• 多业务、多团队
• 资源隔离
• 跨地域部署
• 长期演进的系统

👉 Pulsar 值得你认真对待一次。

别再只把它当“Kafka Plus”了，
它的真正价值，藏在这些你迟早会用到的设计里。