很多人这几年都在喊“MQ已死”Kafka统治一切Pulsar似乎只活在邮件列表和少数大厂的技术分享里。但这次COSCon‘25与Pulsar Developer Day 2025联合场——从现场的上座率、提问的数量到圆桌环节的激烈程度——几乎是在用事实回击这种论调“Make MQ Great Again”不是一句怀旧口号而是消息队列赛道正在发生的一次重新洗牌。这篇文章我想以自己的参会视角把这场活动里最值得琢磨的技术线索、现场讨论和高频问题整理出来给没到场的读者一份能真正参考的回顾而不是简单的日程流水账。如果你正在做技术选型、正在被Kafka集群的存储成本和管理复杂度折磨或者只是好奇为什么Pulsar在这个时间点突然密集出现在各类技术会议的主屏幕上这篇回顾应该能给你一些答案。1. 开场的一个细节议题方向比议程本身更有信息量1.1 “MQ复兴”不是噱头而是基础设施焦虑的投影大会开场前我在展台区转了一圈。跟去年纯聊Kafka生态的场面不太一样今年Pulsar的展位前堆积了相当多具体到让人有点意外的提问——有人问BookKeeper的IO隔离配置有人问协议兼容的迁移路径还有人拿着手机展示自家集群的Backlog积压曲线。这种“带着生产环境问题来现场找答案”的氛围本身就很能说明问题。主会场的第一个专题分享演讲人开头放了张PPT标题是“为什么我们应该重新思考消息队列”。里面有一组数据我印象很深过去三年里传统MQ和Kafka集群在二线互联网公司里的平均副本膨胀率超过了40%而真正被业务消费掉的消息往往不到存储总量的20%。消息队列已经从“流量管道”变成了“存储包袱”。这其实是Pulsar这个项目从诞生起就在回答的问题当消息保留、重放、批量回溯成为刚需时一个把存储和计算完全分离的架构是不是比“追加日志分区堆积”的老模式更适合现代数据链路现场大部分讨论绕来绕去最后都会落回这个原点。1.2 联合场次的组合逻辑COSCon的开源叙事和Pulsar的工程叙事这次活动把COSCon的议题和Pulsar Developer Day编在同一个会场我开始觉得只是蹭档期听完几个分享后反而觉得这个编排很聪明。COSCon的氛围偏“开源共同体建设”Pulsar的开发者日偏“生产系统落地”。前者讲生态讲如何让一个项目活下去并长出自己的供应链后者讲工程讲如何在金融、车联网、AI数据管道这些压力环境里不翻车。两条叙事线在现场形成了微妙的互补。比如上午的某场圆桌台上聊的是“开源项目的治理结构如何影响商业产品选择”台下观众把话筒接过去后直接问了一个Apache/BK版本的兼容性问题——这个转折本身恰恰就是MQ领域现状的缩影大家都在关心它能不能进生产环境而不仅仅是代码好不好看。2. Pulsar现场最打动人的三个演示从“能跑”到“为什么值得跑”2.1 分层存储演示把历史数据从三副本里解放出来技术演示环节第一个抓眼球的是分层存储Tiered Storage。现场Demo直接用AWS S3作为冷存储后端把一个超过500GB的分区从热存储里卸载到对象存储上然后立刻从客户端按时间范围做消息回溯。整个过程里Broker节点的内存曲线几乎没有波动。这个演示的冲击力在于它回答了一个长期痛点Kafka用户为了保住历史消息往往得忍受三副本的磁盘占用而在Pulsar的架构里历史数据本质上存在于BookKeeper之外的存储层副本策略和成本模型可以分层设计。也就是说“把消息留多久”不再等价于“买多大磁盘”。对做数据湖、做审计日志、做事件溯源的中大型系统来说这个能力直接改变成本结构。现场有人问了个很细的问题卸载到S3之后如果消费端要读冷数据时延会不会完全不可控演讲人的回答也很实在——冷读首次确实会有秒级延迟所以Pulsar的推荐策略是按数据新鲜度配置多层存储规则而不是把冷热一刀切。这种“工程上带权衡”的答法比单纯吹特性更能说服人。2.2 多租户隔离演示资源配额不是一次性配置而是持续自愈第二个demo做的是多租户场景。他们在同一个集群里同时跑了一个高吞吐的AI日志管道和一组业务核心交易消息然后人为把AI管道的流量打满到一个节点的极限。有意思的不是流量打满本身而是核心交易消息的延迟曲线几乎不动。这背后依赖的是Pulsar的“资源分组独立故障域”的隔离模型每个租户享有独立的存储和分发策略Broker的处理槽位按策略动态调配。相比“一个Kafka集群一个大Topic靠客户端限流来互相克制”的古老办法这种基础设施层的隔离明显更适合如今企业内部“一个集群支撑所有部门”的资源共享诉求。当然也有观众提到了反面经验隔离能力再强也挡不住存储节点本身的故障所以BookKeeper的Ensemble配置和修复策略才是隔离的前提。这个话题一出来问答环节几乎变成了BookKeeper运维专场这在两年前的技术会议上几乎是不可想象的。2.3 轻盈的客户端与Pulsar Functions把“消息”变成“微服务之间的胶水”另一个现场反响热烈的部分是Pulsar Functions。演讲人没有讲复杂API只展示了十行不到的Java函数把一条IoT消息里的温度字段做实时换算后转发到另一个Topic整个过程以less-than-5ms的额外时延在工作。有人可能会说这不就是一条Kafka Streams吗区别在于Pulsar Functions直接跑在Broker节点上不需要单独部署一套流处理集群。对于中小团队来说这意味着“消息增强、格式转换、简单路由”这类脏活可以直接塞进管道里而不是为每个小需求额外维护一个Flink任务。虽然它的能力边界明显做不了复杂状态流计算但作为“管道内的轻量逻辑注入”它确实让很多原本需要额外服务的场景变简单了。3. 存储架构深挖为什么算存分离重新定义了消息队列的脾气3.1 Broker无状态化换机器和扩节点不再是一场混乱Pulsar最核心的架构决策是把消息的读写服务Broker和数据的持久化BookKeeper拆开。这个决策在现场反复被提及因为它带来的第一个直接红利就是Broker层可以做到无状态。无状态意味着什么做运维的人最清楚——扩缩容不再涉及数据重平衡的漫长等待。你可以在流量高峰前直接横拉一批Broker节点几分钟内它们就能接管流量。在传统Kafka集群里分区迁移和ISR同步往往会让运维在深夜的企微群里用一串感叹号收尾而在Pulsar的架构下这只是负载均衡策略的一个普通动作。我前两年帮一个电商客户做过一次迁移他们当时最崩溃的就是大促前的扩容加了5台机器结果分区重平衡把整个集群的IO拖垮促销流量还没到集群先自己抖了半小时。换到Pulsar之后同一个场景下扩Broker和扩BookKeeper是两类独立操作哪一类先做、做多大完全取决于瓶颈在哪一层而不是两件事绑在一起互相打架。3.2 “马后炮式重放”的成本因为分层存储被彻底改写消息队列的老用户都有一种本能消息能不留就别留留着就是磁盘刺客。Kafka的保留期默认几天延长保留期意味着副本存储成本线性上涨。而Pulsar在架构上把“保留”和“计算”彻底分离存储层可以对接对象存储历史数据可以以极低成本躺在那儿。现场有位做证券行情系统的工程师问了一个很实际的问题如果要保留全量行情数据两年用于策略回溯Pulsar的存储成本能比原来低多少演讲人给了一个大致估算热数据放BookKeeper超过一周的数据转S3或同等对象存储在同等容灾前提比如远端复制一份下两年保留的综合成本大约只有全三副本方案的六分之一到四分之一。这个数字不算绝对精确但它展示的变化是结构性的在Pulsar的世界里“保留更多历史”不再是IT部门的成本噩梦反而成为数据团队愿意积极争取的能力。对于必须做事件审计、法律合规、业务风控回溯的行业来说这个变化比性能提升重要得多。3.3 Segment机制让“大分区”不再等于“不可管理”现场还有一个容易被忽略的细节是关于Segment分段的设计。Pulsar把每个Topic的数据切成相对较小的Segment像日志分段一样管理。这意味着一个巨型Topic并不会构成存储层的单点压力存储节点的读写均衡在Segment粒度上完成。这解释了一个我在生产环境里反复验证过的现象Kafka集群往往需要留意“大分区”的毛刺——某个分区流量畸高时它的所有副本都被绑在同一组节点上热点无法拆散而Pulsar不存在“分区是存储单元”这回事Segment可以被自由调度。对于车联网、物联网等高频小消息场景这种设计天然能打散热点避免一个人声嘶力竭而其他人闲坐看戏的尴尬局面。4. 圆桌“名场面”Kafka、RocketMQ、IBM MQ与Pulsar的正面碰撞4.1 选型争论最集中的三个问题下午圆桌是全场信息密度最高的环节。台上坐了来自互联网、金融、车联网背景的工程师台下的提问显然做过功课几乎没有一个“哪个最好”的泛泛之问全是具体场景下的取舍一个银行背景的听众问存算分离固然好但BookKeeper带来的额外运维组件是否会让团队规模不够的中小企业反受其累一个做直播弹幕的开发者问高扇出场景下Pulsar的消费模型和Kafka的消费者组模型在行为上有哪些微妙差异现场还有从IBM MQ热词里的STF MQ切换过来的用户问协议兼容和迁移平滑度的问题——他们关心的是能否把JMS存量客户端直接迁移到Pulsar暴露的接口上。这些问题之所以好是因为每一种都有明确的架构前提存算分离不是免费的需要额外付出BookKeeper的运维复杂度消费模型差异直接影响客户端代码的改造量协议兼容则决定迁移成本的量级。4.2 几个值得带走的“补刀”经验圆桌上有句话我印象特别深——某位做金融IT的老师傅说的“消息队列不存在最好只存在最不坏。你要选的是你能长期养的架构不是纸面上最强的架构。”他所在的团队最后不是因为Pulsar的存储成本低选择它而是因为他们算过一笔账自己的运维团队只有4个人Kafka集群和BookKeeper集群的运维压力差距不大反而是Pulsar的弹性扩缩容能力能减少大促期间的通宵加班。另外一个高频观点是关于协议兼容的Pulsar支持Kafka Protocol Handler也确实能接住不少存量客户端但如果你想省事直接迁而业务里使用了大量Kafka的“隐式行为依赖”比如消费者session超时的处理细节那么兼容层不等于免改造。不要用纸面兼容替代真实的压测验证。说白了选型没有银弹。MQ技术上各有胜负手真正决定成败的是你的团队能长期承担哪种复杂度、你所在行业对数据保留与回溯的要求是重是轻、以及你的流量模型是低频高吞吐还是高频小消息。5. 留给开发者的五条可落地笔记5.1 什么时候该认真考虑Pulsar综合这次大会的信息也叠加我自己这两年在生产环境的观察比较适合引入Pulsar的画像大致是这样消息保留和重放是刚需比如审计日志、金融流水、IoT事件流。内部已经有多个业务线或部门的场景需要清晰的多租户隔离。存在明显的流量波峰波谷扩缩容能力直接影响成本——比如大促、证券开盘、数据任务集中调度。集群规模已经大到让存储成本、分区管理成为主要痛点而不是能靠几台机器压过去的初创阶段。反过来如果你的业务就是简单的发布订阅、团队很小、数据保留只要求几天Kafka甚至云厂商的托管MQ可能都更务实。大会上的分享者也好、我自己的经验也好都不是让你无脑换Pulsar而是提醒你在MQ选型时把“历史数据保留成本”和“多团队资源共享能力”一并纳入账本再下结论。5.2 动手尝试前先把BookKeeper当成一个独立系统理解一个忍不住想重点强调的现场体会Pulsar的难点不在Topic/Producer/Consumer这套老朋友式的API上而在BookKeeper的Ensemble模型上。存储节点的分布策略、写入确认级别Write Quorum/Ack Quorum、修复流程这些决定了一个Pulsar集群在节点故障时的真实表现。这不是让你现在就啃完BookKeeper源码而是说做性能压测和故障演练时一定要把BookKeeper纳入测试范围。很多人第一次把Pulsar跑崩不是Broker出了问题而是对底层存储的故障域理解不到位。把故障演练覆盖到“杀掉一个Bookie”这个级别你才算真正开始了解自己的集群。5.3 现场反复被推荐的资料与社区路径活动现场有不少人在加微信交流但我也留意到几个更可持续的路径Pulsar官方文档里的Architecture Overview是公认的入门第一站邮件列表里关于LTS版本特性和协议兼容的讨论信息质量很高国内社区压缩包的活跃度也不错很多生产案例分享都值得翻看。多花点时间在官方社区和真实案例上比在二手文章里吸取“玄学经验”靠谱得多。5.4 一个小提醒直播弹幕这类超低延迟场景Pulsar不是最优解说到这一点是给上面那位做弹幕的同学的回答做一个延伸Pulsar出色的地方是吞吐、存储、隔离但它的Broker到Consumer的端到端延迟有架构上的底限不如为超低延迟而生的专业消息中间件。如果你的核心诉求是百万人在线、消息百毫秒内必须触达那你的问题本质不是消息队列而是实时分发网络。选型最怕的就是拿着一个项目的长板去另外一个项目的领域里比短板。5.5 参加完活动的第一周建议做这四件事活动结束后不用急着改架构。按这个顺序动手收益更高也最稳妥用官方Docker Compose拉起一个本地集群把分层存储接到一个云上的对象存储桶里试试卸载与回读先建立感性认识。压测目标设为“写入吞吐与磁盘/网络IO的关系”而不是简单跑一个Producer的TPS数字底层存储行为才是Pulsar性能的关键。试着把公司某个低风险Topic迁移到Pulsar的Kafka Protocol Handler上验证客户端兼容层到底要不要代码改动。做一次“失掉一个Bookie”的故障演练记录恢复时间和数据可用性变化用数据判断运维压力是否在可接受范围。这四步走完你会得到一个相对真实的判断Pulsar到底值不值得成为你系统里的长期底座而不是停留在“它的特性听起来不错”的层面上。6. 会后一个小时和两个社区老手的闲聊比某些分享还干货6.1 “MQ的未来不在MQ本身”活动尾声我把一位做Pulsar Committer的老哥和一位做数据平台的架构师拉在一起聊了一会。他们的看法高度一致这让我很受触动消息队列的未来正在从“传输组件”变成“数据基础设施的一部分”。当越来越多的系统把消息当作一等数据公民——可回溯、可重放、可流式加工、可批式分析——MQ的边界就开始模糊了它既是管道又是存储又是触发引擎。与其说“Make MQ Great Again”不如说整个数据处理范式正在把MQ重新拉回技术舞台的中央。而Pulsar在这个浪潮里可能是当下最贴合“消息即数据”这一理念的落地方案。6.2 给仍然犹豫的人的一句实在话不管你是刚听说Pulsar还是已经跑了一段时间又遇到坑这场大会给我的最大感受是这个项目的社区状态比两年前成熟太多了。文档质量、工具链生态、生产用户的分享密度都上了个台阶。踩坑依然不可避免但那已经是“属于你具体场景的坑”而不是“基础能力缺失的坑”。这两者的区别值得所有在做MQ选型的人细细品味。