从COSCon'25看消息中间件新风向：Pulsar架构与实践

COSCon‘25 的同场活动里，Pulsar Developer Day 的议程一发布，瞬间就成了咱们聊消息中间件的人最关注的事。消息中间件这个老话题，这几年被云原生、事件驱动、实时数仓这些概念反复拉扯，从选型到运维再到成本治理，坑多不说，风向也一年一个样。这次专门给 Pulsar 开一个开发者日，其实信号很明确：在分布式系统越来越“重”的今天，消息中间件不再是你架构里可有可无的管道，而是决定系统能走多远的心脏。这篇文章就借着这次议程的关键方向，把消息中间件选型、Pulsar 核心机制、落地实操和排障经验串一遍，给做架构设计、中间件维护、后端开发的兄弟们一份可以直接参考的笔记，不管你是刚要把 Kafka 换掉，还是第一次认真了解 Pulsar，都能从中找到对应的决策依据。

1. 从这次议程看消息中间件的新风向

1.1 为什么消息中间件又成了焦点

很多人觉得消息中间件是个成熟得不能再成熟的领域，十几年的东西了，Kafka、RabbitMQ、RocketMQ 各自坐镇一方，还有什么可折腾的？但如果真的在业务线上摸爬滚打过，你会发现，消息中间件的麻烦从来不是“能不能用”，而是“在什么规模、什么约束下能不能用得住”。

现在的业务系统早就不是一台机器、一个数据库、一个应用能搞定的了。微服务拆得越细，服务之间的数据流动就越频繁，异步化成了刚需；数据团队又要求实时性和准确性，流批一体、实时数仓都在抢消息队列这条“主干道”；再加上多云、混合云甚至边端协同这些部署形态，消息系统面对的早就不再是“转发几条订单消息”这么简单的场景了。

这个时候消息中间件的技术含量就凸显出来了。你的消费者要多快地消费、积压了怎么办、数据能不能不丢、跨机房怎么复制、存储成本怎么控制、多团队共用一套集群怎么隔离权限和配额，每一个问题落到实地上都是一场硬仗。这也是为什么像 COSCon 这种开源大会，会把一个专门的日子留出来讨论 Pulsar。大家听的不是概念，是那些已经在生产环境里淌过一遍后的实践经验。

1.2 Pulsar 凭什么占据独立活动板块

说实话，Pulsar 不是消息中间件里的新人，它在 Apache 基金会下面也已经积累了很多年，但过去很长一段时间里，它给人的印象是“架构先进，落地复杂”。最早是为解决 Yahoo 内部超大规模存储和低延迟消息需求而设计的，底层把 Broker 和 BookKeeper 做成了完全分离的架构。这个架构在当时非常超前，很多团队一听要额外维护 BookKeeper 这套存储层，就开始打退堂鼓。

但到了云原生时代，你会发现当初的“复杂”反而成了优势。Kubernetes 普及以后，无状态的服务天然适合弹性伸缩，而 Pulsar 的 Broker 不持有持久化状态，扩缩容非常干净；BookKeeper 虽然多了一层，但它带来的好处是存储计算分离、多租户隔离、分层存储、跨地域复制这些能力，都是企业上云之后真正需要的硬需求。

这就形成了一个很有意思的对比，传统消息队列像是把“收件箱”直接堆在每台服务器上，扩容的时候要连数据一起搬；Pulsar 则像是把“邮局”和“仓库”分开，邮局只管收发登记，仓库统一保管信件，哪个环节忙了都可以单独加人加仓库。

单论吞吐量，Kafka 在部分场景下依然很能打，但论架构在云原生环境下的适配度、多租户的隔离性、以及存储成本的灵活性，Pulsar 这几个特点刚好踩中了企业上云和组织规模化后的痛点。也正因为这样，它才有底气在 COSCon 这种大会上单独撑起一个活动日，而且议程全部围绕实践和踩坑展开，而不是打概念。

1.3 从议程设置读行业信号

我翻了下这次 Pulsar Developer Day 的公开信息，虽然具体每个演讲的主题各有侧重，但能明显感受到几个高频方向：架构演进、性能调优、实践落地、生态集成。这几个词看着常规，其实每个都对应着生产环境里的一类焦虑。

