Pulsar开发者日：聚焦消息中间件生产环境实践

1. 开发者日的议程公布，先看这三点

1.1 它和主会场的定位差在哪

COSCon 2025 的同场活动名单里，Pulsar Developer Day 属于那种“懂行的人一看到名字就知道要干吗”的场次。很多人会问，开源大会本身已经有很多演讲了，为什么还要在同期专门办一个开发者日？实际上这两类场合解决的完全不是同一个问题，主会场更偏向覆盖生态全景，议题分散，你能听到操作系统、数据库、AI Infra、前端工程化各种方向，每场大概只能给你一个面上的认知，很难深入到一个中间件内部去啃设计和踩坑细节。

而 Developer Day 这类活动，是把圈子真正缩到“正在使用或者正在评估 Apache Pulsar 的人”这个粒度，一整天的内容都围绕消息中间件展开。台上讲的往往不是愿景，而是某个团队在生产环境压测出来的数据、某个线上故障怎么靠消息机制兜底、某个跨地域场景为什么选了 Pulsar 而不是自研。议程正式发布对你这种关注消息中间件的人来说，其实是一个信号：可以去现场对答案了。平时你在群里和人讨论 Pulsar 的存储分层设计、消费模型差异，很难约到一群同样在一线写代码的人坐下来聊一整天，开发者日恰好把这些人聚在了一起。

另外 COSCon 本身有非常强的开源社区文化氛围，Pulsar Developer Day 作为同场活动，既借了主会的人流和传播势能，又保留了自己技术专题的完整度。整个议程虽然还没有完全揭晓，但从“聚焦消息中间件创新实践”这个定位就能判断，这不是产品发布会，也不是纯布道场，而是以开发者实践为主轴的技术交流区。对参会者来说，看主会可以扩充视野，参加这场同场活动才是解决具体问题的最佳路径。

1.2 议程表透露的“认真程度”

议程发布这件事，衡量一个技术活动真实含金量的指标其实特别简单：看它敢不敢把“生产环境”“踩坑”“性能调优”这些词放在题目里。一个全是“Pulsar 介绍”“消息中间件概览”这种标题的日程，基本可以断定是新手场，适合入门但不太适合老手。而这次标题直接点出“创新实践”，意味着大部分议题会来自真实业务场景的复盘，不是拿着官方文档念概念。

我的经验是，一份好的议程公布后，你第一件事不是看有哪些知名讲师，而是按主题给场次归类。比如存储、消费、运维、生态集成，如果某个方向被安排了两场以上，说明那是社区当前最痛、最热的焦点。从 Pulsar 社区近一年的发展节奏看，比较可能出现的重点会集中在存算分离架构落地、跨地域复制、流量峰值应对、Kafka 兼容迁移这类方向，这些都是企业引入消息中间件时最容易卡住的环节。能够提前从议程的标题结构上嗅出这种趋势，你在现场听的时候就不会只是被动接收，而是带着自己的场景去对照演讲者的方案。

2. 把 Pulsar 放上台面的原因：消息中间件正在被重构

2.1 为什么消息引擎突然重要了

过去做业务开发，大家提到消息中间件想到的第一件事是解耦和削峰，能往 RabbitMQ 塞就塞，能往 Kafka 丢就丢，很少有人会深想消息引擎本身的架构天花板。这几年情况变了。数据量涨上来以后，系统的瓶颈往往不出在业务代码，而出在消息链路：订单事件要进数仓、日志要进湖、实时特征要进推荐、CDC 变更要同步到多套存储，一条消息从产生到被消费，可能要跨越五六个团队、七八套系统。消息中间件从“辅助组件”变成了整个数据流的主动脉，这时候它的可靠性、扩展性、多租户隔离能力，就变得和数据库一样重要。

Pulsar 被反复拿出来讨论，不只是因为它名字里的 Apache 前缀。它和传统消息引擎最本质的差别是把存储和计算分离了：Broker 只负责处理请求、管理游标、执行路由策略，真正的数据落在 BookKeeper 里。这句话听起来像架构师在玩概念，但它带来的实际变化非常具体。你可以单独扩容 Broker 来应对突发流量，也可以单独扩容存储节点来应对数据增长，两者互不拖累。对比传统方案里存储和计算耦合在一起的设计，这种分层让消息中间件第一次有了“云原生基础设施”的样子。

