存算分离与分层存储：Pulsar Developer Day 看消息中间件创新实践

1. 活动背后的消息中间件行业风向

1.1 为什么 Pulsar Developer Day 值得被认真对待

COSCon'25 同场活动 Pulsar Developer Day 的议程一公布，我身边不少做后端架构的朋友就开始转发了。说实话，这几年消息中间件领域的热度一直没降过，但像这样专门为一个开源消息系统办一场完整的开发者日，而且还是在国内顶级开源大会 COSCon 上作为同场活动出现，确实是一个值得注意的信号。

Apache Pulsar 在消息中间件圈子里的地位，用一句话概括就是：它把“消息系统”和“流存储”两件事揉在了一起，而且揉得相当彻底。如果你所在的公司正在做微服务拆分、数据管道建设、事件驱动架构改造，或者正在为 Kafka 的存储成本、分区扩容、跨地域容灾这些事头疼，那 Pulsar 大概率是你评估清单里绕不开的名字。

这次 Pulsar Developer Day 选在 COSCon'25 期间举办，议程方向聚焦“创新实践”，意味着来的演讲者多半是真正在生产环境里跑过 Pulsar 的人，讲的不是概念，而是踩坑、调优、架构演进这些一线经验。对于正在做技术选型、或者已经在用 Pulsar 但想进一步压榨性能的开发者来说，这种内容密度是普通技术文档给不了的。

1.2 这个消息对你到底有什么用

如果你是下面这几类人，这篇议程解读和背后的技术拆解就是给你写的：

• 架构师 / 技术负责人：正在纠结消息中间件选型，想搞清楚 Pulsar 和 Kafka、RocketMQ 的本质区别，以及它在云原生环境下的真实表现。
• 后端开发工程师：项目中已经引入 Pulsar，但只停留在“发消息、收消息”的 API 层面，想深入理解它的存储模型、IO 模型、流量控制和限流机制。
• 运维 / SRE：需要评估 Pulsar 的集群部署成本、监控告警、故障恢复手段，关心它能不能在现有的基础设施上平稳落地。
• 开源技术爱好者：不满足于只会用轮子，想通过一次高密度技术分享，看到 Apache 顶级项目在真实场景里被用得有多野。

我先把话放这儿：这不是一篇替你复述议程的“活动预告”，而是围绕 Pulsar Developer Day 背后那几条技术主线，把消息中间件领域的核心问题、解决思路和实战经验拆开揉碎讲清楚。哪怕你最后没去现场，这篇文章也能让你对这个领域的最新实践方向有一个完整的把握。

2. Pulsar 的核心设计到底强在哪

2.1 存算分离：Pulsar 架构的灵魂

理解 Pulsar，第一关就是理解它的存储架构。Pulsar 从第一天起就做了存算分离：Broker 负责消息的路由和分发，BookKeeper 负责消息的持久化存储。这两个组件可以独立扩缩容，Broker 是无状态的，需要扩展吞吐时直接加 Broker 节点；存储容量和 IO 能力不够了，只需要扩展 BookKeeper 节点。

这个设计在架构层面带来的好处是决定性的。拿 Kafka 来对比，Kafka 是典型的存算一体：一个 Broker 节点既要处理客户端请求，又要管理本地磁盘上的分区数据。消息量涨了，分区数就得跟着涨，但每个分区在集群里只有有限个副本，热点分区一旦出现，那个节点就成了整个集群的瓶颈。更麻烦的是分区迁移要复制大量数据，运维操作像在走钢丝。

Pulsar 的做法则是把数据写入交给 BookKeeper 的分段存储机制。BookKeeper 会把消息按 segment（分段）打散到多个存储节点上，每个 segment 有多个副本，读写 IO 天然就分散开了。Broker 层面不再需要关心“这个分区落在哪个节点上”，它只管内存里的缓存和分发逻辑，数据持久化和节点故障恢复的脏活累活全部下沉给了 BookKeeper。这个抽象的价值，在你需要扩容、缩容、替换故障节点时体现得特别明显。

我见过很多团队在做 Kafka 跨机房容灾时，光是处理 mirror maker 的数据同步延迟和数据一致性就把头发熬白了。而 Pulsar 原生支持多集群复制，它用的是基于 BookKeeper 的存储层复制，配置层面就能完成。这次 Pulsar Developer Day 的议程里，如果讲到跨地域容灾和多集群管理，那基本上都是在展示这一层架构红利。

2.2 分层存储：让消息数据不再成为成本黑洞

消息中间件有一个长期痛点：数据只能存几天，删晚了成本受不了，删早了业务又来不及消费。尤其在事件驱动架构里，很多分析任务需要回放几天前甚至几个月前的消息，Kafka 在这类场景里会被存储成本卡得非常难受。

