深入解析Pulsar MessageId：消息中间件底层逻辑与实战要点

COSCon'25 同场活动 Pulsar Developer Day 倒计时进入第 3 天，朋友圈里已经有不少人在刷话题了。做消息中间件这块的人心里都清楚，Pulsar 这几年的热度不是虚的，尤其是事件驱动架构、云原生数据流、多租户消息平台这些场景，几乎每次技术讨论都会绕到它头上。而这次 Pulsar Developer Day 把“创新实践”四个字放在主题里，说明主办方不想只讲概念，更想聊生产环境里真正跑起来的东西。

今天我就借这个活动倒计时的节点，把消息中间件和 Pulsar 的底层逻辑、实战要点、以及最近很多人问的一个热门问题——messageid|28077:20854:0 到底是怎么来的——一次性说透。不管你是准备去现场交流的开发者，还是正在选型、踩坑、优化消息队列的架构师，这篇文章都能给你一些可以直接拿去用的参考。

1. COSCon'25 与 Pulsar Developer Day：为什么消息中间件值得一场专属活动

1.1 一场开源大会里的技术重头戏

COSCon 是国内开源圈绕不开的年度聚会，每年都会吸引大量开发者、开源项目维护者、技术布道者和企业决策者参加。Pulsar Developer Day 作为同场活动，单独拿出来做一整天，本身就是一个信号：消息中间件已经从“后端组件”变成了“业务架构的核心底座”。

我在和一些同行交流时明显感觉到，今年大家的关注点不再是“要不要上消息队列”，而是“消息队列选哪个、怎么把性能压出来、遇到坑怎么解”。Kafka 统治了大数据管道很多年，但 Pulsar 以存算分离、多租户、跨地域复制这些特性，在云原生时代抢到了非常大的话语权。这场活动聚焦 Pulsar 创新实践，本质上回应的是这个趋势。

1.2 这场活动适合谁

如果你是后端开发者，想搞懂消息中间件的运行机制，Pulsar Developer Day 的分享内容会比单纯看文档直观得多；如果你是架构师或技术负责人，正在评估消息平台选型，现场听到的案例和踩坑记录会比选型报告更有说服力；如果你已经在用 Pulsar，那更值得去，因为开发者日这类活动通常会聊到版本特性、性能调优、社区路线图，这些信息很难在公开文档里找到。

即便你没有报名线下，只是路过刷到相关话题，我也建议你把 Pulsar 的原理和最佳实践系统性过一遍。消息中间件的知识涨起来之后，对整个分布式系统的理解都会更扎实。

2. 选型真相：Pulsar 为什么能在中间件混战中站稳脚跟

2.1 主流消息中间件横向对比

很多人第一次接触消息中间件时，面对 Kafka、RabbitMQ、RocketMQ、Pulsar 很容易晕。我的看法是，没有绝对的好坏，只有适不适合场景。下面这张表是我在实际项目中总结的对照，可以帮你快速找到切入点。

2.2 分层架构带来的直接收益

Pulsar 最核心的设计理念是计算与存储分离。传统消息队列如 Kafka，broker 节点既要处理客户端请求，又要把数据落到本地磁盘，两者强耦合。Pulsar 则把存储抽离到了 Apache BookKeeper，broker 变成无状态的计算层，这带来的一个直观好处是：扩容时你不需要再担心“数据迁移导致的流量高峰”，存算分离让扩容变得像加服务实例一样简单。

更重要的是，这种架构让 Topic 数量不再受限于集群总磁盘和单节点性能。Kafka 社区一直建议控制分区数，因为分区多了 leader 选举、文件句柄、内存占用都会飙升。Pulsar 因为数据在 BookKeeper 的分片（Ledger）里，每个 Topic 可以拆成很多小分段，broker 节点之间几乎不需要复制数据，所以支撑百万级 Topic 不是口号，是真实能力。做 IoT、大数据平台、高并发业务系统的团队，往往就是因为这一点才迁到 Pulsar。

3. 从 messageid|28077:20854:0 看 Pulsar 的底层逻辑

3.1 拆解 MessageId 的每一段含义

先直接回答热搜里那个问题：为什么在 Pulsar 客户端里打印出来的 MessageId 是 messageid|28077:20854:0 这种样子，而不像一个普通的自增数字？因为 Pulsar 的消息寻址方式本来就不同于 Kafka 的分区内偏移量，它把一条消息的位置抽象成“三重坐标”。

