昨天朋友圈被 COSCon‘25 同场活动 Pulsar Developer Day 的倒计时海报刷屏了，还剩 3 天，好几个朋友私信问我说：“Pulsar 到底值不值得专门跑一趟？这个活动跟主会有什么不一样？”作为过去几年一直在消息中间件选型、运维和迁一线折腾的从业者，我觉得这是个聊几句的好时机。

先说结论：如果你所在团队正在做消息中间件选型，或者你已经用着 Kafka 但被分区扩容、存储成本、多租户隔离这些问题反复折磨，这场活动值得你花半天认真听。Pulsar Developer Day 是同场设在 COSCon‘25 里的独立开发者日，主题聚焦消息中间件创新实践，社区核心维护者、头部厂商的一线工程师、还有真正在生产环境跑了几百个节点的用户都会在场。这种密度在平时是很难凑齐的。

这篇文章我不打算给你报议程，而是站在“去之前应该做哪些功课”的角度，把 Pulsar 架构里最关键的几个技术点、生产环境常见的坑、以及参加这种开发者日怎么提问才有收获，一次性整理清楚。无论你是用手机随手刷到这篇文章，还是已经买好票准备到场，下面这些内容都能让你在活动开始时，比别人多一截认知储备。

1. Pulsar Developer Day 同场进 COSCon‘25，为什么值得专门留出时间

1.1 不要把它当成“附加场”，消息中间件正在成为基础设施层的主角

很多朋友对“同场活动”的印象是主办方为了填满档期凑出来的分会场，但 Pulsar Developer Day 的情况完全不同。它本质上是由 Apache Pulsar 社区主导的专业开发者日，只是借用 COSCon‘25 这个开源大会的场地和流量。所以你会看到：议程设置更聚焦，分享者大多是写代码、做运维、处理过真实故障的人；内容密度更高，不会出现那种讲半小时产品宣传片的场面；话题也更深，从消息路由策略到 BookKeeper 存储调优，都是可以直接带回去试的东西。

消息中间件这几年在技术栈里的位置变化，我感受特别明显。以前它是“业务系统之间传个通知”的工具，挂在 Redis 或者 MySQL 旁边就行。现在几乎所有中大型系统都在做异步化、削峰填谷、事件驱动架构，消息中间件变成了整个数据链路的大动脉，一旦抖动就是全站事故。正因如此，社区里关于架构演进、性能瓶颈、故障恢复的讨论变得特别有价值。这次 Pulsar Developer Day 就恰好卡在这个时间节点上。

1.2 从议程规律看活动主线：创新实践不只是新功能展示

虽然我还没拿到最终详细议程（倒计时海报上只透露了部分主题），但按 Pulsar 社区历次开发者日的惯例，内容基本围绕三条线走：

• 架构与设计：Pulsar 的分层存储、Broker 无状态化、跨地域复制等老话题每次都会升级，因为实现细节在变。
• 生产实践：重点通常是大规模部署、性能调优、迁移踩坑，比如从 Kafka 平滑迁移到 Pulsar，或者从自建集群转向云原生部署。
• 生态与路线：Pulsar Functions、IO Connectors、Pulsar 与 Flink/Spark 的集成，还有社区对未来版本的规划。

这里我特别建议关注“创新实践”四个字。“创新”不一定指 Pulsar 发明了什么黑科技，而是同样的旧问题，有人用新的方式解决了。比如怎么把消息流式处理下沉到 Pulsar Functions，省掉一套单独的 Flink 集群；比如怎么用分层存储把消息的保留时间从几天延长到几个月，成本还不涨。这些才是真正能抄作业的内容。如果这场活动里有生产环境规模超过千节点的团队分享，那就是本次最值得录屏的环节。

2. 想听懂 Pulsar 技术分享，先把这几个架构核心提前吃透

如果你不是 Pulsar 的深度用户，直接听现场演讲可能会被“BookKeeper”“Managed Ledger”“分段卸载”这些词绕晕。但底层逻辑其实并不复杂，我用大白话拆一遍。