Pulsar 的分层存储（Tiered Storage）解决的就是这个问题。它的原理是：热数据留在 BookKeeper 里保证高吞吐读写，老数据根据策略自动卸载到 S3、GCS 或 HDFS 这类廉价存储上。当消费者需要回溯读取老数据时，Broker 会自动从分层存储里把数据拉回来，对消费者完全透明。

这个机制在实际业务中的价值，不是省了一点磁盘钱那么简单。它意味着你可以放心地把消息保留时间从 3 天改成 30 天，甚至更长，而不用在成本预算上被运维挑战。事件溯源、审计日志、机器学习特征回放这类需要长周期数据访问的场景，也因此获得了以前只有专业流存储系统才能提供的支撑能力。

我记得有一个做物联网数据采集的朋友跟我聊过，他们的设备事件每天产生好几个 TB，之前用 Kafka 只能保留两天，业务要回溯设备故障原因时经常面临数据已经过期的尴尬。后来迁移到 Pulsar，配合分层存储把历史数据丢到对象存储上，成本降了一个数量级，业务回溯窗口从 48 小时扩展到了 60 天。这种体验上的差距，是任何调参和优化都补不回来的。

3. 从 Pulsar Developer Day 看创新实践的三个方向

3.1 主题演讲的关键看点：大规模生产环境如何调优

标题里的“创新实践”四个字，落在 Pulsar Developer Day 的议程里，最实在的呈现方式就是一线团队分享他们的生产经验。按照这个领域技术大会的惯例，这类活动的重头戏通常是：

• 大规模集群的容量规划和资源隔离策略
• 高吞吐场景下的延迟优化和内存调优
• Broker 和 BookKeeper 的参数配置实战
• 监控指标体系建设和告警阈值设定

Pulsar 的参数体系很庞大，比如 managedLedgerCacheSizeMB（Ledger 缓存大小）、journalSyncData（BookKeeper 同步刷盘策略）、defaultNumberOfStorageNodes（存储节点分布参数）等等。这些参数单独看都能在文档里找到解释，但组合在一起的效果如何，只有在真实压测和生产数据里才能摸得清。开发者日这类场合最有价值的地方，就是有人会告诉你他们最终用的什么配置、踩过什么坑、调整前后对比数据是多少。

如果你自己去搜这些调优经验，互联网上能查到的大多是零散的 issue 讨论和 Stack Overflow 问答，信息碎片化严重。而 Pulsar Developer Day 把这些经验系统地组织成演讲主题，等于帮从业者省去了大量收集和试错的时间。

3.2 实际案例：消息中间件如何支撑业务创新

技术大会的另外一个价值，是看别人怎么把一套技术用出花来。结合我这几年的观察，Pulsar 在以下几个场景里的实践案例特别值得关注：

• 金融交易系统：利用 Pulsar 的严格顺序保证和事务支持，处理订单流和支付事件，保证不丢不重。
• 车联网平台：百万级车辆同时上报位置信号，利用 Pulsar 的多租户能力做不同车型、不同业务线的资源隔离。
• 电商大促：用 Pulsar 的高吞吐能力承接秒杀流量洪峰，支持流量削峰填谷和弹性扩缩容。

这些案例未必每个都出现在本次议程里，但“创新实践”这个主题下，类似的故事是大概率会被讲到的。看这些案例的时候，我建议大家多关注他们做技术选型时的对比过程，而不只是最后的架构图。选型对比里藏着的信息量最大：他们考虑了哪些备选方案、用什么样的流量模型做的压测、最后被什么因素一锤定音，这些才是值得带回家的东西。

4. 消息中间件选型：Pulsar 适合你的场景吗

4.1 用决策矩阵做理性的技术选型

每次社区里有人问“Pulsar 和 Kafka 选哪个”，评论区都会吵成一锅粥。实际上选型根本不应该是站队题，而是基于业务场景的取舍题。我根据自己的实践经验，整理了一张决策参考表，可以作为评估时的起点：

这表不是标准答案，只是一个思考框架。你自己评估时，要把真实业务的流量模型、消息大小、消费行为、SLA 要求都列出来逐项打分，而不是拍脑袋。

4.2 团队能力与运维成本的现实考量

除了技术特性，选型时还有一个经常被低估的因素：团队的学习和运维成本。

Pulsar 的架构更复杂，它的概念分层（Topic、Subscription、Ledger、Segment、Cursor）比 Kafka 的 Topic/Partition/Consumer Group 要多一个维度，初期理解成本明显更高。如果你的团队之前没有 BookKeeper 或者其他分布式存储系统的运维经验，上线 Pulsar 后第一二三周大概率会被各种段位和限流参数折磨。