这次大会把 Pulsar 单独做成一个开发者日，某种程度上也代表开源生态里消息中间件的竞争已经不再是单纯的功能对比，而是架构理念和工程实践的对决。你在现场听到的可能不是一个“谁比谁好”的结论，而是一群人在认真分享“我为什么这样设计”“我踩过什么坑之后才理解这个设计”。这种事情，光看文档是学不来的。

2.2 会议谈论“创新实践”时到底在谈什么

创新实践这个词很容易被说空，落到 Pulsar 生态里其实是几个非常具体的工程方向。第一是分区与消费模型怎么匹配业务，Pulsar 的订阅模式灵活度很高，独占订阅、共享订阅、故障转移订阅、Key_Shared 订阅各有适用场景，生产环境里怎么组合才能既保证顺序性又摊平消费压力，属于典型的实践问题。第二是分层存储怎么用，Pulsar 可以把旧数据卸载到对象存储，这样既能保留长时间窗口的 replay 能力，又不用无限堆 BookKeeper 磁盘，问题是分层阈值、读取性能、生命周期管理这些参数怎么定，才有最优性价比。第三是集群的容灾设计，跨地域复制怎么做、故障域怎么切、脑裂怎么防，几乎每个上规模的公司都会遇到。

还有一个经常被拿到开发者日来讲的话题是兼容迁移。很多团队并不是没有消息中间件，而是现有引擎在某些场景下不够用了，想迁到 Pulsar 又不愿意把业务代码全改一遍。Pulsar 的 KoP（Kafka-on-Pulsar）协议支持就是为了解决这个痛点出现的。你在现场可以听到别人真实的迁移路径、流量切换方案、回滚预案，比自己在办公室试错要快得多。也不要忘了安全这一维度，很多公司对消息链路的加密、认证、权限模型是有硬性要求的，Pulsar 在这块的机制，远不是“开个 TLS 就行”这么简单，如何跟公司既有的认证体系打通，也是设计实践里非常关键的一环。

3. 围绕“消息中间件创新实践”，我最关心这四类内容

3.1 消息不丢不重的工程实现，不能只靠中间件

做消息的都知道一句话：分布式系统里没有绝对的 exactly-once，只有 at-least-once 配合幂等消费。但每一次在真实场景里把这句话落地，都要褪一层皮。我看开发者日内容时，最关心的第一类议题就是关于消息可靠性的生产实践。生产者发送消息失败怎么办？重试机制怎么设？确认机制选什么？消费者拿到消息后业务处理成功但 ACK 失败导致重复消费，幂等怎么做？这些问题在不同团队里会有完全不同的答案，听别人怎么权衡非常有价值。

比如生产者重试，很多人只知道设置一个 retry 次数，却忽略了超时时间和重试间隔对消息顺序的影响。你把超时设短，网络抖动时可能消息根本没发出去就返回失败；设太长，客户端积压的请求会挤爆内存；重试间隔太短还可能导致集群在故障恢复瞬间被重试流量冲垮。这些参数选型的背后没有标准答案，只有基于真实负载的压测数据。再比如幂等，用数据库唯一键去重、用 Redis 记录消息 ID、还是用状态机做前置校验？每种方案有自己的性能和一致性取舍。这类议题只要演讲者真的上过生产环境，几乎每一页内容都能让你有“原来是这样”的启发。

消费端的可靠性也容易被低估。Pulsar 的消费者模型里，消息接收模式、确认超时、重试队列这几个参数的相互作用，决定了系统在消费者宕机或者业务逻辑异常时表现出的行为。我在实际项目里碰到过一种情况，消费者线程池里有几个任务卡死了，导致消息确认超时，Pulsar 把没确认的消息重新投递，结果下游重复处理的量突增，最后靠调整 maxRedeliverCount 和死信队列配置才兜住。这种链路靠“读文档”很难形成肌肉记忆，多听一线分享、多做故障演练才是正路。

3.2 消费积压排查，永远比想象中难

任何消息系统用得久了，都会遇到消费积压。消息堆积这件事本身不可怕，可怕的是你不知道为什么堆积。开发者日里关于性能调优的议题通常会把积压拆成几类：生产者写入慢导致 backlog 增长、Broker 分发瓶颈导致消费拉取滞后、消费者吞吐不够导致处理不过来、还有一个很隐蔽的分区倾斜问题。只有定位到具体环节，才能给出对症的解法，不然就是今天加机器明天又堵。