先说架构演进，凡是讲这个的，背后基本都站着一个“原来只用 Kafka，后来因为某个需求发现顶不住，或者成本太离谱，所以转向 Pulsar”的团队，他们讲的是决策过程。性能调优就更直接了，说明消息中间件的瓶颈从来不是产品功能层面的问题，而是配置、参数、资源隔离这些细节问题，大家真正缺的是有人把参数背后的原理和实测数据讲清楚。

实践落地和生态集成也很有意思，消息中间件单独存在没什么意义，它要跟 Flink、Spark、Pulsar Functions、数据湖、微服务框架打通才有价值，所以议程里凡是涉及生态的，都是在讲“怎么让消息中间件真正融进你的技术栈”。

把议程里这些方向串起来看，其实就是一句话：消息中间件正在从“能用”走向“好用、省心、省成本”。谁能在这一轮里把架构理清楚、把参数调明白、把运维成本降下来，谁就能在生产环境里真正占据主动。

2. Pulsar 核心机制拆解：开发者到底该关注什么

2.1 存储与 Broker 分离的底层逻辑

说到 Pulsar，绕不开的就是它“存储计算分离”的架构。这个设计不是想当然拍出来的，而是为了解决一个非常具体的矛盾：消息中间件的数据是要持久化的，但持久化数据的节点又很难弹性伸缩。

传统消息队列把数据分区打散到各个 Broker 节点上，每个 Broker 既负责收发消息，又负责把数据写到本地磁盘。这个模式下，扩容一台 Broker 不仅仅是加一个服务节点，还涉及分区数据的重新分布，总会有一段迁移时间，而且一旦某个节点磁盘压力大，整个分区的生产者消费者都会受影响，这是典型的存储和计算耦合带来的问题。

Pulsar 的做法是把 Broker 和存储层彻底分开。Broker 变成完全无状态的服务，只处理客户端的连接、路由、权限这些逻辑；真正的数据持久化交给底层的 Apache BookKeeper 集群，BookKeeper 用一组 Bookie 节点组成存储池，数据通过分段日志的方式写入多个 Bookie 做冗余。

好处是什么？Broker 这一层你可以很从容地做水平扩展，业务高峰来了多加几个 Pod，低谷了缩回去，数据一点不用搬。存储这一层则专注于数据安全、副本策略、容错，两者可以独立扩容，这对 Kubernetes 环境下的资源调度特别友好。如果你已经用上了容器化部署，就会明白这个设计让运维省了多少心。

我第一次接触这个架构的时候，觉得它最妙的地方在于把“无状态应用”和“有状态数据”分得干干净净。无状态的东西都好说，挂了就有新的顶上；有状态的东西最难管，所以单独交给一套成熟可靠的存储系统比让每个消息节点自己管数据要稳得多。

2.2 多租户、命名空间与分层存储的实际价值

Pulsar 里有三个层级的概念：租户（Tenant）、命名空间（Namespace）和主题（Topic）。租户一般是给一个团队或者一个业务域用的，管理员可以在租户级别配置权限和配额；命名空间是租户下面再做隔离和策略配置的单位，比如这套命名空间的消息保留三天，另一套保留三十天；主题就是最具体的消息通道。

这套层级模型在现实里的意义非常大。以前用很多开源消息系统的时候，线上一个集群往往被多个团队共用，缺少逻辑隔离的手段，你只能靠 Topic 命名规范来约束，谁也别越界，出了问题只能靠人去查。

有了租户和命名空间这两种隔离单位，相当于给消息集群做了“虚拟化”。运维团队可以把一套 Pulsar 集群分配给多个业务方使用，每个业务方的认证、授权、存储配额、消息保留策略都能独立配置，互不干扰。既节省了物理集群的数量，又保住了隔离性，对于基础设施团队来说这是一种兼顾效率和安全的模式。

分层存储（Tiered Storage）同样是省钱利器。大多数业务的消息，热数据可能只需要保留几天，但出于审计、补数、重放的需求，又希望能把数据保留更长的时间。如果所有消息都放在高性能磁盘上，存储成本会非常难看。

