1. 活动背景与现场直击MQ的文艺复兴1.1 为什么Make MQ Great Again成为了口号看到这个标题的时候我愣了一下——Make MQ Great Again乍一看有点戏谑但仔细想想这恰恰是这几年消息队列圈子最真实的状态。MQ消息队列这个诞生了几十年的老家伙在云原生和AI浪潮里不但没被淘汰反而被Pulsar、Kafka、RocketMQ这些项目一次次重新激活。这次COSCon25和Pulsar Developer Day 2025放在一起办现场最大的感受就是MQ不是老了是正在经历一场文艺复兴。现场签到的时候瞄了一眼数据报名人数远超预期很多是冲着Pulsar的专场去的。这也不奇怪——Apache Pulsar这几年在技术圈的热度直线上升尤其是它那套存储计算分离的架构动摇了Kafka多年来的统治地位。会场内外的技术讨论、圆桌交流、甚至走廊上的小型争论几乎都绕不开一个话题MQ到底应该怎么演进才能跟上这个数据爆炸、AI遍地走的时代。1.2 大会日程结构与参会人群画像这一天的日程排得相当扎实。上午是COSCon主会场的几个主题演讲下午则是Pulsar Developer Day的专场安排了十几个分享。参会人群里我看到的至少有这几拨人一拨是不满足于Kafka、想看看新方案的架构师一拨是已经在生产环境跑Pulsar、来取经或者来吐槽的一线工程师还有一拨是做实时数据、AI基础设施的开发者。这让我挺感慨。上一次见到这么混合的人群还是在几年前的容器圈子里。MQ这个领域正在经历和Kubernetes当年类似的阶段——技术架构在变、使用方式在变、社区的版图也在变。而Pulsar恰好站在了这个变化的中心位置。注意本文内容基于大会现场的分享、圆桌讨论和个人实操经验整理。涉及具体的数据和性能参数会注明出处或标注为个人测试结果方便大家自己判断。2. MQ技术生态现状Kafka、RocketMQ与Pulsar的暗战2.1 Kafka的统治与裂缝要说消息队列生态Kafka绝对是一个绕不开的名字。它靠着高吞吐、分布式日志的设计几乎成为了消息队列的代名词。过去十年凡是搞大数据、搞实时流处理的默认选项基本就是Kafka。我在不少公司见过这样的场景业务团队根本不管什么消息顺序、重试策略直接先上Kafka再说。但Kafka并不是没有短板。最典型的问题有两个一是分区扩容Partition Scaling极其痛苦分区数定了之后想调整要么运维层面做数据迁移要么直接忍受rebalance带来的长时间不可用二是broker和存储强耦合每个broker屁股后面挂着一堆本地磁盘节点挂了之后分区leader的恢复速度、数据均衡的周期都很让人头疼。Kafka的架构是典型的Share-Nothing设计看起来简单但scale-out和scale-in都像是在做手术。这次大会的圆桌环节有人直接问了一个现场很多人心里都有的问题Kafka的KRaft模式都搞了这么久了为什么在生产环境还是很少有人敢把ZooKeeper去掉这其实说明了一件事——Kafka的架构变更牵一发动全身哪怕是官方在推的大改动社区和用户的迁移节奏也是非常缓慢的。这给Pulsar留下了巨大的空间。2.2 Pulsar的差异化打法存储计算分离Pulsar这套架构核心思路是和Kafka反着来的。Kafka是把数据放在broker的本地磁盘Pulsar则是把消息数据放进一个独立的存储层——Apache BookKeeper。Broker变成了一个真正的无状态接入层只管收发消息、维护订阅状态、执行策略。这个设计带来的直接好处就是想扩broker随时加加了之后立即分担流量本地不用做数据搬移想缩容直接撤掉也不用担心数据丢失——因为数据根本不在broker上。存储层扩容同理BookKeeper节点是独立的一组加节点就能提升存储容量和IO能力业务无感知。现场有个分享用了非常接地气的比喻Kafka像是一个人既要接客又要记账Pulsar则是前台只管接待财务和仓库是独立部门。这个类比做得很到位也让不少第一次接触Pulsar的人一下子get到了架构差异的本质。2.3 Pulsar的消息模型与订阅模式到底强在哪比架构差异更重要的是消息模型的差别。Kafka提供的消费模型本质上只有两种消费者组相当于独占或灾备订阅和广播相当于订阅中的一些模式。在复杂的业务场景里你会发现有些Kafka的玩法是硬凑出来的比如共享消费Kafka社区是长期不支持的因为offset管理在共享场景下非常复杂。Pulsar原生支持四种订阅模式独占Exclusive、共享Shared、灾备Failover和按键共享Key_Shared。这看起来只是API层面的差异实际上影响深远。举个例子如果你有一个任务队列的场景每条消息的处理时间不确定用Kafka你只能祈祷partition的key散列足够均匀否则就会出现某几个消费者空闲、某几个已经堆积到天荒地老的情况。而Pulsar的共享订阅让每条消息可以被消费者池里的任何一个实例拉取天然解决了负载不均的问题。我在生产环境里就用过Key_Shared模式处理过订单事件。同一个订单ID的消息必须被同一个消费者处理但不同订单之间要并行。这在Kafka里只能通过自定义分区策略去做而Pulsar直接在订阅模式层面就给你了。这类原生的能力差异是会直接影响业务代码复杂度的。3. Pulsar技术深潜架构原理与核心机制拆解3.1 分层架构的完整链路Broker、BookKeeper与ZooKeeper的协作要理解Pulsar脑子里必须有一张清晰的架构图。消息的路由和处理在Broker层完成消息的持久化落在BookKeeper的Bookie节点上元数据哪些topic在哪个broker、每个topic的游标等则由ZooKeeper后续版本用etcd管理。这一条链路里Broker是无状态的状态被拆到了另外两个组件上。无状态带来的是什么是水平伸缩的粒度变得极细。你的系统遇到流量洪峰理论上可以直接加broker节点十几分钟内就能完成扩容。这在Kafka的架构下是不可想象的。但是也要泼一盆冷水Broker无状态不等于整个系统简单。BookKeeper本身的IO模型、数据同步机制、故障恢复逻辑复杂度并不低。大会上有位分享嘉宾直言Pulsar把Kafka在broker层的很多复杂度转移到了存储层。这句话我深表认同。使用时你会感觉Broker侧逻辑清晰但一旦Bookie出了问题排查的思路就要切换成存储专家的思维这对团队的能力结构是有要求的。3.2 游标Cursor管理Pulsar最容易被低估的设计Kafka的offset管理是通过内部topic__consumer_offsets实现的消费者提交的offset本质上是发给一个特殊的topic。这种设计的优点是不用额外引入组件但缺点也不少——重平衡Rebalance的时候offset恢复有延迟且消费者和分区之间的关系变化会导致offset语义的混乱。Pulsar的做法完全不同。游标Cursor是Pulsar自己管理的一等公民每个订阅都对应一组游标游标的持久化依赖BookKeeper的Ledger。这意味着什么意味着消费者的消费进度和消息数据一样有了真正的持久化和高可用。我在生产环境实际遇到过一个场景某个消费者处理消息的速率突然下降积压了几千万条。在Kafka里想跳过这些积压消息你要么写脚本去改offset要么干脆丢弃重建topic。而在Pulsar里我直接重置了订阅的游标位置把这个订阅的回退时间设置到一个小时前一条命令就完成了。这种运维体验上的差距只有真正操作过的人才会懂。3.3 消息生命周期与保留策略不只是堆数据Pulsar另一个让我觉得设计得相当优雅的地方是消息保留策略。Kafka的日志保留逻辑是Segment级别的删除也是删整个Segment粒度相对粗糙。Pulsar则可以从几个维度精细控制按时间保留TTL、按消息数保留、按存储大小保留还可以设置“持久化但不可消费”的策略。举个具体的场景合规审计需要所有原始消息保存三年但业务消费者只需要处理一周之内的消息。如果你用的是Kafka要么让消费者一直挂在topic上做“假消费”通常会有问题要么就再复制一份存到对象存储里。而在Pulsar里你可以设定消费端的留存无关策略——消息不会被自动删除但游标可以往后跳消费者不会再拉到过期消息。这些都是真实的业务需求不是技术上的炫技。3.4 分层存储与无状态Broker的实际收益Pulsar的分层存储Tiered Storage是我个人非常喜欢的一个功能。它允许把很久以前的消息从BookKeeper自动转移到廉价的存储介质上比如AWS S3或者阿里云OSS同时对外还保持完全一致的消息访问语义。这意味着什么意味着你可以在同一个topic里既能读到几毫秒前刚产生的消息也能读到一个星期甚至一年前的历史消息——不需要额外走一遍大数据导出流程。有个金融行业的分享嘉宾讲了他们的案例合规需求要保留半年的所有交易流水但是热数据其实只需要存三天。用Pulsar的分层存储BookKeeper只需要支撑三天的事务型IO半年的冷数据挂在对象存储上存储成本估算下来比原来用Kafka加离线备份的方案节省了至少40%到50%。无状态Broker在生产环境最直接的价值是——机器的故障处置变得很轻松。我的团队曾经在高峰期遇到一台broker物理机硬件告警按传统思路这是要申请变更窗口的重活儿但在Pulsar里我们直接把这台机器的broker进程停掉流量自动转移到其它broker整个过程业务无感消费者集群没有任何重平衡风暴。这个体验用过就回不去了。4. 大会演讲精华回顾Pulsar在AI与大规模生产环境的实战4.1 AI时代MQ的新角色从管道到数据底座这次大会有一个明显的风向MQ正在从一个“传输管道”变成一个完整的数据底座。多个演讲嘉宾都提到了一个趋势——AI应用尤其是Agent类应用需要的不仅仅是消息路由还需要消息的历史回溯、事件驱动、多租户隔离甚至需要消息数据直接参与模型特征计算。有个做AI Infra的嘉宾提到他们用Pulsar的Key_Shared模式来给不同用户的AI Agent请求做隔离确保同一个用户的上下文不会被不同消费者并发处理。这在我听下来是一个相当巧妙的用法——AI对话的上下文连续性和消息队列的消费模式本质上是同一个需求。过去你可能要自己写一堆状态管理代码现在MQ原生能力就能解决。另一个做数据平台的同学分享了他们在Pulsar上跑批流一体任务的实践通过Pulsar Functions做轻量级的流式计算过滤、清洗、格式转换在消息进了topic之后就能完成不用再把数据投到一套独立的流处理系统。这让我觉得MQ在未来AI基础设施里的位置恐怕比很多人预想的要重要得多。4.2 大规模生产环境案例拆解千万级Topic的运维哲学下午场有几个分享是针对超大规模集群的其中一个案例让我印象很深他们管理着接近2000个broker、超千万个topic包括分区每天的Topic活跃度差异极大大量Topic可能一天只有几百条消息但又要保障秒级延迟。在这种规模下Kafka经常遇到的痛点是无辜的Rebalance。而Pulsar的无状态Broker在这个场景下优势彻底显露了broker挂了影响范围基本只有在该broker上建立的连接服务端没有复杂的分区迁移过程客户端会自动重连到其它broker。这个规模级的运维分享不是纸上谈兵他们的监控大屏上清晰地展示出了单台broker宕机后的客户端重连曲线——平滑、快速、无毛刺。同时他们也分享了踩坑经验聊聊BookKeeper的Journal和Disk的分离配置。如果所有数据都写在同一块磁盘上写延迟会急剧升高。通过把Journal写前日志放在高性能NVMe上把Ledger数据放在普通SSD上集群性能得到了数倍的提升。这个细节在官方文档里只是一句话但在真实运维场景里能直接影响集群的稳定性。4.3 多租户隔离在Pulsar中的落地实践多租户是Pulsar在架构层面就内置的能力和很多MQ通过起多个集群来隔离租户的笨办法完全不同。Pulsar有Namespace级别的隔离体系存储配额、消息速率、订阅数量都可以针对不同Namespace做精细化的策略配置。一个SaaS服务商的嘉宾分享了他们的做法他们的每个大客户独占一个Namespace设置独立的存储配额和流量限制小客户则共享一个大Namespace单独用Topic做逻辑隔离。通过这种方式他们不费吹灰之力就解决了吵闹邻居Noisy Neighbour的问题——某个客户流量突然暴增不会影响到同集群的其他客户。底层能力原生支持而不是靠上层业务逻辑去弥补这种优势在长期维护中感受最明显。4.4 Pulsar生态工具链从Kafka协议兼容到插件机制对于已经深度使用Kafka协议的业务Pulsar提供了一个几乎零成本的迁移路径——Kafka协议兼容层。这意味着你的Kafka客户端Java、Go、Python等可以不用改代码把bootstrap地址换成Pulsar集群的地址就能直接对接Pulsar。我们去掉了Kafka这个名字的束缚。大会现场有个真实的迁移案例让我印象深刻他们的Kafka业务平均迁移时间在一天以内剩下来的时间主要花在测试和回归上代码改动量微乎其微。另外一个作分享的嘉宾还提到了Pulsar在北向生态上的努力像Pulsar Functions、Pulsar IO以及和Flink、Spark等主流计算引擎的深度整合。5. 实操干货从零到一上手Pulsar的完整路径与踩坑记录5.1 单机部署与第一个消息的发送这里给还没接触过Pulsar的同学一个最快速的上手路径。生产环境肯定不推荐单机模式但本地开发、跑通概念验证是够了。官方提供的二进制包直接解压就能跑。# 下载最新的二进制发行包以当前稳定版本为例 wget https://archive.apache.org/dist/pulsar/pulsar-3.3.0/apache-pulsar-3.3.0-bin.tar.gz tar -xzf apache-pulsar-3.3.0-bin.tar.gz cd apache-pulsar-3.3.0/ # 启动单机模式会同时启动broker和依赖的BookKeeper、ZooKeeper bin/pulsar standalone # 再开一个终端用命令行生产一条消息 bin/pulsar-client produce my-topic --messages hello-pulsar # 消费消息 bin/pulsar-client consume my-topic --subscription-name my-sub --num-messages 1这里有一个很多人第一次用会困惑的点Pulsar standalone模式启动一个进程就把ZooKeeper、BookKeeper和Broker全都拉起来了看进程列表会看到一大串Java进程。实际上这是三个独立组件各自有启动脚本standalone帮你拼成了一个One-Box环境。你可以在本地调试这个丑但实用的方式快速验证逻辑。5.2 生产环境的正确部署姿势独立组件的划分本地跑通了之后生产环境部署需要认真对待组件拆分。我个人的建议是生产环境不要用standalone模式用systemd或者容器编排来分别部署ZooKeeper集群至少3节点、BookKeeper集群至少4节点保证宕机一台不影响写可用性、Broker集群按流量预估节点数建议起步三台。# 以二进制方式启动Bookie存储节点 bin/pulsar bookie # 以二进制方式启动Broker接入层 bin/pulsar broker这段配置里需要重点关心两个参数的设定# conf/bookkeeper.conf 中重点关注 journalDirectories/data/pulsar/bookkeeper/journal ledgerDirectories/data/pulsar/bookkeeper/ledgers # conf/broker.conf 中重点关注 managedLedgerDefaultMarkDeleteRateLimit1000 allowAutoTopicCreationtrue defaultNumberOfTopicPartitions1说几个生产环境的实测经验磁盘规划上Journal目录用NVMeLedger目录用普通SATA SSD这两种磁盘的IO特性完全不同不要混用。如果Jounral和Ledger混在同一块盘上会导致频繁的写放大和IO争抢写延迟会呈指数级恶化。managedLedgerDefaultMarkDeleteRateLimit这个参数是在控制游标删除速率。如果设置得太高在消费速度快的时候会导致Bookie上的Ledger被快速删除反而造成频繁的元数据操作影响集群性能。默认值可能不合你的场景需要根据实际消息吞吐量做压测调节。建议创建namespace之后立即设置存储配额和消息保留策略。这是很多人会忘记做的一步。默认策略是无限保留这在生产环境是灾难性的——线上事故后恢复的消息会把磁盘瞬间打满而且你根本没有一个自动清理机制去兜底。5.3 客户端使用中容易踩的坑Consumer与Producer配置客户端是踩坑重灾区社区里被问得最多的几个问题几乎都集中在Consumer配置上。首先是负确认Negative Acknowledgment和Re-delivery延迟。很多Pulsar新手会把RabbitMQ处理失败就nack立刻重新投递的习惯带进来。但Pulsar并不推荐这么做因为默认的Re-delivery延迟是0如果你在Consumer里对一条无法处理的消息不停地负确认就会形成死循环。正确的做法是negativeAckRedeliveryDelayMicros这个参数把它设置成秒级别或者更高例如Consumerbyte[] consumer client.newConsumer() .topic(my-topic) .subscriptionName(my-subscription) .subscriptionType(SubscriptionType.Shared) .negativeAckRedeliveryDelay(5, TimeUnit.SECONDS) .subscribe();其次是Receiver Queue Size。这个参数代表消费者本地预取的消息条数默认值在1000条上下。如果在共享订阅里一个Consumer挂着巨大的Queue会一次性拉走大量消息导致同一订阅下的其它消费者长期处于饥饿状态。我在压测环境里就遇到过这个问题——4个消费者负载完全不均衡就因为第一个Consumer启动时会把Queue填满另外三个完全拉不到消息。5.4 消息积压问题的定位思路不止是消费者慢当Pulsar的消息开始积压定位问题的思路和Kafka有本质区别。Kafka积压了大概率是消费者消费能力不足或分区分配不合理。而Pulsar积压了要先去确认消费者是在还没拉取还是拉取了但没确认。我在实践中积累了一套速查思路现象可能原因排查方法积压持续增长消费者CPU很低消费者拉取速度慢或者订阅模式导致分配不均检查Consumer的Receive Queue确认是否是共享订阅积压持续增长消费者CPU很高消息处理逻辑有瓶颈比如调了个超时的外部API查看Consumer的Pending ACK数量检查是否处理阻塞积压突然暴涨之前正常运行某条特殊消息导致消费者大量负确认检查是否有严重的Nack循环看看是不是死信配置缺失积压出现在某个分区上其它分区正常Key_Shared模式下某个Key的消息量大或者某个消费者卡住检查Key_Shared的Key分布确认Consumer健康状态如果确认了是消费者处理能力的问题Pulsar的处理手段就比Kafka灵活很多——直接在共享订阅下加消费者实例就行不需要动topic的分区数无状态Broker会无缝的把消息分发给新加入的消费者。这个过程我在生产环境做过很多次真的做到了服务无重启、消息无丢失。5.5 死信Topic与重试策略的最佳实践Pulsar的死信机制比很多MQ要灵活它可以同时设置死信Topic以及重试Topic。所谓重试Topic其实就是专门存处理失败但还有机会成功消息的Topic消费者在下次启动时会自动先消费重试Topic里的消息再处理主Topic。Consumerbyte[] consumer client.newConsumer() .topic(my-topic) .subscriptionName(my-subscription) .subscriptionType(SubscriptionType.Shared) .deadLetterPolicy(DeadLetterPolicy.builder() .maxRedeliverCount(10) .deadLetterTopic(my-dlq-topic) .build()) .subscribe();这里有个很大要注意的点死信Topic必须开启allowAutoTopicCreation才能自动创建。如果关了自动创建又没有提前手工建好死信Topic那积压到一个程度消息就会一直重投直到达到确认超时的时间消息进入一种反复重投但最终无处安放的状态。我在一个金融项目里吃过这个亏当时团队按文档配了死信策略也配置了自动创建Topic的开关但因为生产环境部分Namespace做了更严格的权限控制默认禁止了自动创建。上线后两天才发现有大量消息卡在重投循环里排查了很久才定位到是死信Topic没建出来。后来的经验是任何时候配了死信策略提前把死信Topic手工建好线上环境不能依赖自动创建这种方便。5.6 Pulsar与Kafka选型别再争谁取代谁现场几乎每个圆桌都在讨论Pulsar和Kafka的未来关系。在我看来二者不是简单的替代关系而是有各自更好的适用场景。对比维度KafkaPulsar架构风格Share-Nothing 分区 本地存储存储计算分离Broker 无状态水平扩展分区扩容成本高Restore 过程长Broker 直加存储独立扩容消费模式基于分区粒度较粗四种订阅模式粒度灵活多租户弱通常靠多个集群隔离原生支持配额、策略内置游标基于内部 topic 的 Offset基于 BookKeeper 的持久化 Cursor历史消息访问Segment 删除粒度粗保留策略精细支持分层存储运维复杂度组件少但扩容疼组件多但日常操作简单我的个人结论是如果你的场景主要是离线分析、日志管道、高吞吐顺序写入Kafka那些根深蒂固的优势仍然存在迁移成本不值得。但如果是微服务解耦、多团队共享、SaaS多租户、混合负载、以及需要大量灵活的消费模型Pulsar的架构优势会更加明显。6. 社区动态与未来趋势Pulsar的下一个里程碑6.1 Pulsar周边生态的活力与挑战Pulsar社区目前的活跃度从这次活动的热度能明显感觉到。几个热门项目的作者都来到了现场包括Pulsar Manager、Pulsar Protocol以及各种客户端库的维护者。这让我重新确信MDC级别的项目正在向更高成熟度迈进。不过也要承认Pulsar生态相比Kafka还是有不小差距。在大数据生态的整合上虽然Flink、Spark都已经支持Pulsar但Kafka的整合力度和成熟度依然更强一些。社区的职位缺口也很现实招聘一个熟练的Kafka运维比找一个经验丰富的Pulsar运维容易得多。这不是技术问题是生态积累的问题需要时间。6.2 从大会氛围看MQ领域的未来方向这次大会让我看到一个很清晰的趋势MQ正在和AI基础设施深度融合。现场聊到的一个典型需求是——如何让大模型在生成过程中实时的消费、分析数据流同时保证模型状态的多租户隔离。从架构上看事件驱动和消息流式处理天然是AI系统中数据进、数据出的高速通道。Pulsar在架构层的弹性伸缩能力、持久化游标能力和多租户能力让它在这一波AI浪潮里具备相当强的叙事潜力。同时Pulsar社区也在明显加大在这些方向的投入批量消息的高效处理、更完善的事务机制以及与数据湖、流湖一体架构的打通。这些都是实打实的Roadmap不是画饼。提醒不管用哪个MQ都有替代方案。但如果你正在为微服务、AI、实时计算等场景选型我建议把Pulsar纳入概念验证清单里尤其是需要多租户隔离、消费模式灵活性和无状态Broker的场景。这个结论放在三年前我会犹豫但现在它的答案越来越清晰。7. 参会后的个人思考与建议7.1 值得立刻尝试的四个方向大会结束后我回想了这次活动带给我的信息量如果只能挑选出最值得立刻上手尝试的几件事我的清单是这样的第一搭建一个哪怕只有单机模式的Pulsar环境把四种订阅模式全部用代码跑一遍。很多东西光看文档是理解不了的比如Key_Shared和Shared在面对相同消息序列时的行为差异你一定要实际动手才能有体感。第二如果你的团队还在用Kafka做微服务间的事件传递试试Pulsar的Kafka协议兼容层。配一套测试环境把相同代码的Kafka客户端切到Pulsar上体验一下消息查重、死信策略和一些Kafka做得比较痛苦的事情。第三认真评估多租户隔离策略。只要你公司有多个业务团队共享MQ集群的需求Pulsar在Namespace级别的配额和流量管理能力就能帮你解决过去最常见的“某个团队把集群干爆”的运维事故。第四把分层存储记到脑子里。如果你长期有保存数月甚至数年消息的合规要求又苦于成本太高Pulsar的Tiered Storage很值得做一轮深度的技术验证。7.2 给技术团队的落地建议如果你想在团队里推动Pulsar从评估走向落地我的建议是不要急着把全部业务迁过来。选择一个非核心、但对消息可靠性有要求的业务先做试点。期间重点观察三件事架构集群的稳定性、消费模型是否有明显改进、以及运维工具链是否顺手。试点没问题再逐步扩大范围这个节奏是最稳的。大会现场我详细问了几个已经在生产环境大规模使用Pulsar的团队得到的一个共通的反馈是刚迁移过去的第一周最痛苦因为Kafka的很多使用习惯要改尤其是消费模型的思维模式。但一旦适应之后真的不太愿意回到Kafka的运维模式中去了。7.3 我的个人感受MQ的再次伟大正在发生作为一个和消息队列打了多年交道的人我经历过RabbitMQ的灵活体验过Kafka的强壮也见证过RocketMQ在电商场景里的独到之处。这次参会最大的感受是消息队列这个领域远没有到成熟定型的那一天。当AI技术、云原生架构和数据基础设施继续往前推进MQ依然是被反复需要的刚需底座。Make MQ Great Again这句口号看起来像是一句调侃但实际上它正在发生。Pulsar就是这个进程里最有代表性的技术之一。如果你也在思考自己团队的消息架构应该怎么演进我非常推荐你把Pulsar纳入视野动手测一测亲自体验一下技术演进带来的实际改变。这次的参会经历让我更加确认了这个方向也推荐所有关注MQ生态的人持续关注Pulsar社区接下来的动作。