Pulsar 的数据模型里有一条逻辑链路：Topic 下可以有多个分区（Partition），每个分区在 Broker 里对应一个 managed ledger。如果你只用一个分区来承载高吞吐场景，那不管 Broker 有多少资源都白搭，分区数量才是横向扩展的基础。消费者端的 Subscription 又有多种模式，共享订阅里多个消费者轮流拉消息，如果消息处理时间长短差异巨大，就会碰到长尾效应：某个消费者运气差，接了一堆处理慢的消息，其他消费者都闲着。

这块有个我在实际运维中总结的排查顺序可以分享给你：先看消费速率和积压曲线，确认是突增还是持续递增；再登录 Broker 看分区的分发速率和消费者拉取请求，判断瓶颈在服务端还是客户端；最后检查消费者的处理链路有没有外部依赖变慢，比如数据库连接池满了或者下游 HTTP 接口超时。按照这个顺序一步步缩小范围，比上来就瞎猜要快很多。听开发者日的性能议题时，也会发现社区里其他团队的主意特别多，比如有人用批量接收配合 CPU 绑核解决了小消息吞吐上不去的问题，有人用动态调整消费者并发数来适配流量波峰，这些都是能带回去直接改代码的收获。

3.3 生产环境稳定性，光会用 API 远远不够

开发者日上，稳定性相关的分享往往是最受关注的，因为这部分内容是拿事故换来的，听一场就能帮你避开好几个坑。Pulsar 的部署架构里有几个容易出问题的点：BookKeeper 的 JVM 参数和磁盘 IO 配置、Broker 的线程模型、元数据存储 ZooKeeper（或 etcd）的性能、以及集群升级时的兼容性策略。任何一个环节没处理好，都会在流量高峰给你颜色看。

用 BookKeeper 举例，它的 Journal 写入是预写日志机制，每次写入都要刷盘。很多人图省事把 journal 和 ledger 数据放在同一块磁盘上，结果高吞吐时 IO 竞争导致写入延迟抖动，进而影响整个集群的尾延迟。其实 Pulsar 官方建议是 journal 用性能更好的 SSD 甚至 NVMe，数据和 journal 分开目录存放。这个细节没那么起眼，但就是我上面说的，只有经历过线上抖动的人才会在分享里认真提这种建议。再比如 Broker 的负载均衡，Pulsar 默认支持自动负载均衡，但如果你没有配置好卸载条件，频繁的 bundle 迁移本身就会造成短时间内客户端重连和消息延迟抖动。要不要开自动均衡、阈值设多少，这种决策高度依赖实际流量模型，听有经验的人讲一遍比自己在生产环境试错成本小得多。

升级这个话题同样值得关注。Pulsar 的版本迭代比较快，从旧版本跨越大版本升级时，如果没留意 Broker 和 BookKeeper 的兼容矩阵，很可能升级完某个节点就起不来了。社区的惯例是升级前先在 staging 环境完整跑一遍滚动升级流程，再针对目标版本逐个核对配置项废弃列表。现场听分享的好处是，演讲者会告诉你他们最后采用的升级顺序是先升 BookKeeper 还是先升 Broker，以及为什么，这些操作顺序背后的逻辑，通常文档里不会写得很细。

3.4 生态演进的方向：协议兼容、分层存储和流处理

Pulsar 能在开源消息中间件领域站住脚，除了核心架构，生态整合能力也功不可没。这次开发者日的议题里，我很期待听到三个生态相关的方向。第一个是协议兼容，也就是 KoP 的进展。Kafka 生态太庞大了，很多公司内部已经围绕 Kafka 客户端沉淀了大量代码，直接换引擎迁移成本高得吓人。KoP 的思路是在 Pulsar Broker 上实现 Kafka 协议，让存量 Kafka 客户端不改造就接入 Pulsar 集群，这给渐进式迁移提供了喘息空间。我自己在做技术选型时，如果面对一个用 Kafka 用了很久的团队，几乎都会建议他们先评估 KoP 兼容层覆盖了哪些版本、哪些特性还没实现，而不是一刀切地要求团队重写生产者和消费者。

