Pulsar开发者日看点：存算分离消息中间件的落地与未来

COSCon’25的消息刚出来的时候，我的第一反应就是关注同场的 Pulsar Developer Day。如果你做过几年后端或者数据基建，一定体会过消息中间件选型的纠结：Kafka生态成熟但运维压力大，RabbitMQ好用但吞吐有上限，很多团队转了一圈最后还是回了头。Apache Pulsar 这几年能被反复提起，核心还是它“存算分离”的架构确实戳中了不少痛点。而这次的 Pulsar Developer Day 把主题定在“消息中间件创新实践”，议程一放出来，我身边几个做中间件运维的朋友已经开始对表约人了。

这场活动其实是个很典型的开发者日：不用听那种“PPT驱动”的泛泛而谈，而是聚焦在消息中间件的真实落地、架构设计、性能调优和工具的实操经验。无论你目前只用过Kafka，还是已经踩过Pulsar的坑，这个议程都值得仔细读一遍。这篇文章我会结合自己的参会经验和中间件选型实践，帮大家把这份议程拆开揉碎，聊一聊哪些内容背后藏着干货，同时也聊一聊Pulsar这门技术到底值不值得投入精力去学。

1. 这次Pulsar Developer Day到底带来了什么？——先聊聊活动背景和议程定位

1.1 从COSCon到Pulsar Developer Day：一场开源盛会的“传帮带”

COSCon（开源中国开源年会）在圈内的地位不用多说，它最大的特点不是单一项目的主场，而是把国内开源社区里最活跃的一批项目聚到一起。今年 Pulsar Developer Day 选择在 COSCon 期间同场举办，这个安排在开源圈很常见，但背后的信号值得品一下：Apache Pulsar 社区明显进入了“想和更多应用层开发者直接对话”的阶段。过去Pulsar的名气更多在基础设施圈层，很多开发者知道它但没真正上手；现在它需要在更广的开源人群里刷存在感，而开发者日就是最直接的方式。

所谓 Developer Day，通常不是主办方单方面讲完就散场，而是把开发者、维护者、使用者拉到同一个物理空间里，用议题、panel、动手实操和茶歇交流去填满一整天。对普通参会者来说，这比两天的大会主论坛更“解渴”。议程发布本身也意味着两件事：第一，活动已经可以正式报名，时间和场地都定了；第二，议题方向已经过一轮筛选，Pulsar 社区内部认为值得公开讲的创新实践和踩坑经验，才会被放进日程。

如果你是第一次参加这类开源同场活动，我建议不要把它当成“另一个技术大会”，而是当成一次“高密度信息交换”。同一时间段里可能有好几场分会场在讲不同主题，提前把议程摸清能让你少走很多弯路。后面我会专门讲怎么选场次，这里先记住一个原则：绝大多数 Developer Day 的内容密度，远高于普通的主旨演讲。

1.2 议程总览：不是“填鸭式演讲”，而是围绕真实场景的硬核拆解

从这次 Pulsar Developer Day 的主题“消息中间件创新实践”来看，议程大概会分成几条主线：一条是 Pulsar 核心架构深水区，比如 Broker 无状态化、BookKeeper 存储层调优、分层存储落地；另一条是行业应用案例，比如金融交易场景、车联网数据接入、智慧城市海量设备消息汇聚；还有一条比较关键的是“批流一体”和“多协议接入”，这两块目前是 Pulsar 社区里讨论热度最高的方向，也是很多团队从 Kafka 迁到 Pulsar 的主要理由。

我看过很多场同类议程，最有价值的往往不是那些宣传“我们用了Pulsar之后性能提升了几倍”的分享，而是能把“为什么慢”“为什么积压”“为什么消费位点丢失”讲清楚的那种。消息中间件的特点是：平时它能稳定运行到你忘记它的存在，一旦出问题就是整个数据链路的核心故障点。所以我在读这份议程时，重点看的是里面是否有故障复盘、参数调优、数据迁移、性能压测这类实操内容。这些内容恰恰是维护者在日常文档里写不了太细、但在线下交流时愿意展开讲的东西。