Pulsar 的分层存储机制可以把旧的分段数据自动转移到对象存储，比如 S3、GCS 这种便宜的存储上，同时让消费者还能正常消费这些“冷数据”。这样一来，热数据走低延迟盘，冷数据走廉价的云存储对象，成本和体验两头兼顾。对做数据平台的团队来说，这一项配置能直接降低一大块存储账单。

2.3 消费模型与消息确认的隐性细节

聊 Pulsar 的功能，订阅模式是绕不开的。Pulsar 提供了四种订阅类型：独占（Exclusive）、共享（Shared）、灾备（Failover）和键共享（Key_Shared）。很多刚接触的人会把这几种模式跟 Kafka 的消费组混在一起理解，但实际上它们的适用场景差别很大。

独占订阅就是一个 Topic 同一时刻只能被一个消费者消费，适合要求严格有序的场景，但扩展性有限，消费能力扛不住的时候就很难受。共享订阅是多个消费者一起消费一个 Topic 的消息，吞吐量上来了，但消息会分发给不同的消费者，消费顺序就无法保证了。灾备订阅和独占类似，但会多准备一个消费者作为备份，主消费者挂了可以顶上。键共享则是在共享的基础上，保证拥有相同 Key 的所有消息被同一个消费者处理，这对于保证单用户维度有序性但又想横向扩容的场景特别合适。

消费者确认机制（Ack）也值得细看。Pulsar 支持单条消息确认和累积确认，单条确认就是每消费完一条消息就回一个 Ack；累积确认是把某个位置之前的所有消息都确认掉，依赖底层 bookie 的游标管理来实现。

这里面容易踩坑的是重试和死信的处理。如果消费者处理消息失败，可以选择立即重试、延迟重试或者直接发给死信主题。比较推荐的做法是把可控的临时错误交给延迟重试，把多次重试失败的消息投递到死信主题，由单独的补偿任务去分析处理，而不是让消费者无限阻塞在一条毒消息上。

3. 开发者活动议程里，值得深入的技术主题怎么听

3.1 建议重点关注的主题方向

因为我手头没有那份议程文档的完整逐条内容，下面这部分是根据公开通告信息和同类活动的常见安排做的合理推演，用来帮大家建立自己的“听课地图”是可以的，但具体演讲顺序还是要以现场安排为准。

从同类开发者活动来看，这类议程通常有这么几个方向，而且每个方向都有不同的听法：

为什么我把这些主题列出来？因为不同主题演讲的信息密度分布差别很大。架构演进类的演讲，最关键的信息通常在中间那段，也就是“我们是怎么发现旧方案扛不住的”；性能调优类的信息集中在最后，参数表格和对比数据才是精华；业务实战类最值得听的是他们失败的部分，这才是真正的经验沉淀。

3.2 把一场演讲听成一场信息获取过程

很多人参加这类技术会议，喜欢从头到尾把 PPT 拍下来，然后回去就再也没打开过，其实是浪费了会议最大的价值。听架构类分享的时候，我习惯重点记以下几个信息：他们原来的规模是多少，遇到了什么问题，新的架构引入了哪些组件，替换过程中最大的风险点是什么。

如果是讲 Pulsar 参数调优的，我会特别关注几个对比数字，比如调整 Batching 之后吞吐提升了多少、消费端并发从多少调到多少、延迟从多少降到多少。这些数字也许和你自己的系统没法直接对照，但这些参数调整的方向性是通用的，回去照着做一轮压测就一目了然。

互动环节是最值得利用的。如果演讲者没有放联系方式，那就尽量在 Q&A 问一个具体的问题，比如“你这个参数在消费者业务逻辑比较重的情况下还有效吗”，这种问题能逼着演讲者把上下文补齐。技术分享的泛泛而谈没有太大价值，好的问题能把一场演讲里最有价值的隐含假设挖出来。

3.3 会后跟进：把会议的输入变成自己的产出

听完议程回来之后，最忌讳的就是收藏夹里多了一堆链接。我自己的流程是，当天晚上花半小时把听过的主题写一个零散笔记，不追求完整，就记那些触动自己的点，比如某个参数、某个架构图、某个大家反复提的问题。

然后挑一个和自己当前工作最相关的方向，做一次小范围验证。如果正愁 Kafka 消费积压，那就重点研究 Pulsar 的共享订阅和 Key_Shared 订阅有什么区别；如果正要设计一套新的实时数据管道，那就去看看 Pulsar 的跨地域复制配置在自己云环境里怎么跑通。