第二个是分层存储与数据保留策略。Pulsar 的 Tiered Storage 把数据从 BookKeeper 卸载到 S3、GCS 这类对象存储，理论上可以让你保留无限长的消息历史。这里面的关键在于“无限保留”和“查询性能”怎么平衡。有人会把冷数据保留几个月甚至几年，用于事件回放和审计；有人则担心从对象存储读旧消息太慢。演讲里如果有团队给出具体的分层策略、读取性能数据，我会全程录下来研究。

第三个是 Pulsar Functions 和 Pulsar IO，也就是在消息管道内直接做轻量计算和连接外部系统。轻量级计算可以避免“每条消息都要经过一套独立微服务”的架构冗余；连接器生态则决定了消息中间件和数据库、数据湖之间的数据同步能不能开箱即用。在实践中，连接器版本和 Pulsar 版本不匹配是常见的坑；用了 Functions 之后没有设置好并行度导致消息积压的案例也不少。认真听这个方向的内容，能帮你在做技术选型时把“生态成熟度”这个问题回答得很扎实。

4. 带着问题去参会，比多带几盒名片有用得多

4.1 听会前先做一次“场景复盘”

开发者日和普通技术大会不太一样，它更像一个技术同行的对答案现场。如果你在会前不做任何准备，那现场听的时候很容易觉得什么都有道理，但回来后什么也落地不了。我的习惯是，在确定要参加这样的活动后，提前一周把自己当前负责的系统里跟消息中间件相关的场景列表拉出来，逐个环节标注当前的痛点，哪怕是很小的不舒服也写下来，带着问题去对号入座。

这个列表不需要很长，三五个问题就够了，但一定要具体。比如“我们现在共享订阅里消息倾斜严重，最大消费者和最小消费者的处理量差了 3 倍”就比“消费不均衡怎么办”好得多。再比如“我们在客户端设置了 100 的接收队列大小，但消费速度还是上不去，是不是和 prefetch 策略有关系”。这种带着现场细节的问题，哪怕在 Q&A 环节没机会问，你在茶歇时找讲师聊几句，对方也更容易给你一个能落地的思路。因为同样的问题描述越具体，对方越能帮你判断是配置问题、用法问题还是架构层面的限制。

4.2 现场听分享，要学会抓取“决策上下文”

参会最有价值的不只是听到方案本身，而是听到方案背后的决策过程。一个团队为什么选 Pulsar 而不是继续用 Kafka？他们当时面对的场景是每天几亿条消息的日志管道，还是交易系统里几百种事件的有序流转？他们当前团队规模和运维能力是什么样的？为什么最后选择了共享订阅加 Key_Shared 混用？这些上下文信息才是你评估“这个方案是否适用于自己的业务”的唯一依据。

所以听的时候我会在笔记本上分两栏记：一栏记演讲者给出的结论和架构图，另一栏专门记录他们的“限制条件”和“取舍理由”——比如“因为业务要求分区内严格有序，所以不能用共享订阅摊平消费压力”。回到公司以后，要照搬任何一个方案，我都要先对照一遍自己的场景和他们的场景差异。脱离了场景和规模的解决方案只是故事，不是工程。这也是我在这类开发者日上的核心心态：从来不去找“最佳实践”这种虚幻的东西，只去看真实的人在真实约束下做出的决策，然后把有价值的部分提炼出来融入自己的架构。

4.3 现场提问和社交，别高估自己的记忆力

技术活动的现场交流其实非常短，一个茶歇只有二三十分钟，围着讲师的人可能比展台前还多。我的做法是提前把核心问题压缩成 30 秒内能说完的版本，并且准备好一两句跟对方工作相关的铺垫，高效地让讲师在很短时间理解你想讨论什么。这时候笔记本和手机备忘录反而重要。人脑在嘈杂环境下记忆力特别不靠谱，聊完一个加微信再加另一个，三个小时之后就全混了。

同场开发者日的另外一层价值是认识生态里的“关键节点”人物。Pulsar 的提交者、BookKeeper 的维护者、周边工具的作者，这些人在平时你只能在 GitHub Issue 里看到名字，到了现场才可能坐下来聊几分钟。不用抱着“我要谈成什么合作”的心态，只要真诚地拿自己的技术场景去请教，通常会得到很多从 GitHub 讨论区里读不到的信息。回去以后我会花十分钟把当天遇到的人、聊到的要点、演讲的截图导出一份速记，方便未来需要时再联系。参加过几次这种活动后你会发现，这份速记的复用价值远高于会议现场拍的几十张 PPT 照片。