需要提醒的是，议程标题有时候会比实际内容更“大”。比如“Pulsar 超大集群运维实践”这种标题，可能只讲了某个特定规模下的业务挑战，不一定覆盖你的场景。所以你听的时候得带着自己的问题去，不能照单全收。这也是为什么我建议参会前先把自己的生产环境数据、压测结果、架构图都过一遍，带着问题去听，收获会翻倍。

2. 为什么是Pulsar？——消息中间件选型背后的核心逻辑

2.1 Pulsar的架构优势：存储计算分离到底解决了什么问题

聊消息中间件选型，我不太喜欢堆术语，因为大部分读者关心的不是“分层”这个概念本身，而是它到底能解决什么实际问题。Pulsar 最核心的架构特点是存储和计算分离：Broker 层负责生产消费连接、消息路由和缓存，实际的数据持久化则交给 Apache BookKeeper 这个底层存储集群去完成。这就把“无状态”和“强一致”两个看起来矛盾的特性，在架构上放到了一起。

你在生产环境最长遇到的扩容问题，在 Pulsar 上会变得简单不少。Kafka 的典型扩容姿势是迁移分区、观察副本同步、再扩大磁盘，整套流程走完通常以天为单位，而且稍不注意就可能出现分区不均衡。Pulsar 的 Broker 可以横向扩展，不需要把存量数据搬来搬去；存储容量则靠扩展 BookKeeper 节点解决，数据会自动均衡到新增节点。用一句大白话说：收银台只管接待顾客，货仓放在统一物流园区，忙的时候多开几个收银窗口就行，不需要把每个窗口背后的货仓也复制一遍。

除了存算分离，Pulsar 还有三个被提及频率很高的原生能力：多租户、分层存储、地域复制。多租户让多个团队共享一个集群却互不干扰，这在企业内部能省下大量重复的运维成本；分层存储可以把冷数据offload到S3或阿里云OSS这类对象存储上，保留无限回溯能力的同时不用无限堆盘；地域复制则是跨机房容灾的基础。这些能力都不是靠后期打补丁实现的，而是从设计之初就被内置进核心架构里，这也是 Pulsar 在云原生场景下越用越顺手的原因。

2.2 对比Kafka/RabbitMQ：什么场景下我敢直接选Pulsar

每次聊 Pulsar 一定会有人问“它和Kafka到底怎么选”。我的回答通常是：这取决于你的系统瓶颈在哪。Kafka 的吞吐能力已经被行业验证过无数次，它的模型是分区日志，消费者组按分区做负载均衡，这块设计在交易日志、风控事件、埋点数据等场景下确实很稳。但 Kafka 的Broker是有状态的，节点扩容时数据迁移和分区平衡都很考验运维能力；在跨地域容灾和多租户隔离这两个方向上，Pulsar 天然做得更顺手。

RabbitMQ 我会放到另一类来看。它擅长的是复杂路由、延迟队列、RPC 异步化这类业务集成场景，灵活度非常高，但吞吐量上限比 Pulsar 低几个数量级，而且消息堆积到一定数量后，性能下滑会比较明显。我更愿意把 RabbitMQ 看成“业务逻辑型中间件”，而把 Pulsar/Kafka 看成“数据管道型中间件”。

为了让你更直观地理解，我列了一个简单的选型对照表：

这个表格不是要制造“谁吊打谁”的结论，而是帮你把选型问题变成“我的痛点最能被哪一列解决”。如果业务是轻量级、强路由、团队规模小，RabbitMQ 完全够用；如果已经有成熟的Kafka运维体系，也没有跨地域和多租户强需求，那迁到Pulsar的ROI不一定高。但如果你正在搞一个多团队共享的数据中台，或者业务有明确的跨机房容灾需求，又或者想找一个支持多协议接入的“统一消息平台”，Pulsar 就是我敢拍板推荐的方向。

3. 议程亮点逐段拆解：创新实践到底在讲什么

3.1 主题演讲与技术深水区：从broker到协议层

从已经公开的议程方向来看，几个偏底层的分享是我个人最想听的。比如会讲 Pulsar Broker 在收到消息之后，是怎么走完“内存缓存、同步写入BookKeeper、确认应答”这一连串流程的。很多初级开发者以为发消息就是“send一下、broker存一下、consumer收一下”，实际上一锤子买卖背后涉及预写日志、刷盘策略、副本写入、读取缓存等多层配合。现场如果能听到维护者把某一处的源码逻辑展开，哪怕只讲一个类，都值回票价。