• 28077，是 Ledger ID。Ledger 是 BookKeeper 里的一段数据日志，对应一个有序、可追加写入的数据分段。Pulsar 会不断创建新 Ledger，旧 Ledger 写满或达到滚动条件后会被关闭。
• 20854，是 Entry ID。Entry 是 Ledger 内部的一条记录，在 Pulsar 里一条 Entry 通常就对应一条消息（或一批消息）。
• 0，是 Partition Index 或 Batch Index。如果当前 Topic 是分区 Topic，这段通常表示分区序号；如果消息是批量发送的，这个位置还可能表示消息在批次内的下标。

所以 messageid|28077:20854:0 可以翻译成：这条消息位于第 28077 个 Ledger 的第 20854 个 Entry 中，分区或批次内偏移是 0。听起来是不是有点像书的“第几卷、第几页、第几行”？这种设计能让消息在分布式存储中精确定位，不用扫描整个文件。

3.2 为什么不能设计成一个简单的 offset

很多熟悉 Kafka 的人会问，Kafka 直接用一个递增 offset 不也挺好用吗，Pulsar 为什么要搞得这么复杂？关键原因在于存储模型的不同。

Kafka 的 partition offset 是单一分区的逻辑序号，消费组提交消费位点，本质上是“记住读到第几条”。这种模型在分区内是高效直接的，但一旦涉及数据在集群内重新分布、分区迁移、扩容缩容，offset 就会变得很脆弱，需要依赖外部协调机制。

Pulsar 的底层存储是分段的 Ledger，Leder 会被滚动、会被删除、会被自动关闭，也可能因为容量变化重新分布。如果用单纯的递增序号，消息在物理存储上的位置就无法通过序号推导出来，尤其是消息回溯、按时间查询、跨地域复制这些场景都会变得很麻烦。Ledger+Entry 的结构能天然支持“定位到某一段存储中的某一条记录”，这正是存算分离架构下更自然的消息寻址方式。

3.3 日常开发中 MessageId 高频出现的三个场景

场景一：消费位点提交。JAVA 客户端里 message.getMessageId() 返回的对象，可以直接传给 consumer.acknowledge()。很多人误以为 MessageId 只是给人看的字符串，其实它的序列化形式存在于消费位点里，broker 靠它判断消费到哪了。

场景二：消息回溯。Pulsar 支持通过 MessageId 指定从某条消息之后开始消费。你可以先拿一条历史消息的 MessageId 存起来，之后需要重放时用 consumer.seek(messageId)，等于把消费位点“拉回”到某一个精确位置。这一点在修复数据、补算指标时非常有用。

场景三：位点仲裁或边缘情况排查。线上 Kafka 排查时，我们习惯问“消费到哪个 offset 了”，Pulsar 里就要问“你当前的 MessageId 是多少”。如果你能看到 Ledger ID 和 Entry ID 的增速，甚至可以快速判断消息生产是否有积压、对应 Ledger 写入是否正常。

4. 消息中间件落地实操：配置、调优与避坑经验

4.1 生产环境核心配置要点

Pulsar 的参数非常多，但并不是所有参数都要一开始就调。我在实际项目中总结出几个优先级最高的点，在活动上听到的技术分享也基本围绕这些。

• ack 超时时间。Pulsar 的消费者在处理消息后需要返回 ack，如果 ackTimeout 设置过短，消费者处理慢一点，broker 就会重新投递消息，导致重复消费。设置时长建议是业务处理时间的 2 到 3 倍，且要保留一定余量。
• 消息保留策略（retention）。Pulsar 默认消费完成后会清理数据，如果业务需要回溯或重新消费，一定要提前设置 retention。按时间还是按大小保留，取决于你的存储成本和数据重要性。
• 订阅模式的选型。Exclusive、Shared、Key_Shared 和 Failover 四种模式，处理逻辑完全不同。顺序要求极高的场景千万不要用 Shared，否则需要额外做分区排序，这是非常常见的坑。
• BookKeeper 磁盘和 JVM 配置。很多 Pulsar 集群不稳定不是因为 Pulsar 本身有问题，而是 BookKeeper 的磁盘 IO 不够或者 JVM 内存设置不合理。BK 节点要保证足够的 journal 磁盘性能，最好用 SSD。

4.2 客户端使用中的三个细节