2.1 计算与存储分离：Broker 和 BookKeeper 到底谁负责什么

Pulsar 最核心的设计理念是把“消息服务层”和“消息存储层”彻底分开。服务层是 Broker，负责接收生产者的消息、把消息路由给消费者、处理各种协议请求；存储层是 Apache BookKeeper，负责持久化消息数据，保证写进去就不丢。

你可以把 Broker 理解成餐厅的前台，负责接单、传菜、协调顾客；BookKeeper 是后厨，负责把每一道菜（每条消息）真实做出来、放稳。这种分离带来的直接好处是：前台不够用，可以快速加前台人数；后厨不够用，也可以单独扩展后厨，两者互不干扰。换成技术语言就是 Broker 是无状态节点，扩容时不需要迁移数据，BookKeeper 则以存储节点为核心，可以独立扩展存储容量。

这个设计为什么重要？因为它直接决定了 Pulsar 在扩容时不像 Kafka 那样需要做分区级别的数据重新平衡。Kafka 扩容节点时，分区副本要在节点间搬迁，期间会产生大量网络和磁盘 IO，稍有不慎就影响线上流量。Pulsar 这边，Broker 层扩容基本是“拉起新节点，接入负载均衡”的轻量操作；BookKeeper 层增加存储节点，也只是把新的 segments 写入到新节点，老数据不用大动干戈。现场聊到弹性扩容时，核心逻辑就在这里。

2.2 分段存储与分层卸载：消息中间件是怎么解决“数据越来越多”的

Pulsar 内部把消息按 topic 切成多个“段”（segment），每个段是一个存储在 BookKeeper 里的 ledger。写入时数据追加到当前段，段大小达到阈值或时间条件后，封存当前段并开启新段。这个机制天然支持顺序写，所以吞吐量很高。

更出彩的是分层存储。因为数据是分段管理的，老段可以整体“挪走”，转移到便宜的存储，比如 S3、GCS 或者兼容 S3 的对象存储。Pulsar 提供了 offload 机制，你可以设置一个阈值，超过阈值或时间的数据自动转移到对象存储，同时对外仍然表现为同一个 topic 的完整数据。消费者读老消息时，Broker 会透明地从对象存储拉回来。

这个功能在真实业务里能解决一个大问题：很多消息中间件的 topic 数据默认只能保留几天，因为全放在昂贵磁盘上成本太高。但有些场景（比如订单流水、审计日志、金融对账）需要保留几十天甚至更久。用分层存储后，热数据留在 BookKeeper，冷数据躺在对象存储里，成本可能差一个数量级。这次活动大概率会有人讲这个方向，提前理解 segment、ledger、offload 的关系，听的时候会顺畅很多。

2.3 多租户隔离与四种消费订阅模型：不是只有 topic

Pulsar 里有一个“租户（tenant）+ 命名空间（namespace）+ topic”的三级结构。租户可以类比成一个公司里的部门，拥有独立的认证、配额和存储策略；命名空间是更细的隔离单元，可以在不同命名空间配置不同的备份、保留策略。这种设计对多团队共享集群特别友好，你可以给业务 A 和业务 B 划分不同的命名空间，互不干扰，而不是单独给每个团队部署一套集群。这也是很多团队从自建 Kafka 迁移到 Pulsar 的初衷之一：省机器、省运维、还能隔离。

消费模型方面，Pulsar 提供了四种订阅：独占（Exclusive）、共享（Shared）、故障转移（Failover）和 Key_Shared。很多人第一次用时会困惑，觉得“不就是消费者组吗”。它的区别在于：

• 独占：一个 topic 只能有一个消费者，适合严格顺序消费。
• 故障转移：多个消费者中只有一个在消费，挂掉时自动切换，适合顺序性和高可用兼顾。
• 共享：消息被多个消费者分摊，吞吐最大化，但顺序性无法保证。
• Key_Shared：按消息 key 分桶，同一个 key 的消息固定发给同一个消费者，做到“同一业务键有序+多个消费者并行”。