另外值得关注的是协议兼容层。Pulsar 原生支持多种协议，尤其是 Kafka 兼容协议是目前很多团队迁到 Pulsar 的敲门砖。听过实操分享的人都知道，兼容不是说“把端口换一下就好”，而是涉及分组协调、消费位点管理、事务语义等一系列差异。一个常见的“保命”问题就是：公司里的Flink任务通过Kafka协议连Pulsar，状态一致性有没有问题？生产环境事务怎么处理？消费者组的 rebalance 行为在兼容层下有什么不同？这些如果能在开发者日上得到一线维护者的明确回复，绝对比自己在Stack Overflow上查半天靠谱。

还有一类值得听的议题是“分层存储与数据生命周期管理”。很多团队把消息中间件当成临时通道，消费完就丢，忽略消息本身其实是带时间属性的数据资产。Pulsar 的分层存储可以把历史消息放到对象存储里，需要回溯时再拉回来计算；怎么设计分区、怎么管理 offload 任务、怎么控制对象存储成本，这些都属于“书本上不会写、但生产上天天遇到”的细节。总之，在技术深水区里，我更关注那些能让我回到工位立刻改一行业务代码或配置文件的细节。

3.2 应用案例与踩坑实录：别人掉过的坑一遍遍提醒你

我认为一场开发者日真正的精华，常常是“案例复盘”和“避坑实录”。消息中间件的坑有很强的共性，很多问题你在自己环境里排查很久，其实别人早就走过一遍。比如消息积压的经典处理：先检查消费者是否有空轮询、再查分区热点、还要看Broker端是否出现读延迟，这整套排查思路如果用文字写出来可能分成好几篇博客，但现场讲者由于时间限制，往往会直接给出一条完整的“故障时间线”，这种信息密度是所有在线文档都替代不了的。

具体到 Pulsar，我预判现场会有几个高频案例：第一，BookKeeper 节点故障导致写入延迟升高，最后怎么通过调整 Ensemble/WriteQuorum 参数解决的；第二，消费位号回跳和数据重复的问题，由于 ack 超时时间设置不合理，导致同一批消息被重复投递；第三，超大 Topic 的消息顺序性怎么保证，因为单个 Partition 的写入能力是有上限的，架构设计上往往需要从“消息路由键”设计开始规避热点。这些案例如果能结合真实监控截图、压测数据和关键参数来讲解，含金量会非常高。

应用案例还应该关注另一个角度：系统从一个中间件迁到另一个中间件的迁移过程。尤其是 Kafka 到 Pulsar 的迁移，常见做法有双跑、双写、灰度切换这些节奏；怎么保证迁移过程中消费位点不丢失、生产链路不中断，是很考验架构师设计能力的。如果讲者是来自实际承担过迁移的团队，那这部分的细节值得拿个小本子记。甚至你可以问一个问题：“如果迁移到一半发现某个Topic的流量是别的Topic的100倍，你们的切换策略会调整吗？”这种现场追问往往比讲稿本身更能暴露真实架构水平。

4. 开发者Day的“隐藏菜单”：动手实操和互动环节值得关注什么

4.1 动手实验环节：怎么在有限时间内把环境跑起来

很多开发者日在主议程之外都会安排动手实验，Pulsar Developer Day 这类活动尤其适合做 hands-on。原因是 Pulsar 本身可以单机模式运行，你不需要有一套完整集群就能体验核心功能。如果活动现场提供在线实验环境，那当然好；如果场地里网络拥挤或者你没有抢到实验名额，我的建议是提前在本地把环境跑通，到场后专注听思路而不是被环境卡住。

这里给你一套我一直在用的本地快速启动方法。前提是你装了 Docker，执行命令：

docker run -d --name pulsar \ -p 6650:6650 \ -p 8080:8080 \ apachepulsar/pulsar:latest

启动后可以用自带的管理工具创建租户和命名空间：

docker exec -it pulsar bin/pulsar-admin tenants create my-tenant docker exec -it pulsar bin/pulsar-admin namespaces create my-tenant/my-namespace docker exec -it pulsar bin/pulsar-admin topics create my-tenant/my-namespace/my-topic