第一个细节是 Producer 的批量发送参数。批量发送能显著提升吞吐，但也会增加延迟。如果业务对延迟敏感，应该调小 batchingMaxMessages 或 batchingMaxPublishDelay；如果追求吞吐，可以适当调大。这个平衡点需要压测，没有统一答案。

第二个细节是消费者预取数量。receiverQueueSize 决定消费者本地缓存多少条消息。调大可以减少网络往返，但也会导致消息在本地积压，如果处理到一半应用崩溃，部分未 ack 的消息会被重新投递，重复数量变多。建议默认值起步，再结合业务情况调整。

第三个细节是消息 key 的使用。Pulsar 的 Key_Shared 订阅会根据 key 把消息路由到固定消费者，但前提是写入消息时要指定 key。很多人忘了设置 key，结果 Key_Shared 订阅退化成 Shared，顺序完全无法保证，排查起来特别隐蔽。

4.3 从实际问题反推优化方向

如果发现消费速率上不去，先别急着加消费者。用 Pulsar Admin 或监控面板看一下 topic 的 backlog 和消费速率，然后把问题分成两类：如果消费者的 CPU 和内存都不高，大概率是 receiverQueueSize 太小或者消费逻辑里有串行阻塞；如果消费者负载已经很高，就要看代码里的处理逻辑是否能并行化，或者考虑增加分区数和消费者数量。

如果出现大量重复消费，第一步不是改代码，而是查 ack 超时和消费者的“处理时间”。我遇到过不少情况是 ack 超时时间设置成了 10 秒，但业务处理要 30 秒，系统必然重复投递。调这个参数的优先级，永远高于在代码里做幂等。当然，幂等也必须有，这是兜底方案，但源头问题也要解决。

5. 参与 Pulsar Developer Day 的实用准备

5.1 参会前建议准备的问题清单

如果你准备去现场，我建议你不要空着手去。带几个具体问题，收获会大得多。

• 先问自己：我现在用的是哪些消息中间件，最痛的点是什么？是吞吐不够、运维复杂、还是消息乱序？
• 再问技术：Pulsar 的跨地域复制在容灾场景下的 RPO/RTO 实际能达到多少？BookKeeper 节点故障时，对读写的影响窗口有多大？
• 最后问业务：如果要把现有 Kafka/RabbitMQ 迁移到 Pulsar，消费位点映射和数据双写方案怎么做？这些内容通常是社区分享里最有价值的部分。

5.2 现场交流如何获取最大价值

开发者日这种活动，最大的价值不是坐在台下听演讲，而是茶歇和圆桌环节的技术碰撞。我自己的经验是，提前十分钟到场，先和旁边的开发者聊两句，你往往会发现对方的场景和你高度相似。

在现场提问时，尽量拿自己的真实数据说话。比如“我们集群 5 个 broker，Topic 数量 2 万，延迟偶尔飙到 200ms，怎么定位”就比“Pulsar 性能怎么样”更容易得到有效的回答。遇到社区维护者时，还可以问一下新版本里有哪些预期特性，这会比看 Release Notes 提前掌握方向。

6. 高频问题速查与实战记忆点

6.1 我就遇到过这些问题

6.2 经验沉淀

消息中间件的坑和数据库的坑有一个共性：大部分问题不是框架本身的问题，而是使用姿势不对。Pulsar 的 MessageId 之所以引起大家好奇，我觉得也有这个原因——当你理解了它的结构，其实就理解了整个 Pulsar 的存储模型，后面遇到报错、排查问题都会顺手很多。

我个人的一个习惯是，在项目里打印日志时把 MessageId 完整打出来，不要只打一部分。因为排查问题时，完整的 MessageId 能直接定位到 Ledger 和 Entry，配合 broker 日志，很快就能缩小问题范围。保存消费位点时，也要用 MessageId 的序列化形式，不要自己拼字符串。

另外，每次升级 Pulsar 客户端和服务端版本前，我都会在测试环境先跑一轮消费回溯和 failover 演练，确认位点兼容性。这类中间件的版本升级比业务系统升级更容易踩坑，尤其是跨大版本，提前验证能省下大量线上救火时间。

这次 Pulsar Developer Day 倒计时 3 天，如果你还没决定去不去，我的建议是：去。技术分享的价值不只在于听完后的顿悟，更在于它帮你把已经很模糊的经验重新梳理清晰。哪怕你只是被 messageid 这个热搜吸引过来的，弄懂它的原理，回去再翻一遍项目代码，你都会看到一些之前忽略掉的细节。