上月底我特意从外地赶去上海参加了COSCon‘25 x Pulsar Developer Day 2025一进会场就看到那块写着“Make MQ Great Again”的签名板说实话看到这句话我还是挺有感触的。消息队列MQ这个领域聊了十几年从Kafka到RabbitMQ再到RocketMQ大家一直在“能用”和“好用”之间来回折腾但真正让我觉得“MQ又变酷了”的时刻并不多见。这篇回顾我不会写成官方新闻稿我想以参会者的视角把当天听到的技术风向、看到的现场DEMO、自己动手踩过的坑以及那些你复现时一定会遇到的问题原原本本分享出来。如果你正在做消息中间件选型或者已经在用Apache Pulsar又或者只是想看一场开源开发者聚会到底是什么样这篇内容应该能给你一些参考。1. 为什么是“Make MQ Great Again”1.1 MQ现状老问题与新需求先聊聊这句话为什么能戳中很多人。过去十年消息队列的主流选择大致可以分成三类Kafka主打高吞吐和日志型场景但分区扩张和迁移一直让人头疼早期依赖ZooKeeper的那套运维复杂度很多团队都领教过RabbitMQ胜在功能丰富、路由灵活中小团队拿来当业务解耦非常好用但吞吐量到了一定规模之后瓶颈非常明显RocketMQ功能很全尤其事务消息做得很成熟但社区一直给人一种“小圈子”的感觉外部贡献者很难真正参与核心。而在实际业务里需求早就变了。以前大家只关心“消息别丢”和“消费别乱序”现在更常见的诉求是数据要留存很久可能要回放几周前的数据多个团队要共享同一个集群但又不能互相影响流处理和普通消息投递最好能在一套体系里打通。这些需求用传统MQ架构去硬拼不能说拼不出来但代价很高。Apache Pulsar之所以能在会场里收获那么多目光正是因为它把“存储”和“服务”拆开重新回答了上面这几个问题。1.2 COSCon’25 与 Pulsar Developer Day 的新玩法这次活动的特殊之处在于它把COSCon中国开源年会和Pulsar Developer Day放到了一起。COSCon本身就是国内开源社区覆盖面很广的大会观展人群不光是做基础软件的还有很多做应用开发、嵌入式硬件、数据平台的人。Pulsar Developer Day则更聚焦来的大多是社区维护者、各厂在Pulsar上做二次开发的工程师以及在生产环境里跑Pulsar的“受害者”和“获益者”。两个活动叠加的效果就是主会场讲趋势和社区治理专题分会场讲技术和案例展区则留给动手实验和硬件演示。我印象最深的不是PPT而是现场随时有人在黑板上画拓扑图讨论BookKeeper的写放大问题也有不少人蹲在IoT展台前看一块STM32开发板如何把传感器数据实时推到Pulsar里。这种“核心开发者、使用者、刚入门的新手”混在一起的氛围比单纯听演讲有价值得多。2. 主会场透出的技术风向从消息到流的一体化2.1 计算存储分离不再是一句PPT主会场的几个演讲反复提到同一个词stream-native。很多人第一次听会觉得这是营销话术但Pulsar确实把这条路径落到了实现层面。Broker节点不保存消息数据所有消息的持久化都交给BookKeeper集群而BookKeeper又按segment段来存储。段这个设计很妙它让消息可以像日志文件一样分段管理Broker可以随时无状态地扩缩容存储节点也能独立扩展。这带来的直接好处是Topic数量可以做得比传统MQ多得多。Kafka在遇到上千个Topic时分区管理和日志文件数量会变得非常重而Pulsar的Broker更多是在处理路由和订阅状态真正吃存储资源的BookKeeper可以水平拆分。现场有位老兄展示了一个压测截图单集群几十万个Topic消息写入延迟依然比较平稳。我不建议你把这个数字当成日常目标但是用它来理解“计算存储分离”的价值很直观。另外Pulsar把“消息”和“流”在底层统一了。同一个Topic里的数据消费者既能用普通队列的方式去拉取也能通过订阅模式做数据回放。现场演示了一个很实用的场景一个业务系统在夜里发生了一次数据异常工程师直接把当天下午的Topic回放了一遍在几分钟内把加工逻辑重新跑完不需要翻日志、不需要临时脚本。这种“把MQ当时间序列数据库用”的能力是传统队列产品很难给的。2.2 多租户与数据隔离企业用户最关键的一课主会场另一个让我觉得“确实该选Pulsar”的点是多租户模型。它用tenant租户/namespace命名空间/topic三层来组织数据。比如一个大公司里支付团队可以建一个payments租户风控团队建一个risk租户两个团队可以共用同一套Pulsar集群但彼此的Topic、权限、配额完全隔离。在传统MQ架构里做这种多团队隔离通常只能靠“加集群”解决。每个团队一套集群运维成本高资源利用率也不高如果混在一个集群里又很难防止一个业务把集群整垮。Pulsar的namespace级别可以设置用量上限、消息保留策略、读写速率限制等于把“一租户一集群”的隔离效果在一个物理集群内实现了。大会现场有一个大型互联网公司的分享说他们内部一千多个业务共用一套Pulsar集群靠的就是这套租户模型加精细权限控制。这里必须提醒一句多租户不是“白来的能力”它要求你在接入规范上立规矩。比如命名规则、谁有权限创建namespace、Topic的TTL该设多久都要提前定好否则用着用着就会变成“租户乱建、Topic爆炸”。2.3 可插拔协议让Kafka客户端直接接入Pulsar会场上技术密度最高的一段是关于Protocol Handler的讨论。Apache Pulsar为了降低迁移成本实现了一套协议插件机制其中最常见的是Kafka Protocol Handler。它可以让原来用Kafka客户端写的生产者和消费者几乎不改代码直接连到Pulsar集群。这对存量用户来说意义太大了意味着“换引擎但不换驾驶舱”。有听众现场提问既然兼容Kafka协议那为什么不直接继续用Kafka台上的开发者回答得很实在Pulsar看中的是后端存储和订阅模型协议兼容只是为了让你不需要重写一堆客户端。你完全可以先用Kafka API接入在后台把数据落到对象存储做长期留存或者把一个Topic同时分享给多个消费组做不同处理。真正要换的是思维方式和架构客户端代码反而是最不重要的部分。除了Kafka协议Pulsar还支持MQTT、AMQP、OpenWire等协议。现场IoT展台用的就是MQTT协议接入这一下子让MQ的边界从“服务器和服务器之间”扩展到了“嵌入式设备和云端平台之间”。3. 展区与动手实验有硬件的IoT也有纯软件的Message3.1 一个半小时跑通本地PulsarPulsar Developer Day设置了专门的动手实验区我跟着走了一遍单机部署流程说实话比我想象中简单。用docker拉起一个standalone容器就能开始体验docker run -d --name pulsar \ -p 6650:6650 \ -p 8080:8080 \ apachepulsar/pulsar:latest启动之后先用pulsar-admin创建一个租户和命名空间docker exec -it pulsar bin/pulsar-admin tenants create my-tenant docker exec -it pulsar bin/pulsar-admin namespaces create my-tenant/my-namespace这几条命令本身不复杂但现场有不少人卡在了内存上。Pulsar的standalone模式默认分配的内存比较大如果你的笔记本只有8G内存建议启动前调整一下配置文件里的Java堆参数或者加一行环境变量export PULSAR_MEM-Xms512m -Xmx512m -XX:MaxDirectMemorySize1g动手实验讲师的建议是单机只是跑通概念真正要理解Pulsar的架构还是得至少开一个Broker加一个BookKeeper节点。不过第一次接触的人先从standalone入手是最快的路径。3.2 Python客户端实现生产消费动手实验的第二个环节是写一个最简单的Python客户端。现场特意强调了一个问题Pulsar有Python客户端但它依赖C客户端库所以在Linux和macOS下安装方式略有区别。直接用pip装pip install pulsar-client然后写生产者和消费者。生产者这边很直接import pulsar client pulsar.Client(pulsar://localhost:6650) producer client.create_producer(my-tenant/my-namespace/my-topic) for i in range(10): producer.send((hello pulsar %d % i).encode(utf-8)) client.close()消费者端我试了Shared订阅模式这样如果以后开多个消费者实例消息会在它们之间分摊import pulsar client pulsar.Client(pulsar://localhost:6650) consumer client.subscribe( my-tenant/my-namespace/my-topic, subscription_namemy-sub, consumer_typepulsar.ConsumerType.Shared ) for _ in range(10): msg consumer.receive() print(msg.data().decode(utf-8)) consumer.acknowledge(msg) client.close()有学员问为什么同一段逻辑在不同订阅模式里表现不一样讲师画了一张图解释四种订阅类型——Exclusive是单消费者独占Shared是广播给多个消费者分摊Failover是主备切换Key_Shared则让同一个Key的消息固定落到同一个消费者。这个知识点很基础但很多Pulsar的新手会在用Shared模式时突然发现消息不再按顺序消费了其实不是系统出了问题而是你选的订阅模式决定了顺序性的上限。3.3 STM32环境监测系统接入Pulsar的全过程这次展区里最让我意外的是那个硬件DEMO。一块STM32开发板接了几个传感器DHT11测温湿度、BH1750测光照强度、MQ-2测可燃气体浓度然后用一块OLED屏实时显示数据。最开始我以为这只是个普通的嵌入式作品直到我看到它把数据通过MQTT协议发到了Pulsar的Topic里。它大概的链路是STM32通过串口连接一块ESP8266或ESP32模块模块上跑MQTT协议连接Pulsar的MQTT端口。Pulsar本身就支持MQTT协议处理所以不需要额外再搭一个MQTT Broker。传感器数据像“温度25.3湿度60%光照320气体100”这样按固定格式拼成一行JSON通过MQTT发布到一个名为“iot/sensor”的Topic。另一端一个Python脚本订阅这个Topic把数据解析后写入时序数据库。这个DEMO只是简单展示了链路但它背后代表的意义让我想多说两句。传统IoT方案里很多设备先连EMQX这类MQTT Broker然后再通过规则引擎把数据桥接到消息队列或流处理平台。等于链路是“设备-MQTT Broker-MQ”多一跳就多一层运维多一份故障风险。Pulsar直接支持MQTT协议以后整套链路变成“设备-Pulsar”消息直接进分布式存储既可以被后端业务消费也可以留存在对象存储里做数据重放或者训练模型。硬件展台负责人说了一句话我很认同“MQ对大厂来说是基础设施但对物联网来说它更应该像一个水管插上就能用。”Pulsar这次给我的感觉确实像一个标准接头接得东西越多价值越大。4. 选型讨论Pulsar、Kafka、RabbitMQ的真实边界4.1 圆桌上最常被问的问题大会下午有一场圆桌讨论主题就是“消息队列选型我们到底在选什么”。现场听众的提问水平很高几个问题反复出现几乎可以当成你选型时的自查清单如果我的团队只会Kafka值不值得为了Pulsar去重学一套运维单集群Topic数量超过一万Kafka顶不住Pulsar真能顶住吗我只有几个微服务需要异步解耦用Pulsar是不是杀鸡用牛刀Pulsar的BookKeeper节点挂了会不会影响正在读写的消息每个问题其实都没有标准答案但圆桌嘉宾给出的判断框架很实用不要先看Benchmark先看你的痛点到底是“吞吐不够”还是“运维太累”还是“生态受限”。吞吐不够Kafka和Pulsar都有办法运维太累Pulsar的计算存储分离能带来一些缓解但BookKeeper本身又引入了新的运维复杂度生态受限那Pulsar的可插拔协议就值得认真考虑。4.2 性能、成本与运维对比我把现场讨论的重点整理成一张表维度不一定完全严谨但能代表现阶段的一般情况维度Apache PulsarApache KafkaRabbitMQ吞吐能力高适合大流量日志、流数据极高性能优化空间成熟中等适合企业级消息路由持久化与回放分层存储数据可长时间留存并回放留存时间受磁盘成本限制回放能力有限主要消费即确认回放能力弱多租户隔离内置tenant/namespace模型依赖配额和ACL较粗需要靠vhost和插件扩展运维复杂度Broker无状态但BookKeeper需要重点运维依赖KRaft/ZooKeeper分区迁移较重部署简单集群扩展有瓶颈协议兼容Kafka、MQTT、AMQP等可插拔Kafka私有协议AMQP为主学习曲线较高概念多segment、cursor、managed ledger中高但资料多较低这张表不是说Pulsar全面胜出而是不同场景的契合度完全不同。如果你只需要简单可靠的业务消息RabbitMQ依然比Pulsar容易得多如果你的场景主要是高吞吐日志收集、且团队已经很熟悉Kafka那硬迁到Pulsar不会让你“自动变好”。4.3 我不建议无脑迁移我在圆桌上也提出过一个观点迁移MQ的成本不只是改代码还包括所有围绕它建设的内部工具、监控告警、故障排查经验。这些隐形成本往往比选型本身更值得重视。一位现场嘉宾给了一个非常务实的建议如果新项目、新团队且需要长期数据留存和多团队共享可以考虑直接用Pulsar如果是存量系统先不要全量迁移挑一个低风险的业务Topic比如日志汇流、指标采集用Pulsar的Kafka Protocol Handler接过去跑一阵子观察稳定性和运维手感再做决定。我自己很认同这个方案它既验证了架构又不至于把自己逼到“全有或全无”的墙角。5. 会后复现与避坑笔记5.1 本地部署最容易翻车的三个地方回到住处以后我自己又完整复现了一遍部署结果翻车的地方比现场实验多得多。第一个坑是内存不足。standalone模式默认堆内存加直接内存差不多动辄几个G小机器根本扛不住。后来我老老实实改了bin/pulsar里的PULSAR_MEM和环境变量才把服务稳定跑起来。第二个坑是端口占用。Pulsar默认使用8080做HTTP管理端口、6650做客户端端口。如果本机装了其他中间件很容易冲突。解决办法是启动时换端口但要注意客户端连接地址和pulsar-admin用的地址都得同步改否则会出现“服务已经启动但怎么都连不上”的假象。第三个坑是元数据初始化。用二进制包部署时dcos或者本地文件系统模式都需要先执行initialize-cluster-metadata很多人忘了这一步然后BookKeeper一直报错。如果用的是官方Docker镜像这一步被自动处理了所以现场体验很顺换成手动部署时问题才会暴露。我建议刚开始学的时候先别跳进手动部署先用Docker跑通逻辑再回头补架构细节。5.2 生产环境配置的一些思考复现完之后我翻了一遍生产环境相关的配置手册结合大会上听来的经验有几个点特别值得注意。首先是BookKeeper节点数。生产环境建议至少3个节点且要满足半数可用原则。比如5个节点可以容忍2个节点故障3个节点只能容忍1个。这个数学模型跟很多分布式系统一样节点数不是越多越好而是要按容灾需求反推。其次是存储选型。BookKeeper的Journal盘写操作日志一定用SSD不一定要顶级NVMe但绝对不能和系统盘共用普通机械硬盘否则写入延迟会严重拖后腿。Ledger数据盘可以用相对便宜的存储因为Pulsar会把数据offload到S3或其他对象存储来降低长期保存成本。再有就是offload配置。对象存储的region、endpoint一定要配置准确尤其是使用各类兼容S3的私有存储时最容易出现“本地测试没问题换个网络环境就上传失败”。我见过不止一次因为endpoint写错导致offload任务堆积的案例。5.3 监控指标与告警规则大会主会场专门有人讲Pulsar的运维可观测性这块在国内资料相对少我觉得很值得记录。Pulsar的指标主要分Broker和BookKeeper两块简单说Broker关心消息速率和订阅积压BookKeeper关心磁盘和写延迟。至少要看这几个指标Broker侧的RateIn/RateOut用来判断生产消费流量是否均衡Subscription Backlog代表未被确认的消息数量它是线上“消息堆积”的直接信号BookKeeper Journal的写入延迟如果P95长时间超过10毫秒说明磁盘可能扛不住了还有StorageSize用于观察Topic占用的存储空间方便规划offload策略。告警规则不需要一开始就做得很全先把“Backlog持续增长”和“BookKeeper写延迟飙升”两条加上已经能覆盖大多数事故。我后来在Grafana里配了一个简单面板把Broker的吞吐曲线和Backlog曲线放到同一张图里排查问题时非常容易定位是生产端打太快还是消费端卡住了。6. 常见问题与排查技巧实录6.1 现场高频QA每次大会几乎都会有观众问一样的问题这次我特意把答案记了下来。问题一Pulsar和Kafka到底什么关系Pulsar不是Kafka的替代品它们都处理流式数据但架构不同。Kafka是分区日志模型Pulsar是段存储加计算存储分离。你用Kafka的一切经验在Pulsar里依然有用比如Topic、Partition、Consumer Group这些概念都能对应上但底层行为和运维方式不一样。问题二Pulsar能不能直接兼容Kafka客户端能。通过Kafka Protocol Handler可以让Kafka客户端直接连接Pulsar不用改代码。但需要注意Pulsar的订阅模型比Kafka的消费组更丰富这给迁移留了很大的弹性空间。问题三Topic数量太多会不会有性能问题在Pulsar里Topic本身很轻量多Topic不会像Kafka那样产生一堆日志文件。但每个Topic的订阅、游标和相应内存开销依然存在所以也不是说可以无限创建要配合租户和Namespace的使用规范来控制。问题四数据能保存多久Pulsar允许按namespace设置消息保留时间从几小时到几年都行配合分层存储offload到对象存储在成本上比Kafka长期保留数据更划算。问题五中文资料多不多这几年Pulsar的中文社区活跃度明显上来了各种落地案例和源码解析都能搜到。相比前几年学习条件已经好太多。6.2 踩坑实录客户端版本、Backlog、认证我自己的踩坑集中在三个方面。一个是客户端版本和Broker版本不匹配。之前遇到过Pulsar客户端升级后突然报“IncompatibleSchemaException”后来发现是Broker还停在旧版本两边版本跨度太大协议字段对不上。所以在测试环境升级时最好带上小版本一起升。第二个是Backlog只涨不消。排查后发现是因为消费者程序在启动时订阅了Topic但是处理完消息之后忘记acknowledge。Pulsar的游标会一直停在最早未确认的位置导致积压持续增加。这在用Python客户端时特别容易发生因为如果处理函数抛异常有的写法会直接把消息重新requeue看起来消息在被消费实际堆在那里。第三个是认证配置错误。Pulsar支持Token认证、TLS等本地测试时经常有人配了enableAuthenticationtrue但客户端侧没带Token然后报401。排查的方法是先用pulsar-admin加--auth-plugin和--auth-params参数从服务端验证再逐步拉客户端进来不要一上来就怀疑网络问题。6.3 排查速查表我把这次从现场听来的和自己踩过的坑整理成了一张速查表放在这里方便大家直接参考现象可能原因排查手段客户端连接失败端口错误、认证缺失、版本不兼容检查连接URL看服务端日志用pulsar-admin做连通性测试消息积压不消费消费者未acknowledge、消费组暂停、消费能力不足查看订阅Backlog指标检查消费者日志观察RateOut写入延迟突然升高BookKeeper磁盘性能下降、网络抖动检查Journal写延迟测磁盘IO看网络带宽消费顺序异常使用了Shared模式、Key_Shared路由未指定Key确认订阅类型必要时改用Key_Shared且消息带KeyTopic创建不成功Namespace不存在、权限不足先用pulsar-admin get-namespaces验证权限重启后数据丢失持久化策略配置为无持久或单机模式磁盘损坏检查Topic持久化参数确认BookKeeper数据盘状态这张表不是什么万能攻略只是高频问题的一个提醒。真正出问题时第一件事永远是看日志Pulsar的Broker日志、BookKeeper日志、客户端日志三层对照着看大多数问题都能定位到具体层。7. 写在最后Make MQ Great Again 不只是口号会后我在回程路上想了一路为什么“Make MQ Great Again”会被贴在门口。那条横幅底下其实还写了一行小字“来自社区为了社区”。Pulsar这个项目从最初的少数人布道到如今能在中国开源年会上组织独立的Developer Day背后是整个社区一起在推。我个人的体会是MQ这个领域正在从“一个存消息的工具”变成“整个数据流动的基础管道”。Pulsar提出的计算存储分离、分层存储、可插拔协议都不是贴在PPT上的概念而是可以落地解决具体问题的设计。我回来之后的最直接行动是说服团队把一条边缘业务日志链路从自研消息组件迁到了Pulsar规模不大但已经能感受到它在多租户和留存回放上的好处。最后再分享一个小技巧无论你最后选哪个MQ都建议在测试环境把“节点宕机”和“磁盘写满”两个故障演练做一遍。很多MQ的架构优势只有在你亲手模拟故障时才能真正理解。Make MQ Great Again不是某一家公司的目标而是所有被消息队列折腾过的工程师共同的心愿。希望这次分享能让你少走点弯路也期待下次大会能在现场见到你。