但反过来说，一旦团队啃下了这个概念体系，Pulsar 带来的长期红利是明确的：存储和计算分离让扩容从“搬数据”变成“加机器”，多租户能力让一个集群服务多个业务线成为可能，运营成本在中长期反而会更可控。

在这个问题上我见过的反面教材是：一个团队因为 Pulsar 热度高就上了，但没有提前储备调优知识，也没参加 community 的活动，结果集群出问题时只能去翻 GitHub issue 和社群求助。所以我特别强调：如果你打算认真评估甚至落地 Pulsar，像 Pulsar Developer Day 这类高密度活动，一定要当成一次团队技术投资来对待。

4.3 从 Pulsar 的特性反推适用业务场景

Pulsar 的设计目标决定了它有特定擅长和不太擅长的部分。从我接触过的落地案例来看，下面这些业务场景和 Pulsar 的契合度较高：

• 消息量增长预期不明确、需要频繁扩容的场景。存算分离让扩容操作不至于伤筋动骨。
• 数据需要多业务线共享，且要彼此做配额限制的场景。多租户能力比“每个业务线一套 Kafka”省大量机器。
• 对消息回溯和数据保留有中长周期需求的场景。分层存储的成本优势在这里体现得淋漓尽致。
• 已经有公有云对象存储资源、希望通过分层存储降低总拥有成本的场景。S3/GCS 接入是开箱即用的。

而如果你只是希望在一个几十台机器的小集群里做简单的消息通知，那 Pulsar 的复杂度确实有点杀鸡用牛刀，Kafka 或者更轻量的 RabbitMQ 可能是更务实的选择。技术选型不一定要选最热的，要选最合适的。

5. Pulsar 生产落地的实操要点与坑位复盘

5.1 集群部署前的容量估算方法

生产环境部署 Pulsar，第一步不是写 yaml，而是做容量估算。Pulsar 社区推荐的粗估方式是：首先根据峰值消息吞吐计算 Broker 数量，其次根据消息保留量和副本数估算 BookKeeper 节点的存储和 IO 需求。

用一个实际例子走一遍流程，假设业务峰值是每秒 50 万条消息，每条消息大小平均 2 KB：

• 峰值吞吐带宽 = 500,000 × 2 KB ≈ 1 GB/s
• 单台 Broker 的实测吞吐能力，即使中端配置，通常在 300～500 MB/s 以上，两到三台 Broker 就能满足吞吐要求，还需要再考虑故障冗余，建议 4 台起步。
• 磁盘存储：假设保留 7 天数据，加上 BookKeeper 默认 2 副本（可配置 3 副本），预留写放大系数，所需存储容量 = 500,000 × 2 KB × 86,400 秒 × 7 天 × 副本数 / 压缩系数，结果在几百 TB 级别。
• 这些存储容量如果全放在 BookKeeper 节点本地磁盘，硬件成本相当高。所以生产环境强烈建议启用分层存储，把超过两三天的数据卸载到对象存储，本地磁盘只承担热数据的读写压力。

这个粗略估算说明一个核心思想：Pulsar 部署的成本大头不在 Broker，而在 BookKeeper 的存储规划，这也是 Pulsar 项目一直都在强调分层存储在成本控制中关键作用的原因。

注意：上面这组数字是方便理解思路的估算示例，不是放之四海皆准的标准答案。不同版本的 Pulsar、不同的消息大小、不同磁盘类型，实际数字差异会很大。做正式规划之前，一定要用自己业务的流量模型做压测验证。

5.2 消费模型中流量控制和背压机制解读

我在接触 Pulsar 使用者时发现，很多人对它的“消息接收模式”理解不透，导致消费端程序写出来性能很差。Pulsar 消费者有两种基本的 receivetype：

• Shared（共享订阅）：消息在多个消费者之间轮询分发，适合并行处理的场景，吞吐高，但消息顺序无法保证。
• Exclusive（独占订阅）：一个订阅下只有一个消费者能拿到消息，顺序有保证，但并行度受限。

实际业务里，很多人希望既能并行消费又保持顺序，其实可以通过 key_shared 订阅模式，按消息的 key 来做哈希分发，让同一个 key 的消息始终落在同一个消费者上。这个做法的适用场景很广，比如订单事件按 orderId 分区、用户行为数据按 userId 分区，既保了局部顺序，又能打满并行度。

另一个容易踩坑的地方是消费端没有合理地设置 receiver queue size。这个参数决定了消费者本地最多缓存多少条消息。设太大，客户端内存压力增大，而且如果处理逻辑出错会产生大量消息堆积在本地；设太小，又会导致频繁向 Broker 拉消息，增加 RPC 开销。常见的调法是先按单条消息处理耗时为基准估算，再通过压测调整，找到吞吐和延迟的平衡点。