我建议你把这四种模型画成一张表放在手边。现场听到“我们用 Key_Shared 解决乱序问题”这种分享时，你就能马上 get 到他的场景了。

3. 消息中间件创新实践的落点：从选型对比到生产环境避坑

技术分享再炫，最后都要落到生产环境“能不能用、怎么用好”。这块我多写一点，都是实际踩过或看到别人踩过的坑。

3.1 对比 Kafka：Pulsar 强在哪，又要付出什么

只要一聊 Pulsar，就绕不开 Kafka。我做了一张简单的对比表，可以在去活动前快速建立坐标系。

这张表不是让你得出“Pulsar 一定比 Kafka 牛”的结论。Kafka 生态成熟、文档多、排查问题的资料丰富，很多场景下它依然是合理的选择。Pulsar 的优势集中在需要长保留、多租户、弹性扩容、跨地域复制这类场景。如果你所在的团队还在用 Kafka，但每天都在为 topic 无限增长磁盘分区而头疼，那 Pulsar 值得你关注。

3.2 生产环境最常见的一批坑：顺序、确认、背压、还有磁盘

信息密度最高的分享通常来自“踩坑复盘”，我在生产环境里见得最多的有这么几类。

第一，消息顺序问题。很多人以为选了个顺序型订阅就完事了，但共享订阅下多个消费者并发处理，消息可能乱序；Key_Shared 也不是绝对的，如果生产端发送时 key 设计不合理，同一业务键还是可能落在多个分区。实践中要保证顺序，必须生产端按业务 key 发送，同时消费端选独占或故障转移，或者 Key_Shared 且只有一个消费者处理同一 key。

第二，消费确认与消息堆积。Pulsar 的 ack 机制是累计确认，消费者收到消息后，处理完再 ack。如果 ack 超时时间设置太短，消费者在处理一个耗时较长的任务时，Broker 会认为消息没被消费，重新投递，导致重复处理。把 ack 超时调长一点、做好消费幂等，是很基本的操作。但很多人上来就把 ackTimeout 设成几秒，线上任务一慢就全是重复消息，吓得赶紧回滚。

第三，背压。消费者处理不过来时，Pulsar 默认通过限制 receiver queue 的大小来实现背压。直接把 receiverQueueSize 调到很大，看起来很美好，内存压力全跑到客户端，Broker 端堆积也很快。更稳妥的做法是先在消费者侧配合理的队列长度和并发线程，再观察 backlog，再决定要不要调。

第四，BookKeeper 的磁盘布局。这是我见过翻车最多的地方。BK 的 journal（日志）和 ledger 数据不能共用同一块物理盘，否则大量随机读会严重拖慢顺序写性能。生产环境至少用两块 SSD，一块纯 journal，一块放 ledger；有条件再单独一块盘做索引。很多人图省事，单盘跑，结果吞吐量一上来，延迟直接飙到几百毫秒。

类似的坑还有很多，比如消息最大大小限制默认 5MB，大消息需要单独调配置；比如多个租户共享集群时，如果没有设置配额，一个业务方的海量消息可能把整个 BookKeeper 磁盘打满；比如 Pulsar 的元数据虽然用 ZooKeeper 管理，但你不用给每个 znode 单独调参数，反而要小心 ZooKeeper 集群自身的容量规划。

3.3 创新实践示例：用 Pulsar Functions 精简流处理链路

传统流处理链路通常是：消息进 Kafka，然后 Flink 或 Spark 做处理，再把结果写到下游。这套架构很成熟，但组件多、运维重。Pulsar Functions 的价值在于，把一些轻量级的流处理任务直接部署在 Pulsar 集群上，不需要额外一套计算引擎。它支持 Java、Python、Go，写起来也简单。比如下面这个 Python 函数，过滤并转写消息：

python复制from pulsar import Function

class TweetFunction(Function):
    def process(self, input, context):
        fields = input.split(",")
        if len(fields) >= 2 and fields[1] == "blocked":
            return fields[0] + ",filtered"
        return input

