别再只把 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 的主题分层，本质上是 治理边界的设计：
| 层级 | 干嘛的 |
|---|---|
| Tenant | 租户，通常是公司 / BU / 业务线 |
| Namespace | 资源和策略的管理单元 |
| Topic | 真正承载消息 |
这意味着什么？
👉 权限、限流、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”了，
它的真正价值，藏在这些你迟早会用到的设计里。