生产者消费者验证时，直接用命令行自带的 produce 和 consume 子命令就行：

docker exec -it pulsar bin/pulsar-client produce my-tenant/my-namespace/my-topic --messages "hello, pulsar" docker exec -it pulsar bin/pulsar-client consume my-tenant/my-namespace/my-topic --subscription-name my-sub --num-messages 1

这套流程跑通以后，你自己看 Pulsar 的文档就会更容易。动手实验的意义不在于真正压测出多高的吞吐，而在于让你在脑海里形成“消息从哪里进、存在哪里、怎么被取走”的完整路径。如果开发者日现场有导师在旁答疑，那就更别浪费机会，遇到和本地环境不一致的情况直接问，比自己闷头调配置高效得多。

4.2 与核心维护者面对面：问什么问题才不亏门票

同场活动最大的隐藏福利，是你能在线下遇到 Apache Pulsar 项目的核心贡献者和维护者。平时在 GitHub issue 里沟通个两三回合才能说清的问题，线下五分钟可能就聊透了。但不要直接冲上去问“Pulsar和Kafka哪个更厉害”这种问题，浪费机会。好的提问方式，是带着具体业务场景和矛盾点去问。

我的建议是把问题分成三层：第一层是“配置参数背后的逻辑”，比如“ack超时到底该设多少，为什么我们系统里设了60秒还会大量重复消费”，这类问题往往能引出底层实现细节。第二层是“架构演进方向”，比如“社区下一个LTS版本的重点是什么？分层存储是否会支持更多后端？”这类问题适合聊趋势，也有助于你规划团队的技术路线。第三层是“生产故障兜底”，你可以问问对方：“如果你在线上遇到 BookKeeper 磁盘偶发故障，你的第一反应是要调哪些参数？”这种即兴的问题最能看出经验水平。

还有一个特别容易被忽略的细节：茶歇和休息时间。开发者日的精华往往不在演讲厅，而在茶水间。核心维护者和资深用户通常会被一群参会者围住聊技术，你不需要往前挤，搬个椅子坐在旁边听十分钟，可能就比听一整场主论坛收获大。如果你有社交包袱，那至少可以加一下对方的联系方式，后续在社区里提问也会更容易得到回应。

5. 消息中间件创新实践的启示：Pulsar生态下一步往哪走

5.1 从活动议程看Pulsar社区的趋势信号

从这次议程的侧重点，可以反推社区资源正在往哪些方向倾斜。我个人最明显的感受是：“多协议接入”和“批流一体”正在从卖点走向真正的生产级特性。早几年大家聊多协议，基本是“MQTT for IoT”或者“Kafka Protocol for 迁移”，但现在很多团队的诉求是让一套消息基础设施同时承载实时埋点、CDC事件、异步任务和边缘设备消息，这是Pulsar天然想占领的位置。

另一个趋势是“被集成”的含义在变化。Pulsar不再只是单纯的消息管道，而是慢慢形成以它为中心的数据生态。比如和 Flink 连接器、Spark Structured Streaming、数据湖的对接，都在往更深度整合的方向走。你可以想象一个场景：消息到达 Pulsar 后，一份流向实时计算，一份通过分层存储冷备到对象存储，还有一份触发数据湖的批处理作业。这种“一份数据、多路复用”的能力，正是消息中间件从“通道”变成“数据平台”的转变。

从社区角度看，Pulsar 还在强调“可运维性”。之前的版本已经在做自愈、负载均衡和资源配置的自动化，新版本大概率会把更多运维经验沉淀进系统。我判断未来一年，围绕多集群管理、自动化扩缩容、可观测性增强的内容会持续增加。如果你正在考虑团队技术投入，往这个方向积累经验，简历上的含金量也会明显提升。

5.2 对开发者个人成长的三个建议

第一，把消息中间件当成“数据系统”来学，不要只当“API工具”。比如你写一个 producer，除了知道 send 方法怎么用，还要知道这个请求从 producer 到 broker 再到 bookie 的过程中，有哪些环节可能丢数据、哪些环节引入延迟。懂这部分原理，你在遇到线上问题时的排查半径会大很多。