部署时直接用 pulsar-admin functions create --className TweetFunction --py tweet.py --inputs input-topic --output output-topic 就完了。是不是比搭一套 Flink 快多了。当然，Pulsar Functions 不适合跑重量级计算，但它能干掉大量“简单清洗、过滤、格式转换”类的应用，这就是创新实践落到日常的一种体现。活动里如果有 Functions 或 IO Connectors 的分享，值得坐前排，听完马上能试。

4. 去活动现场之前，我建议你先准备好这几个问题

参加开发者日和听网课最大的区别是“你能当场提问，还能和演讲者近距离聊”。但这需要提前准备，空手去很容易变成听完就走。

4.1 先用自己的业务场景去套，而不是泛泛地问“Pulsar 怎么样”

很多人提问喜欢问“Pulsar 比 Kafka 好吗？”这种问题，说实话没法回答。正确做法是把自己的具体场景讲清楚。比如你是“日订单量千万、要求最终一致、消息保留 30 天”，问“在这个规模下 Pulsar 和 Kafka 的存储成本差异有多大”就靠谱得多。

我习惯的做法是：动身前先花 20 分钟写下当前团队消息中间件最痛的三个问题。比如“broker 重启时消息堆积为什么恢复得很慢”“shared 订阅模式下消费位移重复提交”“分层存储触发后查询老消息延迟高”。带着问题去听，一旦哪个讲师讲到相关方向，茶歇时直接冲过去追问，这种收获比你听十场讲座都大。

4.2 一份可以直接用的提问清单

如果你一时想不出该问什么，可以参考下面这些问题，都是实际生产里经常遇到的：

• 你们生产环境的 BookKeeper 副本数是怎么定的？数据容灾和性能之间怎么平衡。
• 分层存储 offload 到对象存储时，对读路径延迟影响多大？有没有实测数据。
• 在 shared 订阅下，如果消费者做批量写入，Backlog 长时间不下降，通常有哪些调优思路？
• 一个 team 消费慢而另一个 team 消费快，多租户隔离是怎么防止慢消费者拖垮整体集群的？
• Pulsar 3.x 版本里对 Broker 升级有没有更好的滚动方案，升级期间消息是否完全不断档。
• 用 Pulsar 做跨地域复制时，两个地域之间的延迟对数据一致性的影响如何评估。

这些问题不指望每个都有完美答案，但你问出来，对方就知道你是有准备的人，愿意多聊几句。

4.3 现场安排的几个实用建议

第一，提前确定场次，别贪多。开发者日通常有多个 track 并行，提前根据标题选出 3-4 场最相关的，重点听。不要试图全程听完，因为信息量太大，大脑根本消化不了。第二，如果有 Workshop 环节，强烈建议带着电脑。现场跟着敲一遍本地搭建或配置案例，比看十页文档都有用。第三，多跟旁边的参会者交换联系方式。开发者日最大的价值往往在茶歇和午餐时间，你旁边坐的很可能就是某个大厂的中间件负责人。技术人习惯用问题破冰，你抛出一个真诚的技术困惑，很容易聊起来。

另外，如果你这几天才刚开始了解 Pulsar，也不用焦虑。活动倒计时 3 天，足够你做两件事：一是通过官方文档了解 Broker、BookKeeper 的基本概念；二是用 Docker 在本机快速拉一个 Pulsar 单机版，跑通“生产-消费-查看 backlog”的最小闭环。带着真实操作中的问题去现场，效果会完全不一样。

我在参加类似开发者日时最深的体会是：演讲内容会网上回放，但当面提问、交流、看别人怎么解决同类问题的机会是回放不出来的。所以别只想着“到时候去听一听”。把它当成一次给自己的技术问题做集中会诊的机会，把问题准备好，到场就赚到。哪怕你暂时没有迁移计划，了解消息中间件的演进方向，也会帮你下一次技术选型时少走弯路。三天后，会场见。