5. 议程官宣之后，怎么利用会前时间让门票价值翻倍

5.1 把“中文议题名”翻译成自己的“技术预习题”

Pulsar Developer Day 的很多议题从标题看并不复杂，但实际内涵往往需要一定背景知识才能完全吸收。会前这段时间最适合做的事，就是根据已公布的议题方向，把相关文档和源码先过一遍。比如如果议程里大概率会有“Pulsar/BookKeeper 存储架构的演进与挑战”这类方向，我会提前去把 managed ledger、Bookie 写入路径、flush 机制这些概念复习一遍，不至于现场听到术语时还要在脑子里搜索。

这种预习不需要很深，但最好能和自己的实际运维经验挂钩。消息中间件涉及的概念链路很长，一条消息从 Producer 发出到 Broker 接收、写入 BookKeeper、确认返回、更新游标、等待 Consumer 拉取，每一步都有一堆配置项和调优参数。提前把所有组件的版本号、API 路径、常用的 admin 命令整理进自己的知识库，现场听到任何案例时都能快速映射到对应的组件和配置上。这个动作会让人在分享结束后的提问环节明显更有底气，因为你问的不是“这个怎么实现”，而是“当时为什么在这个配置下选择这种实现路径”。

5.2 帮团队整理一份“回来后要讨论的问题清单”

一个人出差的收获如果只停留在自己脑子里，价值基本就损失了一半。如果你是以技术负责人的身份代表团队去参加这次 COSCon 同场的 Pulsar Developer Day，会前有必要顺手建立一份“团队引入/优化消息中间件关注点清单”。这份清单不需要很正式，但应该把当前团队在消息相关技术上想做但还没做的事列出来，比如是否要建设消息治理规范、有没有计划把消息轨迹和全链路追踪打通、现有集群的容量水位是否需要重新评估。

带着这份清单去现场，你会发现凡是跟清单相关的议题，你都比别人听得更专注，记录也更细致。回来之后你再把会议笔记整理好同步给团队，一起对照清单讨论哪些经验可以直接借用、哪些结论还需要压测验证。这么做的好处是：一次会议的产出，从“一个人的学习”变成了“整个团队的技术输入”。毕竟门票和差旅都是成本，得让价值在团队层面流动起来才算回本。

5.3 别只盯 Pulsar，还要留意消息中间件领域的横向对比

Pulsar Developer Day 的舞台虽然属于 Pulsar，但整个消息中间件赛道正在出现一些有意思的共性趋势。多协议兼容、分层存储、云原生部署、Serverless 化，这几件事不是 Pulsar 单独在做的，其他消息系统也在往同一个方向走。只是每个项目的实现路径不同，取舍也完全不同。带着横向对比的视角去听，收获往往会更多。

一个具体的例子是消息中间件的“存算分离”。RocketMQ 5.0 在强调分层存储，Kafka 也在通过 KRaft 和 Tiered Storage 逐步演进，Pulsar 从诞生起就走这条路。如果你能听清楚各自的设计取舍，回头做选型报告时你就能非常清晰地告诉团队：每个方案在运维复杂度、成本模型、数据一致性上的差异是什么。再比如消费模型，RocketMQ 的消费组与 Pulsar 的 Subscription 很相似，但在实现细节上有分别，哪些层面兼容哪些层面有坑，只有对比过才会敏感。如果你恰好需要给团队做一次内部技术分享，去参加完这类开发者日之后，素材和案例通常都会丰富很多。

我个人体会比较深的一点是，消息中间件这个领域最缺的不是高性能，而是久经考验后的稳健，以及认知的统一。只有不断通过像 Pulsar Developer Day 这样聚焦的交流场合，把同行踩过的坑、拿数据验证过的结论沉淀成能被复用的经验，整个技术社区才能少走弯路。所以不妨在议程发布后尽早锁好票，把会前功课做足，再带着具体的问题走进会场，这样等散场时，你带走的绝对不止是几张 PPT 截图。