再进一步，可以去读一下演讲者提到的源码文件。Pulsar 是 Apache 开源项目，源码都在那里摆着，很多演讲里没有展开的细节，比如某个参数默认值为什么是 5MB，某个组件为什么采用这种一致性协议，读源码都能找到答案。把会议内容变成一次实际验证，才是参加这场活动的完整闭环。

4. 消息中间件落地实操复盘：选型、改造与排障

4.1 选型阶段先想清楚这三件事

很多团队选消息中间件，先比的是吞吐量数据，但你问他们要真实的生产流量模型，往往又说不出一个清晰的数字。选型的第一步不是看哪个中间件厉害，而是把自家的业务场景量化清楚。

第一件事是流量模型。你的峰值发送速率是多少？消费方是稳定消费还是突发消费？消息体大小平均多大？消息的写入频率和消费频率差值大不大？这些数字直接决定了你需要的吞吐量级别和积压能力。Kafka 在小消息、高吞吐场景下确实有优势，Pulsar 在大量 Topic、动态扩缩容、多租户场景下更灵活。

第二件事是一致性要求。订单、支付、库存这类核心链路，对消息丢失是零容忍的；日志采集、指标上报这类偏数据分析的场景，可以容忍少量丢失换取更低的延迟和成本。不同的消息中间件在这两者之间的取舍是不同的，你把自己的一致性需求定级之后，才知道能不能用异步刷盘、能不能降低副本因子。

第三件事是运维能力。你们团队有没有精力维护一套 BookKeeper？现有基础设施是不是已经容器化？公有云上有没有托管的 MQ 服务？这些问题不解决，再先进的消息中间件落地的时候都会变成运维灾难。

如果团队规模不大，我一般建议优先考虑托管服务或者成熟的云产品，把精力集中在业务上；等数据量真正大到一定程度，再认真评估自建集群的收益。自建不是目的，省成本、拿性能、控架构才是目的。

4.2 从 Kafka 迁移到 Pulsar 的实施路径

很多团队对 Pulsar 感兴趣，原因是 Kafka 在某个规模下遇到瓶颈了。但从 Kafka 迁到 Pulsar 不是改个客户端依赖那么简单，Topic 语义、消费组模型、消息格式都可能存在差异，必须分步骤走。

先做兼容性评估。业务代码用的是 Kafka API 还是高级抽象？用没用 Kafka Streams？Kafka Connect 的任务有多少？如果用了 Kafka Streams，迁移到 Pulsar 的工作量明显更大，因为 Pulsar Functions 的编程模型跟 Streams 不完全一样，需要改写一部分处理逻辑。

然后是并行运行阶段。两个消息系统同时上线，生产端按一定比例灰度切流，消费端做双消费，验证新系统的延迟、吞吐和消费准确性。这个阶段最需要关注的是“消息有没有丢”“有没有重复消费”“积压情况怎么样”这三个指标。

接下来是正式切流和回滚预案。比较稳妥的做法是先切非核心业务，稳定后再切核心链路。一旦切流后出现异常，需要能快速回切到原系统，所以旧集群不要急着下线，保留至少一到两个业务周期再决定是否清理。这个周期可以覆盖业务的高峰、低峰和活动大促，确保各种流量形态都验证到位。

我在实际推动这类迁移项目的时候，最大的教训就是：技术上最难的往往不是新系统的性能，而是数据比对。两边并行运行那段时间，消费端要把两边拉到的数据抽样比对，确保一致。这步做扎实了，后面切流才有信心。

4.3 性能调优的几个关键参数

Pulsar 的性能调优和很多消息中间件一样，参数一大堆，但真正决定系统表现的往往是几个关键点。我会特别关注生产端的 Batching，消费端的 Ack 策略，以及 Topic 分区和消费者的数量匹配。

生产端 Batching 指的是生产者把多条消息攒成一个批次再发送，这样可以大幅减少网络往返次数和 bookie 写入次数，吞吐量提升非常明显。但代价是单条消息的延迟会变大。适合高吞吐、对延迟不太敏感的场景；如果业务里存在大量单条低频消息，可能需要把 Batcher 的最大消息条数调小，或者根据 key 做分区。