5.3 常见故障的排查与恢复流程实录

我把自己和几个朋友在生产环境里实际碰到过的问题做一个汇总，这些问题在 Pulsar 的使用者群里也属于高频问题：

这个表里我想强调两个通用性的经验：第一，Pulsar 的故障排查，大部分到最后都会落到两个层面——要么是 Broker 层的 Java 堆和线程模型问题，要么是 BookKeeper 层的磁盘和网络 IO 问题，所以监控体系一定要把这两层分开采集数据；第二，生产环境一定要提前演练故障恢复，尤其是 BookKeeper 节点宕机时的自动恢复流程，不要等到真正出事了再来查文档，那是拿线上稳定性开玩笑。

6. 开发者大会的正确参与姿势

6.1 会前准备：带着问题去，比带着笔记回来更重要

很多人参加技术大会回来，笔记记得满满当当，但问起来收获也就是“了解了一些新东西”。问题在于他们没有带着明确问题去参会。我的习惯是，大会开始前一周，把当前工作中最棘手的三到五个技术问题列出来，写在手机备忘录里。

比如你正在用 Pulsar 但觉得消费延迟偏高，那就带着“receiver queue size 和订阅模式对消费延迟的影响”这个问题去。现场听演讲时，你的大脑会自动筛出相关内容；Q&A 环节你也能问出有质量的问题；会后你甚至可以顺着演讲者和这些问题，直接建立起联系。一次大会如果能在核心问题上得到一个从模糊到清晰的答案，就值回票价了。

6.2 现场实操：主题演讲、闪电分享和深度交流怎么平衡

Pulsar Developer Day 这类活动通常由主题演讲和分论坛组成。主题演讲是让你建立整体认知框架的，关注重点应该放在系统设计思路的演变和未来路线图上；而上半场结束后的深度交流互动环节，价值往往比正式议程还高。

以前我在一个大会的分论坛结束后，因为一个问题跟旁边的工程师聊起来，发现他们在用 Pulsar 做了很冷门但有意思的用法——把事务消息配合分层存储做了一个跨系统的最终一致性数据对账平台。后来我们交换了联系方式，回去之后又从那次聊天里延伸出了好几个新想法。这种“散场后的碰巧对话”，才是线下参会真正无可替代的部分。

如果你日程允许，优先去听那些讲生产落地和故障案例的分享。这类内容通常信息密度最高，因为演讲者是用自己的真实经历换来的经验，其中包含的大量细节，在官方文档和技术博客里是看不到的。我自己做技术选型前，就很喜欢找这种“失败案例分享”，因为知道别人在什么场景怎么做失败了，比自己踩一遍坑高效得多。

6.3 会后沉淀：把灵感变成行动项

会议上听到的内容，如果 48 小时内不整理、不落地，基本就是白听了。我的个人做法是：会后当晚会花一两个小时做三件事。

第一，把当天的演讲笔记里所有提到官方文档中没见过的工具、参数、项目名，统一记到一个专门的文档里，后面逐个搜资料查证。第二，挑出一个跟当前工作最契合的内容点子，写成一份一页纸的小方案，发给团队或直接拉一个小型讨论会。第三，把会上认识的人按“后续可能合作交流”这个标准做一个简单标签，写清楚是在什么语境下认识的，这样下次联系不会尴尬。

这些动作坚持下来，你会发现参加一次高质量开发者活动产生的能量，比你闷头看两个月技术资料还要大。

7. 我对消息中间件创新实践的一点个人判断

近两年消息领域的产品有两个很明显的变化趋势：一个是消息系统自己在往存储方向延伸，像 Pulsar 的分层存储、Kafka 的 Tiered Storage，都在把“不删数据”变成一种成本上可接受的默认选项；另一个是消息系统在处理能力上越做越重，希望覆盖越来越多的流计算场景，比如 Pulsar Functions、Kafka Streams。

Pulsar Developer Day 在 COSCon'25 上作为同场活动出现，本身也说明了开源社区对“消息中间件创新实践”的关注正在升温。对于从业者来说，这既是一个技术趋势的风向标，也是一次观察 Apache 顶级项目如何从小众走向主流的机会。

最后分享一个我个人的体会：不管大会现场多热闹，真正决定你技术路径走不走得通的，永远是能不能在自己的业务土壤里，把技术特性转化为可度量的业务价值。消息中间件只是工具箱里的一件工具，搞清楚它为什么这么设计、擅长什么、不擅长什么，才能在合适的场景里把它用出优势。希望你在读完这篇文章后，能对 Pulsar 以及消息中间件领域的核心问题有一个系统性的理解，也期待在会场上听到你带来的实践故事。