第二，多做“对比实验”，而不是只用一个中间件。给团队做技术选型时，我特别推荐用同一套压测脚本，分别跑 Kafka 和 Pulsar，记录端到端延迟、堆积场景下的吞吐、rebalance期间的消费停止时间。这些数据虽然不一定能推导出绝对结论，但它能逼着你站在架构层面理解两者的取舍。如果你没有生产环境，用 docker 起两个单机集群跑样例数据也行，重点是把“对比”的方法论建立起来。

第三，一定要参与开源社区，哪怕是给文档补一个注释。Pulsar 是一个很活跃的社区，Issue 和 PR 的响应速度都不错。你提一个优质 Issue 就可能和核心维护者产生讨论，这种讨论比你看十篇源码解析都有效。而且在开发者日的线下场合，你发现自己“在 Issue 上和某个维护者聊过”之后，再开口请教问题会自然很多。

6. 参会前必须准备好的几件事（以及我踩过的坑）

6.1 门票、时间与场地：别因为这些小问题影响体验

报名这种事看起来简单，但因为同场活动多，经常有人跑错分会场。我的习惯是先把 COSCon 主会的场地地图下载到手机里，标出 Pulsar Developer Day 的具体会议室，再往前推半小时把“从哪个门进、要不要换胸牌、午饭在哪解决”都确认一遍。这种活动通常人不少，中午排队吃饭可能会占用大量时间，你可以提前看看场馆附近有没有快速解决午饭的地方，或者准备好干粮，把午休时间留给技术交流。

还有一个我吃过亏的细节：现场网络往往不稳定。如果你要现场实操，别依赖在线环境，至少提前把自己电脑上的 Docker、Pulsar Client、Java 环境都装好。千万不要在演示前的最后一分钟才下载依赖，几千人挤在同一场馆抢带宽，你的编辑器很可能就转圈转不出结果了。电脑电量也很关键，我参加这类活动时一定会带一个至少支持30W输出的充电宝，不怕重，就怕没电。

如果是在线上参加，那就提前测试会议软件，准备好耳机和安静的角落。很多人以为线上参会轻松，实际上如果长时间戴着耳机听技术硬核分享，会比线下更容易疲劳，所以线上参会的日程更要精挑细选，别贪多。

6.2 现场提问与社交：怎么在开发者日获得最大收益

最后聊聊怎么提问。现场提问环节最容易出现两个极端：一类人全程沉默，一类人把Q&A时间变成“线上求助通道”。我比较推荐的提问方式是：先明确说出你的业务场景，再描述你做了什么排查，最后问“在Pulsar这类架构下，还有没有其他角度我没想到”。这么做显得你尊重讲者的时间，也更容易得到具体回答。比如你可以说：“我们有一个Topic的分区消息大小极不均匀，目前靠业务方增加路由键字段来缓解，我想知道除了增加分区数量之外，还有没有更好的设计方式？”这种问题讲者一听就知道你确实上过手。

社交方面，不要只加微信然后躺在通讯录里。你可以准备几个和自己项目相关的问题，在茶歇时和对方聊三五分钟，结束后立刻把关键信息记在手机备忘录里。很多人加了微信就变成了沉默的社交关系，其实真正有效的方式是后续通过开源社区 Issue 或邮件列表继续交流，让对方看到你在持续跟进。参加开发者日不是“完成任务”，而是在技术网络上建立真实的连接。

线下还有一个我常用的技巧：带一个小本子。虽然现场很多人用手机记录，但键盘声和手机碎片化信息很容易让你错过细节。我习惯在本子上画简单的时序图，比如“Producer -> Broker -> BookKeeper -> Consumer”，旁边标注现场提到的问题和参数，活动结束后再整理成电子笔记。这种动手写一遍的复盘过程，会让你的收获翻倍。如果你听了上一场动手环节，结束时顺手写一个“我今天学到的最有价值的一件事”总结，比朋友圈打卡有意义得多。

我个人在实际操作中的体会是：参加这种开发者日，最重要的不是把每场演讲都听完，而是在有限的时间里找到三五个真正触动了你的技术细节，并想清楚如何和自己的工作结合起来。议程只是入口，真实的价值，永远在线下人与人的交流里。