消费端最大的坑是 Ack 太慢导致重复消费和积压。默认情况下，消费者处理完消息之后才回 Ack，如果消息是异步处理的，要特别注意 Ack 超时时间，避免消息被多次投递。Pulsar 的 Negative Ack 和重试 Topic 也要配合使用，才能做到“快失败、快重试、不死等”。

Topic 分区数和消费者的关系也很关键。一个主题有 N 个分区，单个订阅里最好保证消费者数不超过有效分区的数量，否则多余的消费者会闲置；如果消费者太少，一个消费者要消费多个分区的消息，又可能出现单消费者成为瓶颈。这个话题没有绝对的标准答案，最终还是要结合消息大小和处理耗时的压测数据来确定。

4.4 线上消息故障排查建议

我把自己在实际运维中遇到的高频故障整理成了下面这个速查表，排查顺序基本也是按表格从上到下走的。

消息中间件排障里，我最建议先看指标再看日志，因为消息系统的参数指标能快速缩小问题范围。Pulsar 自带很多 Prometheus 指标，比如存储等待时间、缓存命中率、后台活动线程池状态，这些指标比服务端日志更早表现出异常。日志负责还原细节，指标负责定位方向，两者结合才能少走弯路。

5. 社区活动的隐藏价值：为什么开发者该多参与这类会议

5.1 除了议程，开源社区能给你什么

很多人参加技术大会，习惯性地把自己定位成“观众”，从头听到尾，像看一档技术纪录片。但 COSCon 这种由开源社区组织的活动，和普通商业大会最大的区别在于，讲台上的人就是你平时在 GitHub 上看到的那个维护者、提 Issue 的那个人、PR 被 Review 的那个人。

在活动现场，你完全可以抓住 Q&A 或者展台交流的机会，去问一个困扰自己很久的问题，比如某个参数在特定版本里的行为差异、某个已知 Issue 的 workaround、某个新特性的设计动机。这些问题在评论区可能等一周都没人回，但在现场可能三句话就聊明白了。

这种面对面的交流还能帮你捕捉到路线图信息。开源项目的 Roadmap 往往不会作为正式文档发布，但维护者在闲聊中会透露一些方向性的想法：“我们正在考虑把 xxx 模块重构”“下一版可能会改掉这个默认值”。这些信息很值钱，能让你提前判断自己团队的选型和投入方向是不是走在正确的路上。

社区活动也容易帮你拓宽技术视野。你可能是来看 Pulsar 的，但同场还有各种其他开源项目的展台，不同项目之间的碰撞往往会带来新的灵感。比如消息中间件和可观测性项目怎么结合、和数据编排项目怎么配合，这些跨领域的火花在大流量的大会会场里比在线上更容易产生。

5.2 把会议变成技术雷达

我一直把参加这类大会当成一台“技术雷达扫描仪”。当多个演讲都在围绕同一个关键词展开的时候，那个关键词大概率就是接下来一年的技术热点。像这次活动聚焦消息中间件，而且把 Pulsar 作为核心主题，说明云原生时代大家对消息基础设施的要求又抬高了一层。

会后我会做三件事：把会议相关的代码仓库 Star 几个，然后挑一个跟工作相关性最高的项目下载下来跑一跑 demo；把演讲稿里提到的博客或设计文档整理进自己的阅读列表；最后，如果有涉及新版本特性和参数变化的演讲，就去官方文档里核对一下具体的配置项。

这套动作看起来简单，但每次都能让参会效果翻几倍。收藏不是产出，跑通和记录才是。大会像是一个信息源，真正能带来价值的是你把它转换成自己系统中的一笔实际操作。

我个人在参加过几届开源大会之后，最大的体会是：这种活动的价值不是“一顿饭的时间听听别人怎么说”，而是“用几天的时间集中把一个领域的技术脉络理清楚，然后再用接下来一个月的时间验证和消化”。所以，哪怕这次 Pulsar Developer Day 上只有一个演讲方向跟你当前的工作沾边，也值得认真听进去，回来动手试一试。技术这东西，自己踩过坑、调过参、看过指标变化，才算真正学到手，收藏夹里的 PPT 和链接，隔一个月再看基本就只剩下“我好像看过”了。