能坐在COSCon25的Pulsar Developer Day会场里听台上的人喊出Make MQ Great Again的时候说实话我第一反应是这口号够狂的。但等活动走完一整天、我把现场的分享内容和同行聊的内容捋了一遍之后我得承认这句口号背后是有底气的——过去几年消息队列领域几乎被单一生态的叙事主导而Pulsar社区正试图用一套完全不同的架构理念把消息中间件到底该怎么设计这个本该被反复讨论的问题重新拉回台面上。这篇文章就是我对这场活动的一次完整复盘。里面会聊到Pulsar的核心架构逻辑、会议上反复被提及的消息一致性问题也就是先写数据库还是先写MQ这个老生常谈但极其要命的抉择、从现场Session里提炼的落地经验以及我自己在会前会后整理的一些排坑记录。如果你是正在做技术选型、或者已经在用Pulsar但想深入了解其原理的开发者这篇文章应该能给你一些比官方文档更贴近实战的参考。1. 活动全貌Pulsar Developer Day到底聊了什么1.1 活动定位和日程结构的看点这一天的活动是COSCon25中国开源年会与Pulsar Developer Day 2025合办的专场。COSCon本身就聚集了大量国内开源社区的活跃分子而Pulsar Developer Day则是Apache Pulsar社区面向开发者的年度技术活动两者的受众高度重叠所以会场里既能看到写业务代码的应用开发者也能看到做基础架构的中间件维护者。整个活动的日程排得比较紧凑。上午场以主题演讲为主内容偏宏观包括Pulsar项目的年度进展、社区治理情况、生态工具链的更新下午场则明显更动手向有具体的架构演进案例分享也设置了QA环节。整体看下来主办方想传达的信号是Pulsar不只是一个能跑消息的组件而是一套从存储引擎到客户端SDK、从云原生部署到观测运维的完整体系。1.2 社区数据和版本更新的信号开场演讲公布了几个数据Pulsar的GitHub Star数持续增长社区贡献者数量也在稳定上升尤其来自亚洲地区的贡献者比例明显提高。这些数据本身说明不了太多问题但配合几个技术动向就有点意思了——比如Pulsar 3.x系列版本在持续打磨Broker的元数据服务能力事务消息的稳定性也在逐步增强。最值得关注的一个更新是Pulsar对云原生环境的适配更深入了。Pulsar的Broker层被设计成无状态服务存储层BookKeeper和计算层Broker可以独立扩缩容这套架构在Kubernetes上部署有天然优势。会上有人展示了在K8s里用Helm Chart部署多机房Pulsar集群的方案Broker按流量峰值自动扩容BookKeeper节点按存储容量独立扩展这个演示虽然不算特别复杂但直观展示了Pulsar在资源利用率上的潜力。1.3 Pulsar生态的另一个重要维度协议兼容让我比较意外的是今年Pulsar在协议兼容层面的进展被多次提及。Pulsar从很早起就支持Kafka协议适配Kafka Protocol Handler这意味着原本用Kafka Client的应用可以几乎不改代码地连到Pulsar集群上。会上有一个分享专门讲了这种协议兼容层的设计思路与其强迫用户迁移客户端不如在服务端兼容已有生态让用户可以选择自己的节奏逐步迁移。这套思路在现场的讨论中获得了不少认同。毕竟真实业务系统中消息中间件的替换从来不只是换一个依赖那么简单涉及上下游链路、监控告警、运维习惯的全面调整。Kafka协议兼容让Pulsar可以作为一个平替先接入系统跑稳之后再逐步把流量切过去这个渐进式迁移路径比一夜做完的方案现实得多。2. 架构拆解Pulsar凭什么值得被这么讨论2.1 存算分离Pulsar和Kafka最根本的分歧点很多人第一次接触Pulsar时最困惑的问题是它和Kafka到底有什么区别如果只记一句话那就是存储与计算是否分离。Kafka的Broker节点既负责任务调度、消费管理等计算逻辑同时也把数据以Segment文件的形式存在本地磁盘存储与计算是耦合在一起的。这种设计的好处是简单直接但坏处也很明显——扩分区数量往往受限于Broker节点的存储容量节点故障时数据恢复时间也较长。Pulsar的思路是把存储层彻底抽出来做成一个独立的BookKeeper集群。Broker只负责管理和调度不存任何持久化数据真正的消息数据写入BookKeeper的Bookie节点。Broker是无状态的可以随时加减实例Bookie是存储节点按存储容量扩展。这就像把厨房和仓库分开厨房只管做菜处理读写请求仓库只管囤货持久化数据哪个环节不够用了就单独加人。2.2 数据分片和读写路径的细节Pulsar的数据模型和Kafka有个关键差异Kafka的Topic是分区Partition内严格有序的而Pulsar引入了一个Ledger的概念。Topic的每个分区在Pulsar里叫Topic为便于理解可对应Kafka的分区被拆分成多个Segment每个Segment落在一个Ledger里。Ledger是BookKeeper的核心抽象它把一条条消息追加写入并记录在一个包含多个Bookie节点的Ensemble中。写路径上Producer发送消息到BrokerBroker将消息写入当前Ledger的多个Bookie副本副本数量由配置的Ensemble Size和Write Quorum决定。读路径上Consumer通过Broker读取Ledger中的数据。这套机制带来的直接好处是扩容时不需要做数据重平衡。Kafka加分区通常要触发数据迁移而Pulsar因为数据天然按Ledger切分Broker分配Ledger给新节点即可数据搬迁的压力小得多。2.3 分层存储让无限消息保留变成现实Pulsar还有一个被反复提及的能力是Tiered Storage分层存储。因为底层的Ledger数据是抽象的统一存储接口Pulsar可以配置将较老的Segment自动卸载Offload到对象存储比如S3或其他兼容对象存储的产品中。也就是说热数据留在Bookie上提供低延迟读写冷数据丢到廉价的存储桶里。这套设计对成本敏感的业务很有吸引力。Kafka里消息默认只保留几天想长期留存就得不断堆Broker磁盘Pulsar里你可以只保留最近几小时的消息在Bookie上更老的数据自动归档到对象存储查询时还能透明地读回来。这种访问频率和存储成本的分层思路在数据量增长很快的场景里能节省大量成本。2.4 多租户和跨地域复制是隐藏王牌Pulsar中的Tenant租户、Namespace命名空间、Topic三级模型非常清晰。每个租户的资源可以单独计量和管理不同租户之间数据隔离、权限隔离这对企业内部多个团队共享一个集群的场景非常实用。会上有一个案例分享说他们一个集群接入了七八个业务线每个业务线都用自己的Namespace资源配额和权限可以做得非常细。跨地域复制Replication则是Pulsar的老牌强项。通过配置一个Topic上的消息可以异步复制到其他地域的集群中而且支持多个地域之间的双向复制。这种能力对需要多活容灾、就近接入的业务很重要现场有人分享了从Kafka MirrorMaker方案迁移到Pulsar跨地域复制的经历最大的感受是配置量从几十行YAML变成了一条命令。3. 硬核话题先写数据库还是先写MQ3.1 这个经典问题为什么被反复拿出来讨论在活动的QA环节一个听众问了一个看似基础但让在场不少人都陷入思考的问题业务里到底应该先写数据库再发消息还是先发消息再写数据库这个问题的背后是MQU重大而普遍的痛点——消息发送和业务数据变更之间的一致性。典型的业务场景是这样的用户在商城下单系统需要把订单数据写入订单表同时发送一条消息给积分服务或物流服务通知它们有新订单产生。如果先写数据库消息发失败了怎么办订单已经落库了但下游没收到通知整个链路就断了。如果先发消息再写数据库消息发出去了、数据库写失败了下游处理了一个不存在的订单等于产生了脏数据。这就是先写数据库还是先写MQ的完整困境。3.2 业界常用的几种应对方案第一个方案是本地消息表。在业务数据库里建一张消息表把写业务数据和写消息记录放在同一个本地事务里。事务提交后通过一个后台任务扫描消息表把状态为待发送的消息发给MQ发送成功后更新消息状态。这套方案实现简单、依赖少在很多老系统中仍然适用。缺点是需要侵入业务库、要做消息表的维护和清理以及存在消息重复投递的可能因为发送前要轮询期间宕机可能重复扫描。第二个方案是事务消息。RocketMQ和Pulsar都支持事务消息能力。以Pulsar为例Producer在事务中发送消息事务提交后消息才对Consumer可见。结合先发事务消息-半消息状态-执行本地事务-确认提交的流程可以比较优雅地解决一致性问题。Pulsar的事务消息是在存储层面实现的通过Transaction CoordinatorTC协调多个Topic上的消息原子性提交这比在应用层做控制要干净得多。第三个方案是定时补偿。不追求每一步的强一致而是通过定时任务或对账系统定期扫描数据库里应该发消息但没发出去的记录重新补发。这本质上是一个兜底机制单独使用不太靠谱但作为最后一道防线非常有效。3.3 Pulsar事务消息的实现逻辑会议上有个分享专门剖析了Pulsar事务消息的底层实现这部分信息量很大。Pulsar的事务基于BookKeeper的事务能力引入了两个关键组件Transaction CoordinatorTC事务协调器和Transaction Buffer事务缓冲区。TC负责管理事务的整个生命周期——开启、提交、回滚Transaction Buffer则存在于每个Topic分区中用于缓存事务消息在事务提交前这些消息对Consumer不可见。事务的流程大致是Producer向TC发起事务开启请求拿到Transaction ID然后在事务内发送多条消息这些消息先进入Transaction Buffer对其他Consumer不可见业务代码执行本地数据库操作最后Producer提交事务TC确认所有相关的消息都已写入并通知Transaction Buffer将消息释放给Consumer。整个过程保证了发消息和本地写库的原子性——要么都成功要么都失败。当然事务消息也不是万能的。Pulsar官方建议只在确实需要原子性操作的场景使用因为事务机制本身会带来额外的协调开销和延迟成本。对于大部分做了幂等设计的消费场景普通消息配合重试机制反而更高效这个度需要结合业务的实际接受范围来取舍。3.4 幂等消费是永远绕不开的伴侣不管是本地消息表还是事务消息消息的发送方都只能保证至少一次At Least Once投递无法保证恰好一次Exactly Once。因为网络环境里存在不确定因素消息可能被重复投递而重复投递在大多数业务场景中是不可接受的所以消费者的幂等设计是消息系统中最重要的一块基石。现场有个分享者讲了一个很接地气的幂等方案在消费者处理消息前先去Redis里查一下这条消息的唯一业务ID是否已经处理过如果没有则处理处理完把ID写入Redis。如果重复投递直接消费但不处理。这个方案的优点是简单、性能好缺点是需要额外维护Redis状态以及处理Redis本身的高可用。另外一个替代方案是在数据库层做幂等比如用唯一约束或事务记录来防重。4. 从现场Session里提炼的落地经验参考4.1 技术选型什么时候选Pulsar而不是其他消息组件每一场技术活动都逃不开到底该选谁做我的MQ这种问题今年Pulsar会场的答案也很明确不是所有场景都需要Pulsar但存在三类典型场景确实更适合Pulsar。第一类是数据量超大、要求消息留存时间长、且消费模式以离线或回溯为主的场景。Pulsar的分层存储特性可以廉价地保存海量历史数据这是Kafka比较难做到的。第二类是需要多租户隔离、多人共享基础设施的To B场景Pulsar的Tenant/Namespace模型让不同业务线可以用一个集群却互不干扰。第三类是对低延迟和动态扩缩容要求都比较高的云原生场景Broker无状态加上Ledger分片机制让Pulsar在容器环境里能获得更好的弹性。如果你的业务还在初期阶段消息量不大、团队对Kafka生态极度熟悉、也没有多租户和长留存的需求那继续用Kafka或者干脆用云产商提供的消息队列服务完全没问题。技术选型永远是为业务服务的而不是为了技术上的更先进盲目切换。4.2 一个从Kafka迁移到Pulsar的模拟路径有分享者用了一个蛮典型的案例说明从Kafka迁移到Pulsar的完整路径第一步是先做协议层面的替换利用Pulsar的Kafka Protocol Handler让所有Kafka客户端原封不动地连到Pulsar集群上。这个阶段集群底层已经变成Pulsar了但应用层毫无感知风险最小。第二步是做数据双写或同步迁移。在Pulsar和Kafka之间架设Connector新产生的数据同时写入两套系统比对两边数据一致性逐步把读流量的比例切到Pulsar。第三步是替换客户端SDK。把应用里的Kafka Client换成Pulsar Client同时改造部分业务代码以适配Pulsar的消费模型。整个过程按照基础设施替换→数据同步比对→客户端替换→全量切换推进每一步都有回退的可能比直接切换稳妥得多。4.3 给Pulsar集群调参的一些经验整理现场有不少从事中间件运维的开发者他们关心的参数问题非常具体。比如Ledger的Ensemble Size和Write Quorum怎么配Ensemble Size决定一个Ledger的数据分布在多少个Bookie上Write Quorum决定每条消息同步写入的副本数。生产环境建议设置Ensemble3、Write Quorum3这样每个数据块都有3份副本如果追求更高的写入吞吐可以调整为Ensemble5、Write Quorum3利用更多的节点分散写入压力。Bookie的磁盘IO类型也是重点。因为Pulsar的读写路径上Journal日志是写关键路径几乎每次写入都要fsync所以Journal盘建议使用独立的SSD或者NVMe盘。Ledger数据落在Ledger盘上可以用普通SATA盘配RAID但务必和Journal盘物理隔离。如果预算充足直接用多块SSD分担IO是省心做法。4.4 研发阶段最值得关注的几个细节从我自己的体验来说Pulsar客户端API的初步上手不算困难但有几个细节比较容易踩坑。第一个是Consumer的订阅类型选择。Exclusive独占订阅只允许一个消费者消费某个TopicShared共享订阅允许多个消费者瓜分消息Failover灾备则是主消费者挂了备消费者顶上。很多人误以为Shared订阅是消息广播给所有消费者希望像订阅发布模式一样让每个消费者都收到全量消息结果只收到了一部分。这属于概念混淆建议在开发前先把订阅模型搞懂。第二个是消费位点Message ID的管理。在Pulsar中有几种消费起始位置设置默认从最新消息开始、也可以从最早或指定时间开始。如果Consumer上线时想消费之前积累的全部消息要把SubscriptionInitialPosition设置为Earliest否则新消费组默认不会去读历史数据容易造成消息去哪儿了的错觉。5. 现场问答和后台交流里的避坑记录5.1 消息积压和消费变慢怎么定位怎么解现场被问得最多的排障问题就是消息积压Backlog。Pulsar的Broker管理台和Web UI里都能看到Topic的Backlog大小如果持续增长就说明消费速度跟不上生产速度。第一步先看是哪个Consumer Group在拖后腿把消费端日志和指标打开看是下游调用延迟过高还是消费者线程数配置太小。如果是下游依赖的慢查询导致的消费阻塞这时候直接加消费者线程往往只会让下游挂得更快应该先优化下游接口。还有一个常见原因是消费者处理过程中出现了大量消息重试。比如消息体解析失败、业务校验不通过代码里又没有做有效重试策略导致一条消息反复消费、消费位点不推进。建议在开发阶段就给消费者配上死信队列DLQ机制Pulsar的Topic可以配置死信Topic超过最大重试次数的消息自动转移到DLQ再单独分析原因避免它们阻塞主链路。5.2 数据丢失的场景和排查思路消息系统最怕数据丢而Pulsar的数据丢失多半发生在BookKeeper层面。最常见的一种情况是Write Quorum和Ack Quorum配置不合理。Ack Quorum表示写请求需要几个副本确认才算成功如果Ack Quorum设置比Write Quorum小那么某份数据可能只写到了部分Bookie上一旦这些Bookie同时故障数据就会丢。生产环境建议至少保持Write QuorumAck Quorum3。另一种丢数据的情况和消费位点有关。消费者手动确认Acknowledge了某条消息但实际业务逻辑还没完全处理完。比如先Ack后再调用下游接口如果调用失败消息就再也拉不回来了。正确做法是先处理业务逻辑、后返回Ack或者使用累积确认加定时Ack的策略。这个是老生常谈但每次出问题都还有人在踩。5.3 运维层的几个实用心得Bookie故障是运维Pulsar时必然要面对的事件。单台Bookie坏了Ledger会自动把数据重新复制到其他Bookie这个过程叫数据重建Re-replication。现场老司机提醒了一个细节重建过程会消耗网络带宽和磁盘IO如果集群本身已经处于高负载状态重建可能进一步拖垮集群性能所以建议给重建任务设置限速参数。Broker层的优化也有讲究。因为Broker是无状态的所以当流量上涨时理论上可以随时加节点但实际中要注意元数据服务的压力。Pulsar使用ZooKeeper或etcd作为元数据中心如果Topic数量非常多元数据频繁变更会给ZK带来大量读写压力需要单独关注ZK集群的指标。6. 写在最后关于Make MQ Great Again的一点个人感受活动结束后我一直在想Pulsar社区为什么要把Great Again喊得这么响。在我看来哪怕Pulsar在市场份额上距离Kafka还有不小的差距但技术选择的多样性对整个产业是有益的。消息队列领域需要Kafka这种普惠生态也需要Pulsar这种试图从架构层面做出突破的方案让大家意识到消息中间件不是只能按同一种范式设计。根据我自己的使用经验来说Pulsar的上手曲线确实比Kafka要陡峭一些——理解BookKeeper、Ledger、Cursor这些概念需要投入不少时间事务消息和各种订阅模型的组合也容易懵。但一旦跨过这个坎你在面对消息堆积可不可以无限保存存储和计算能不能分开扩缩容多租户隔离到底应该怎么做这些问题时会有更多选择空间这种架构层面的自由度在业务规模变大之后尤其值钱。如果这篇文章能让你对一个消息队列的未来发展方向多了一些了解或者让你在选择技术方案时多了一个可考虑的选项那这趟COSCon25没白来。最后再分享一个我在实践中领悟的小技巧不管最后选了什么MQ先把消费端的幂等和重试机制设计好再复杂的消息链路也乱不到哪儿去。
