姜小邑COSCon’25 的同场活动里，Pulsar Developer Day 的议程海报刚放出来，好些群里就开始转发了。有人说“终于有专门聊消息中间件的场子了”，也有人问“跟主会场的大会报告到底有什么区别”。我的看法比较实在：消息中间件这个领域，光靠 keynote 其实听不出什么水分，真要判断今年社区在解决什么问题、各家又在往哪个方向使劲，得看开发者日这类小规模、强互动的议程安排。这篇文章我就按已经公开的议程方向，结合我自己在 Pulsar 生产环境里踩过的坑，聊聊今年有哪些值得关注的点，也顺便说说如果你准备去现场，最该带着什么问题进场。
1. 为什么 Pulsar 要单独做一个“开发者日”，而不是挤在主会场讲完就走
1.1 开发者日和普通议题的本质区别：从“秀成果”变成“抠细节”
一般开源大会的消息中间件演讲，往往停留在“我们用了 XX，性能提升 XX%”这种层面，PPT 翻得快，真正关键的配置、参数、异常场景处理基本不会展开。开发者日不一样，它的核心逻辑是把话筒交给真正写代码、做运维、背故障的人，一场分享四十分钟，后面可能还留了二十分钟问答，很多时候问答环节比演讲本身还有价值。
COSCon 本来就是一个偏开源社区氛围的会议，把 Pulsar Developer Day 放到同场来做，其实挺符合消息中间件社区目前的交流习惯。Apache Pulsar 本身的架构相比传统消息队列要复杂一些，Broker、BookKeeper、ZooKeeper（现在也叫 metadata store）三层组件，光理解数据是怎么写进去、怎么读出来、故障时怎么恢复，就需要不少时间。这种复杂度决定了它不适合在高密度的大会场里走马观花，更适合让用户带着自己的业务场景，到小会场里跟维护者和同行做深度碰撞。
1.2 消息中间件正在从“异步解耦工具”变成“实时数据底座”
早些年我们聊消息队列，说来说去就是削峰填谷、系统解耦、异步处理这三板斧。但这两年明显感觉到，消息中间件的定位在变。尤其是实时数仓、数据湖、AI 训练样本管道这些场景起来之后，消息系统已经不只是业务系统之间的“传声筒”，而是整个数据链路的主干道。所有数据先进消息中间件，再由下游按需消费，这种架构越来越普遍。
在这个转变里，Pulsar 有几个特性确实踩在了点上：存算分离的架构使得 Broker 可以横向扩展而不受存储限制；多租户模型天然适合企业内部多个团队共用一套集群；分层存储能让你把热数据留在 BookKeeper、冷数据卸载到对象存储，从而把消息保留时间从“几个小时”拉长到“几十天甚至几个月”。所以今年的 Pulsar Developer Day 议程里，如果看到实时数据管道、AI 场景、分层存储这类关键词，不是巧合，是社区和用户共同催出来的方向。
1.3 从议程方向看今年开发者日的整体定位
从已公开的信息来看，这次议程大体上可以分成几个方向：一是架构与性能，讲 Pulsar 在超大规模Topic场景下怎么调优；二是生态与集成，讲 Pulsar 怎么跟 Flink、Spark、数据湖组件配合；三是实践案例，讲企业从 Kafka 或其他消息系统迁移到 Pulsar 的过程中踩过的坑；四是动手实践，现场带大家跑通一个完整流程。这个结构比较稳健，既照顾了已经在用 Pulsar 的人，也给还在选型阶段的人留了入口。
我自己比较期待的是案例类议题。因为 Pulsar 跟 Kafka 最大的区别，不是某个 benchmark 数据更好看，而是架构理念不同。Kafka 的分区是存储并行和消费并行的唯一单位，Pulsar 则把订阅模型和存储模型拆开了，同一个 Topic 可以用不同订阅模式消费。这种差异，只在真实业务压力下才会暴露出来，光看文档是体会不到的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 议程关键词背后：今年 Pulsar 社区到底在解决什么问题
2.1 超大规模 Topic 和元数据压力，是生产环境绕不过去的坎
用过 Pulsar 的人都知道，它的优势之一是 Topic 数量可以做得很多，不像 Kafka 那样 Topic 一多，分区数上涨，Broker 和磁盘都会亚历山大。但这不代表 Pulsar 不需要管理。Topic 一多，metadata 的读写压力就上来了，尤其是频繁的 Topic 查找、策略变更、订阅重置这些操作，会对元数据服务形成压力。
这次议程专门把“超大规模 Topic 场景”列出来，我猜是社区收到了不少生产用户的反馈。实际运维中我也遇到过类似情况：业务方为了精细化权限管理，一个部门一套命名空间，一个业务一个 Topic，数量轻松上千。表面上看 Pulsar 撑得住，但如果你把 Topic 的 retention、backlog 配额、消息策略都配置得很细，每次策略变更都会产生额外的元数据操作。这时候就需要对一些参数做调整，比如元数据缓存的刷新时间、Broker 对 Topic 查找请求的并发控制等。
这里给个建议，去现场听这类议题前，最好先把自己集群的 Topic 数量和元数据服务负载曲线拉出来看看。如果你发现 ZooKeeper 或 etcd 的 CPU 在业务低峰期也不低，那说明元数据操作可能已经成了隐性瓶颈，这时候听专家讲调优，会有豁然开朗的感觉。
2.2 分层存储为什么持续热门：消息已经不是“用完即走”了
过去我们设置消息保留时间，通常就是 24 小时、72 小时，因为磁盘成本摆在那里。但现在越来越多的场景需要把消息保留更久，目的不是给消费者重放，而是把消息本身当成一种可追溯的数据资产。比如金融场景要留存交易事件，IoT 场景要留存设备上报的原始数据，AI 场景要把历史行为流重新灌给模型训练。
Pulsar 的分层存储机制，本质上是在回答一个问题：当消息积压到几十 TB、几百 TB 时，怎么不让 BookKeeper 的存储成为瓶颈。它通过自动把已经消费过的、达到一定条件的段卸载到对象存储，让老数据还能被消费，但存储成本大幅降低。实践里最常见的做法是把 AWS S3 或其他兼容 S3 的对象存储作为 offloader 的载体，设置阈值之后就不用手工干预了。
这次的议程如果涉及分层存储，我建议重点关注三个参数：managedLedgerOffloadThresholdInBytes、managedLedgerOffloadDeletionLagInMillis，以及读回冷数据时的带宽控制。这三个参数直接决定了数据什么时候被卸载、卸载后元数据什么时候清理、以及读冷数据时会不会把带宽打满。很多新手只设置了阈值，没考虑删除延迟，结果 BookKeeper 上的数据已经卸载了，但 Ledger 元数据还占着空间，问题没有完全解决。
2.3 Pulsar 与 Flink/数据湖的集成，正在成为“实时数据基础设施”的关键拼图
议程里跟生态集成相关的部分，我不太担心 Pulsar 连接器本身的能力，反而更关注它在流批一体架构里的位置。Pulsar 的存储模型天然支持保留消息历史，所以它可以同时扮演 Kafka 那样的实时流入口和类似数据湖的离线数据源。配合 Pulsar Flink Connector，你可以从任意时间点开始消费，不用像 Kafka 那样依赖 offset reset 到最早或最新这种粗粒度策略。
实际用 Flink 消费 Pulsar 时，最常见的困惑是 Source 的并行度怎么设置。Pulsar 的 Topic 可以有很多分区，而 Flink Source 的并行度可以大于分区数，也可以小于分区数。这里建议遵循一个原则：让 Flink 的并行度尽量等于或略大于实际需要的分区数，避免因为分区闲置导致消息延迟。如果 Pulsar 端的 Topic 分区数比较固定，并行度直接对齐分区数通常是最省心的。
还有一个容易踩坑的地方是消费位点提交。Pulsar 的消费者是自动提交还是手动提交，对 Flink 的 Exactly-Once 语义影响很大。如果你用 Flink 做精确一次处理，建议不要依赖 Pulsar 的自动 ack，而是通过 Flink 的 checkpoint 机制，结合 Pulsar 的 Reader 接口或带事务的消费方式来实现。这部分内容在现场应该会有比较多的讨论，值得提前准备几个问题。
2.4 从 Kafka 迁移到 Pulsar：不只是换客户端，而是换一套思考方式
议程里如果有“迁移”相关话题，我猜现场的共鸣度会很高。做消息中间件迁移，最难的技术点往往是双跑和数据一致性。常规做法是先让新老两套系统同时接收消息，消费端先读老的，验证新的没问题后再切流量。但这个过程中，两套系统的消费位点不可能天然对齐，尤其是消息量大的时候，靠消费端自己记录位点很容易出问题。
我自己做过一次从 Kafka 到 Pulsar 的迁移，最大的体会是：不要用 Kafka 的 partition 思维去套 Pulsar 的 subscription。Kafka 里一个 partition 只能被同一个消费组里的一个消费者线程消费，所以你的并发上限在 Topic 设计时就被锁死了。Pulsar 的共享订阅模式允许同一 Topic 被多个消费者同时拉取，而且可以通过 Key_Shared 模式保证相同 key 的消息落到同一个消费者，灵活性高很多。迁移时如果只是简单地把 Kafka 的 Topic 和分区数 1:1 映射到 Pulsar，相当于把新架构的优势浪费了一半。
去现场如果正好遇到有人分享迁移经验，我建议重点问三个问题：消息顺序性是怎么保证的？消费位点不一致时怎么补偿？迁移过程中是否有消息重复，重复是怎么过滤的？这三个问题是所有中间件迁移里最容易翻车的点。
3. 如果你是刚接触 Pulsar，带着这些问题去现场收获最大
3.1 先确认自己的场景属于哪种消息模型：队列、流、还是两者都要
很多刚到 Pulsar 社区的新手，第一个问题就是“Pulsar 和 Kafka 到底选哪个”。这个问题其实很难直接回答，因为你得先弄清楚自己的业务需要的是队列模型还是流模型。
如果你的需求是“一条消息发给一个消费者”，比如订单创建后通知库存系统扣减，典型的 Worker Queue 模型，那 Pulsar 的共享订阅正好合适。
如果你的需求是“一条消息按顺序发给所有关心它的人”，比如数据库变更事件广播给多个下游同步，那 Pulsar 相当于把 Topic 当成一个流，每个订阅方维护自己的消费位点，互不影响。
如果你两个都要，那消息中间件里能在一套架构上同时满足这两种模型的确实不多，Pulsar 算一个。
现场听分享的时候，别只盯着人家用了什么组件，多问一句“你们消息模型是什么样的”。因为很多案例看起来是在讲 Pulsar，实际本质是在讲特定模型下的最佳实践。
3.2 在现场动手环节，建议把 Pulsar 的订阅模型亲手验证一遍
如果这次开发者日有动手实验环节，强烈建议你自己写一个小 demo，把四种订阅模式都跑一遍：独占订阅、共享订阅、故障转移订阅、Key_Shared 订阅。只有亲手跑过，你才会直观感受到它们之间的差别。
比如独占订阅，适合对顺序要求极高、且只能单消费者处理的场景。故障转移订阅在主消费者挂掉后，备份消费者会接管，但这个切换过程通常有秒级延迟。共享订阅是吞吐优先，任何消费者都可以拿任何一条消息，适合对顺序不敏感的场景。Key_Shared 订阅则是根据消息 key 做 hash，保证相同 key 的消息一定被同一个消费者处理，这是很多业务系统最喜欢用的模式，但使用时要注意生产者必须给消息设置 key，否则 Key_Shared 退化成共享订阅，顺序性就没了。
这个小细节非常容易踩坑。我在生产环境里就遇到过，开发说消息顺序不对，查了半天才发现是部分历史消息没带 key。
3.3 现场要学会问“参数为什么这么调”，而不是只记结论
消息中间件的调优没有银弹，同样的参数在不同集群规模、不同消息大小、不同消费速度下，最优值差很远。所以现场听别人讲调优，最好的方式是追问“你们当时是怎么判断要调这个参数的”。
比如很多人喜欢调大 consumer 的接收队列大小，觉得这样能提升消费吞吐。但在 Pulsar 里，receiverQueueSize 调太大，会导致消息提前推给客户端，如果消费端处理速度跟不上，内存里的消息越积越多，反而造成 GC 压力甚至 OOM。与其无脑调大，不如先看消息的平均大小和消费处理耗时。
举一个比较量化的例子：如果单条消息处理耗时 50ms，单线程消费吞吐大概是 20 条/秒，想要达到 1000 条/秒，至少需要 50 个并发消费者，这个并发可以通过 Pulsar 的共享订阅来横向扩展。但如果你的 receiverQueueSize 默认是 1000，那每个消费者本地可能堆积上千条消息，一旦处理逻辑抛异常反复重试，情况会很难看。这种时候，你需要把 queue 大小调到和你的处理能力匹配，而不是一味追求大。
4. 回到实际项目，我整理了一份 Pulsar 落地的自查清单
4.1 Topic 与命名空间规划：一开始就做对，后面少熬夜
无论你是否去现场，消息中间件的使用规范都值得提前定好。我给自己团队定过几条特别管用的规则：
- 命名空间按业务域划分，不同域之间用策略隔离，从根上避免互相影响。
- Topic 命名统一用“域名-业务-事件类型”格式，例如 order-domain-order-created，这样在监控平台上一眼就能看出哪个环节出问题。
- 每个命名空间设置明确的 backlog 配额，超过阈值直接触发告警，而不是等磁盘满了才发现。
多租户是 Pulsar 特别强的一个特性，但很多时候没有在初期被利用好。很多团队不管三七二十一，把几百个 Topic 全部塞在默认的 public 租户里，权限没法分、配额没法隔离，等于把多租户的优势白白扔掉了。
4.2 消息保留策略，按数据价值分三层来设
不要所有 Topic 用同一套保留策略。我自己习惯把数据分成三类：
- 临时消息：消费完即删，retention 设为 0，适用于内部异步请求。
- 短期回溯消息：保留 2 到 7 天，适用于需要排查问题、重放数据的核心业务链路。
- 长期归档消息：开启分层存储，数据卸载到对象存储，保留 30 天甚至更长，适用于审计、账单、行为分析等场景。
这样做的好处很明显，BookKeeper 的存储压力主要来自第二类数据，第一类和第三类都不会对实时存储造成太多负担。如果你还不清楚怎么判断哪些 Topic 是“临时消息”，可以从消息的消费方数量和业务价值来判断：如果一个 Topic 只有一个消费者，且消费完不需要再看历史，那它就是临时消息。
4.3 消费端要设置合理的 Ack 超时和重试策略
消费端 Ack 超时是另一个高频踩坑点。在共享订阅模式下，如果消费者拿到消息后处理时间超过了 Ack 超时时间，Pulsar 会认为消费失败，把消息重新投递给其他消费者。如果业务逻辑本身处理时长波动大，比如有时候 3 秒、有时候 30 秒，但 Ack 超时设的是 10 秒，你就会看到大量消息被重复消费。
这里有几种应对方案：
- 如果你用 Pulsar 的 consumer，可以把 ackTimeout 设成一个足够大的值，例如正常耗时的 5 倍以上，但也要为真正卡死的消费留出重投递空间。
- 更推荐使用 Cumulative Ack 或 Negative Ack，对单条失败做精准重试，而不是等超时。
- 在 Pulsar 客户端里，RedeliveryBackoff 参数可以控制重投递的退避时间，避免失败消息在多个消费者之间疯狂横跳。
我在现场如果遇到用户分享，一定也会问他们在消费失败重试上是怎么做的。因为这一块设计得好不好，直接决定了故障时消息会不会成倍放大。
4.4 监控与告警：必须覆盖的消息指标清单
引入 Pulsar 之后，监控体系也要跟着升级。除了常规的 CPU、内存、磁盘，核心要盯 Pulsar 自己的几个指标：
- 消费积压：通过 backlog 大小判断下游是不是堵住了。
- Broker 线程池状态：是否出现长时间的线程饥饿。
- BookKeeper 写入延迟：P99 延迟如果突然飙升，多半是磁盘或网络出了问题。
- Topic 数量增长曲线：如果业务方频繁创建 Topic，会导致元数据压力上涨，需要及时治理。
名称 | 指标含义 | 建议告警阈值
Backlog | 尚未被消费的消息积压量 | 超过 10 万条或持续 10 分钟增长
BookKeeper 写入延迟 | Ledger 写入 RTT | P99 超过 100ms
消费端 Ack 超时次数 | 发生消息重投递的频率 | 每分钟超过 100 次需要检查
Broker 线程池活跃数 | 判断 Broker 是否繁忙 | 持续超过 80% 需要扩容
这张表很简单，但真出事的时候能救命。很多团队直到消费积压把磁盘打满才看到问题，就是因为没把 backlog 的告警当回事。
5. 常见问题与排查思路：这些坑我基本都在生产环境里遇到过
5.1 消费积压一直降不下去，是下游处理慢还是 Pulsar 投递有问题
遇到积压，第一反应不应该是先加消费者。我会先看积压是不是集中在某个分区上，如果所有分区都积压，大概率是下游处理能力不足；如果只有部分分区积压，就要检查是不是消息 key 分布不均匀导致 Key_Shared 模式下消息都堵在少数消费者上。
还有一次我们遇到非常诡异的现象，消费端日志显示消息明明拉到了，但是 ack 一直没有提交成功。后来排查发现是消费端在做批量处理，一批消息里只要有一条失败，整批都不提交，结果这一批消息一直被重复拉取，积压数字当然降不下去。解决办法是把批量提交改成逐条提交，并单独处理失败消息。
5.2 Broker 频繁 Full GC，消息延迟升高
Pulsar 的 Broker 需要处理大量内存中的消息，如果某个 Topic 的消息体积特别大，单条消息 10MB 的那种，很容易把堆内存打满。除了提醒业务方别把大对象塞消息体外，还可以调整 Broker 的消息分配策略，适当限制单条消息的大小。
在支持大消息的场景里，我建议做成“消息里只放引用和元数据，真正的文件内容走对象存储，下游通过链接去取”的架构。这样消息队列始终只处理轻量事件，吞吐和延迟都能保持稳定，并且让大文件没法对 broker 造成压力。这个习惯越早养成越好。
5.3 写入 Pulsar 的消息延迟偶发飙高，怎么定位是不是 BookKeeper 的问题
如果你发现生产端到消费端的整体延迟偶发性很高，先确认是生产写入慢还是消费拉取慢，具体要从客户端指标来看。最简单的方式是在生产端记录 sendAsync 回调的时间，消费端记录 receive 的时间，把两个时间差拉出来，基本能定位到延迟落在哪一段。
如果确认延迟主要在写入端，很大概率是 BookKeeper 的写入没有达到预期。常见原因是磁盘 IO 被其他业务抢占，特别是用了机械盘或者云上共享型磁盘时更明显。Pulsar 对磁盘延迟比较敏感，建议 BookKeeper 的 Journal 盘和数据盘分开，并且优先使用 SSD 或 NVMe 云盘，不要为了省钱把 Pulsar 和别的数据库混在同一块盘上。
5.4 消息重复到底能不能避免：有些场景能，有些场景只能靠幂等兜底
消息不重复是一个很难绝对保证的事情。网络超时、客户端重试、Ack 丢失，都会导致消息被重复投递。我在生产环境里对业务方的要求是：能靠幂等兜底的就不要纠结消息系统层面是否严格不重复，先把业务处理的幂等做好。
比较常见的幂等方案有两种：一是唯一键去重，消费端在数据库里建唯一索引，重复消息插入时直接冲突跳过；二是用状态判断，比如订单状态只有从“待支付”才能流转到“已支付”，重复的支付消息到了之后发现状态不匹配，直接丢弃。
现场如果有人在台上说自己做到了端到端不重复，可以追问一下他们的事务方案是怎么实现的和是否有性能回退。Pulsar 有事务机制，但事务有额外开销，不是所有场景都值得用。
6. 我的一些参会建议：带着场景去，带着问题回
Pulsar Developer Day 这类活动，最值钱的地方不在台上的 PPT，而是散场后的交流。如果你认真想从这个活动里带走东西，我建议先花半天时间把自己系统的架构图画清楚：哪些链路在用消息、现在有什么痛点、有没有正在评估的新场景。然后带着这张图去现场，听到任何可能是解决方案的内容，就顺着往下问一句“你们这个方案在 XX 场景下适用吗”。
如果团队里还在选型阶段，也可以到现场跟已经落地的团队聊聊 Pulsar 的运营成本。很多人只看了 Pulsar 功能丰富就冲进来，结果被 BookKeeper 的运维复杂度劝退。实际上 Pulsar 更适合有专门中间件团队、且对多租户和分层存储有真实需求的企业。如果只是简单解耦，那老老实实找一个轻量的消息队列或者直接用云上的托管服务就够了，没必要为了一两个高级特性背上整套运维负担。
我在自己的项目里选择 Pulsar，是因为业务确实需要长时间回溯、多租户隔离，以及未来往流式计算扩展的可能。三种需求叠加之后，消息中间件的选型空间其实已经很窄了。比较关键的是，用之前我想好了几个必须验证的点，包括多租户隔离下是否会互相影响，backlog 相当大时老化策略是否能正常触发，以及 broker 滚动升级是否有连接闪断，这些在选型阶段全都压测过一遍，上了生产之后才没有太多惊吓。
最后再分享一个小技巧：如果你打算去现场参加动手环节，记得提前在自己电脑上把 Docker 环境调好，拉一个 standalone 的 Pulsar 镜像跑通最简单的生产消费。现场网络状况你无法控制，把环境提前装好能节省大量时间。真正到现场，把精力花在看他们如何讲解架构设计和问题排查上，那才是这次日程中最值回票价的部分。