从Pulsar Developer Day看消息中间件选型与架构演进

COSCon‘25同场活动 Pulsar Developer Day 还有 3 天就要开了，群里已经有人在讨论了。作为经常跟消息中间件打交道的人，我对这场活动的兴趣点其实不在“开发者日”这种形式，而是想看看 Pulsar 这次能拿出什么新东西。毕竟这几年消息队列领域卷得厉害，Kafka、RocketMQ、Pulsar 各有各的基本盘，能面对面聊实践的机会确实不多。

这篇文章不想写成活动议程复读机，我更想借着 Pulsar Developer Day 这个话题，把消息中间件从选型到落地、从原理到踩坑的完整链路梳理一遍。无论你是准备入场的小白，还是已经在生产环境里被消息队列折磨过的老手，这篇内容应该都能给你一些参考。

1. COSCon‘25 与 Pulsar Developer Day：一场活动背后的生态信号

1.1 为什么 Pulsar 值得单独办一场开发者日

先聊聊 Pulsar Developer Day 本身。在开源社区里，能给某个项目单独办开发者日的并不多，Kafka 算一个，Pulsar 现在也算一个。这种同场活动的价值不只是多几个演讲，而是背后有一套完整的生态逻辑。

Apache Pulsar 这些年能持续升温，核心在于它抓住了传统消息中间件的两个痛点：存储与计算耦合太深、多租户隔离能力弱。Pulsar 把存储层剥离出来，用 Apache BookKeeper 做底层存储，Broker 只负责计算和路由，这样一来扩缩容变得更加灵活。这种架构上的差异，让它在云原生场景下天然比 Kafka 更有弹性和可运维性。

从活动议程来看，Pulsar Developer Day 的内容通常聚焦在架构深入、性能调优、最佳实践这几块。对于开发者来说，这些内容比单纯的项目介绍有价值得多，因为消息中间件这种基础设施，真正决定成败的往往不是选型本身，而是落地后怎么调、怎么排查问题、怎么在极端场景下保证可用性。

1.2 消息中间件领域的生态竞争格局

现在消息中间件赛道大概分这么几个流派：Kafka 凭借流处理和生态整合能力占据大数据领域主流地位，RocketMQ 在电商、交易链路中沉淀了大量实践，RabbitMQ 凭借轻量灵活在小团队和中小场景中普及率极高，而 Pulsar 则靠云原生架构和多租户能力切入了另一块市场。

我自己的感受是，选消息中间件不能只看性能测试报告，要看你的团队运维能力能不能覆盖它的复杂度。Kafka 部署简单但调优和运维门槛不低，RocketMQ 功能丰富但社区资料相对分散，Pulsar 架构先进但现在生产环境的一线经验相比 Kafka 还有差距。这次 Pulsar Developer Day 如果能多分享一些实际运维中的问题，价值会比某个组件又出了新特性更大。

1.3 谁能从这场活动中真正获益

从参与者的角度倒推，三类人最适合关注这场活动。第一类是架构决策者，他们做中间件选型时需要了解 Pulsar 的真实边界在哪里，哪些场景能上、哪些场景要谨慎。第二类是平台工程师，他们需要掌握 Pulsar 的调优技巧，比如 BookKeeper 的 Journal 和 Ledger 配置、Broker 的内存水位、租户资源的隔离策略。第三类是业务开发者，他们更关心消息中间件接入的 SDK 使用、消费模型选择、以及实际业务中遇到的堆积、重复消费、顺序保证等常见问题。

这场活动的价值提醒我们，消息中间件早已不是“能用就行”的阶段，而是要在一个长期演进的架构中持续负责。

2. 消息中间件的核心价值：从“系统解耦”到“流量治理”

2.1 为什么系统需要消息队列

聊到 Pulsar Developer Day，必须先说清楚消息中间件在整个技术体系中的位置。很多人第一次接触消息队列，听到最多的理由就是“解耦”“异步”“削峰”，但真正落地的时候会发现，这三个词背后各有各的代价。

解耦是最直接的价值。两个系统之间如果直接通过 HTTP 或 RPC 调用，调用方被响应时间绑死，被调方一旦崩溃，调用方也跟着失败。引入消息队列之后，生产者和消费者不再直接依赖，只要保证消息能发出去，生产者就算达到了最终一致的目标。但代价是链路变长，需要额外维护消息中间件本身的可用性。

异步是提升系统吞吐的关键路径。比如下单后发通知、积分、物流，这些操作如果同步执行，一次请求可能要几百毫秒甚至几秒。改成异步之后，核心链路只做必要操作，其余逻辑放到消息里面慢慢消费，系统响应速度能上一个台阶。但异步也带来一个问题：用户无法立刻感知后续流程的结果，需要额外设计状态追踪和兜底机制。

削峰是消息中间件最有冲击力的使用场景。典型的例子是大促秒杀，瞬时流量可能是平时几百倍，如果直接打到数据库，基本必死。消息队列在前面挡一道，把流量先堆积到队列里，后端按自己的处理能力慢慢消费，保证系统不被打挂。但这需要你提前评估队列的容量和消费者的吞吐上限，否则堆积过多，延迟会变得不可控。

2.2 消息模型选型：点对点、发布订阅还是消费分组

选消息中间件和消息模型本质上是绑定的。Pulsar 在这方面的优势是同时支持队列模型和流模型，一套系统能覆盖两类场景。

队列模型对应的就是点对点模式，一条消息只会被一个消费者消费掉，比如订单支付成功事件只需被订单服务处理一次。流模型对应的是发布订阅模式，一条消息可以被多个订阅者消费，比如用户登录事件既可以进风控系统，又可以进数据仓库做实时分析，还能进推荐系统更新画像。

Pulsar 的消费分组概念做得特别灵活。同一个 Topic 可以挂多个订阅，每个订阅有独立的消费进度，互不干扰。这类似于 Kafka 的 consumer group，但 Pulsar 在订阅模型上更抽象，让同一份数据在不同业务视角下可以被多次消费，不需要像 RabbitMQ 那样靠 Exchange 和 RoutingKey 绕来绕去。

2.3 从使用场景倒推选型逻辑

消息中间件没有所谓“最好”的选择，更没有万能的银弹，只看跟你的场景匹配度。如果你是十几台机器的小团队，核心诉求是快速接入、灵活路由，那 RabbitMQ 的 AMQP 模型和轻量特性可能更合适。如果你在做实时数仓或大规模日志采集，Kafka 的超高吞吐和流处理生态更贴合需求。如果你身处电商或者金融交易链路，RocketMQ 的事务消息和延迟消息能力经过大规模验证，可靠性相对来说值得信赖。如果你的系统要支撑多个业务部门、需要资源共享和严格隔离，那 Pulsar 的存算分离架构和多租户能力值得重点关注。

大会的议题往往能帮你把每种选型的适用边界讲得更清楚，这比看官方文档的 benchmark 更有参考意义。

3. Pulsar 架构深度拆解：为“云原生”而生的消息中间件

3.1 计算与存储分离：Broker 与 BookKeeper 的分工

理解 Pulsar，最关键的一步就是搞懂它和多数组件不同的存算分离设计。传统消息中间件（如 Kafka）的存储和计算是绑定的，每个 Broker 节点既要接收请求、处理 IO，又要管理本地的日志分片。这种设计在小规模下没问题，但规模变大之后，数据不均衡、节点迁移慢、扩容成本高等问题都会暴露出来。

Pulsar 则把 Broker 与存储节点分开：Broker 负责处理和路由，BookKeeper 负责消息落地和持久化。Broker 层是无状态的，可以横向扩展；BookKeeper 层由多台 Bookie 构成，每个消息会被分片写入多个 Bookie 副本，从底层保证了数据的高可用和一致性。

这个架构带来的直接好处是：Broker 可以从数据搬迁、磁盘均衡等脏活中解放出来，资源能更多集中在请求处理上；Node 故障后，新的 Broker 可以立刻接管流量，无需等待数据同步。用一个不太恰当的比喻，传统模式像是每台售货机各带一个仓库，补货得整售货机搬走；Pulsar 相当于把所有货集中到几个大仓库，售货机只负责卖货，哪台机器坏了换一台就能继续营业。

3.2 多租户与资源隔离：大平台场景的必答题

多租户是 Pulsar 比较擅长的一个方向。消息中间件一旦成为公司内部的基础设施，必然面临一个问题：多个业务线共用一套集群，怎么避免某个业务发消息太猛拖垮别人？

Pulsar 的多租户模型给到三个层级：Tenant、Namespace、Topic。Tenant 通常对应一个部门或一个大的业务线，Namespace 可以按业务模块继续拆分，Topic 则是最小粒度的消息通道。每个 Namespace 都可以单独设置存储配额、消息持久化策略、消费权限，甚至可以绑定不同的 Bookie 存储集群，做到物理级别的隔离。

这比 Kafka 只能靠多集群或 Topic 命名规范来粗粒度划分要灵活得多。如果你所在团队正想在中间件层面做租户隔离，Pulsar 的多租户架构是一个非常值得研究的设计，可以说它几乎是为了平台化的角色而生的。

3.3 分层存储：消息 TTL 不再被磁盘容量限制

消息中间件经常遇到一个痛点：消息消费完之后，数据到底留多久？Kafka 的保留策略受限于 Broker 磁盘，如果想保留几天甚至更久，成本会很高。Pulsar 引入了分层存储的概念，冷数据可以自动从 BookKeeper 卸载到 S3 等对象存储中。

这个设计的价值在于：不再需要为了“万一以后要用”而一直保留热数据。Pulsar 允许设置一个阈值，超过阈值的数据自动下沉到对象存储，消费端仍然可以透明地读取这些历史数据，就像它们还在本地一样。这对于做事件溯源、审计日志、离线回放等场景特别实用。

动手测过一次分层存储的配置之后，我才意识到这功能有多省心：两个 broker 配置项就能让数据从热存储无缝迁移到冷存储，完全不用业务方操心。这种能力在自建消息平台时非常实用，能节省一大笔物理磁盘成本。

4. 实战选型对比：Pulsar、Kafka、RocketMQ 到底怎么选

4.1 三个主流消息中间件的差异化对比

作为一个在消息中间件上踩过不少坑的人，我给一个相对客观的对比，基于实际使用经验，不全参考官方宣传。

单看表格可能觉得 Pulsar 并不完全占优，尤其是生态成熟度上还有短板。但 Pulsar 的优势场景恰恰是云原生和平台化，如果你的团队核心需求是弹性扩缩容、资源共享，那架构优势会明显盖过生态短板。

4.2 我的选型建议：场景驱动而非技术驱动

这两年做技术选型，我越来越确信一个观点：不要为了用新技术而用新技术，消息中间件的选型一定要围绕业务真实场景展开。

如果你是做大数据实时计算、日志管道，追求极致的吞吐，Kafka 依然是稳妥之选。它的流处理生态（Kafka Streams、ksqlDB）和 Flink 的整合成熟度，在目前社区里很难被替代。如果你是做交易、订单、支付这类对可靠性极度敏感的链路，RocketMQ 的事务消息设计更加贴近业务语义，且多年双十一的验证让人安心。如果你们公司内部业务线庞杂，云上资源弹性需求大，想统一一套消息基础设施，那 Pulsar 的多租户与存算分离架构值得认真评估。

Pulsar 有个特性是跨地域复制（Geo Replication），这在多机房容灾场景下非常好用。相比 Kafka 的 MirrorMaker 需要额外部署和配置，Pulsar 原生支持多集群消息同步，配置好之后只需要一个 API 调用就能实现容灾切换。对于国际化业务或者异地多活的架构，这是一个不可忽略的加分项。

4.3 一次迁移踩坑复盘：Pulsar 不是银弹

想起一次从 Kafka 迁移到 Pulsar 的经历。当时团队觉得 Kafka 运维太累，想用 Pulsar 的多租户能力统一各个业务线的消息服务。前期测试很顺利，吞吐量、延迟都符合预期，但上了生产环境之后，消费客户端各种报错就来了：一部分老客户端不支持新协议，重新适配花了不少时间；还有一次 Bookie 节点磁盘故障，因为对恢复流程不熟悉，差点导致消息长时间不可读。

这次经历给我的教训是：Pulsar 的架构确实先进，但它的运维体系和 Kafka 完全不在一个维度。如果你团队里没有一个对 BookKeeper 原理比较熟的人，建议还是先做小范围试点，不要一上来就想全量替代。技术选型没有对错，只有适合不适合，这句话在消息中间件上体现得最鲜明。

5. 上手 Pulsar：从部署到运行的完整实操笔记

5.1 5分钟搭建本地开发环境

如果你是第一次接触 Pulsar，本地起一个单机实例最快的路径是用 Docker 镜像。

bash复制# 拉取 Pulsar 镜像并启动单机模式
docker pull apachepulsar/pulsar:3.2.0
docker run -d --name pulsar-dev \
  -p 6650:6650 \
  -p 8080:8080 \
  apachepulsar/pulsar:3.2.0 \
  bin/pulsar standalone

启动完成之后，Pulsar 会在 6650 端口监听消息协议，8080 端口提供 HTTP API 和 Admin API。我建议再起一个 Pulsar Manager 或者直接用命令行工具验证一下集群状态。

bash复制# 进入容器并查看集群信息
docker exec -it pulsar-dev /bin/bash
bin/pulsar-admin clusters list
bin/pulsar-admin tenants list

Pulsar 的租户和命名空间概念，在单机模式下虽然用途不大，但建议现在就把模型搞清楚。后面接真实业务时，Tenant / Namespace / Topic 的三层结构会直接影响你的命名规划和权限设计。

5.2 发送与消费：从原生 SDK 到客户端配置细节

原生 SDK 的使用很简单，Java 客户端大概是这样的：

java复制PulsarClient client = PulsarClient.builder()
        .serviceUrl("pulsar://localhost:6650")
        .build();

Producer<String> producer = client.newProducer(Schema.STRING)
        .topic("persistent://my-tenant/my-ns/hello-topic")
        .create();

producer.send("Hello Pulsar");

Consumer<String> consumer = client.newConsumer(Schema.STRING)
        .topic("persistent://my-tenant/my-ns/hello-topic")
        .subscriptionName("my-subscription")
        .subscribe();

Message<String> msg = consumer.receive();
System.out.println(msg.getValue());
consumer.acknowledge(msg);

看着跟 Kafka 的 Producer/Consumer API 很相似，但有几个配置值得额外关注。

第一个是 subscriptionName。它是 Pulsar 里最核心的消费抽象，相当于给这条 Topic 挂了一个独立的消费进度。同一个 Topic 上可以同时有多个不同名称的 Subscription，互不影响。这个特性让一套消息数据可以被多个业务场景反复消费，而 Kafka 里如果需要多份消费，往往要复制 Topic 或者设置多个消费组。

第二个是消息确认机制。Pulsar 的 Ack 是逐条确认的，比 Kafka 的 offset 提交更精细。使用累积确认可以提高吞吐量，但代价是如果某条消息处理失败，积压的批量消息都会重新投递。我个人的习惯是：如果消费逻辑不复杂，可以使用累积确认；如果每一条消息都要写数据库或调外部接口，建议逐条 Ack，避免重复处理带来脏数据。

第三个是消费者类型的选择。Pulsar 支持 Exclusive、Shared、Failover 和 Key_Shared 四种订阅类型。Exclusive 和 Kafka 的分区内单消费者语义一致；Shared 则允许多个消费者共同处理一个订阅的消息，相当于把队列模型带进了流世界里；Key_Shared 则保证同一 Key 的消息始终落在同一个消费者上，非常适合需要局部有序的场景。这四种订阅类型组合起来，几乎可以覆盖所有消息分发需求。

5.3 生产环境的配置清单和避坑要点

单机跑通容易，但生产环境一上来，坑就一个接一个。这里分享一份我整理的核心配置要点。

首先是 JVM 内存与堆外内存的分配。Pulsar Broker 同时使用堆内存和堆外内存（Direct Memory），默认配置在某些机器上可能不够用。如果发现 Broker 频繁 Full GC 或者直接内存 OOM，建议把 -Xmx 调大，同时关注 pls.memory.ensureNonHeapUsage 之类的直接内存限制。真实场景中，Pulsar 的内存分配策略需要按流量模型反复调整，一键配置不存在的。

其次是 BookKeeper 的 Journal 和 Ledger 配置。Journal 是 Bookie 的写前日志，必须放在高性能磁盘（SSD 或 NVMe）上，否则写入性能会大打折扣。Ledger 存储可以放在普通 HDD 或对象存储上，但要注意 managedLedgerCacheSizeMB 这个参数，它控制 Bookie 缓存的大小，直接影响读写性能。我见过不少团队在这里栽跟头，结果消息吞吐上不去，排查半天才发现是缓存配置给得太小了。

最后是 Topic 数量的预估和拆分策略。Pulsar 对 Topic 数量的容忍度比 Kafka 高，但也不建议一个业务一条 Topic 然后把所有事件都塞进去。相对合理的做法是按事件类型拆分，比如订单事件、支付事件、积分事件各自独立 Topic，方便不同业务方按需订阅、隔离权限和消费位点写坏。

6. 常见问题排查与调优实录

6.1 消息堆积，消费始终跟不上怎么办

面对消息堆积，直观第一反应是增加消费者数量，但在 Pulsar 里先要看你的订阅类型。如果是 Shared 订阅，增加消费者确实能提升并行消费能力，但前提是你消费者的处理逻辑没有瓶颈。如果消费者的处理耗时来自数据库写入或外部接口调用，单靠加进程可能只是把压力转到下游，堆积问题不除。

我一般会先做这几步排查：看消费者的 receive 到 ack 之间的耗时分布，找出是正常业务耗时还是阻塞等待耗时；看 Broker 端 Backlog 的存量和增速，判断积压是在快速增加还是已经平稳；再看下游数据库或外部服务的 QPS 和延迟指标，确认不是它拖了后腿。

如果是业务处理耗时太高，优先优化消费逻辑，比如批量写入、合并请求；如果已经没法优化，就考虑增加消费者或者是加大消费者的单次批量拉取数量。Pulsar 的 receiverQueueSize 可以调整 pre-fetch 的消息数量，适当调大能提升消费吞吐，但注意不能设得太大，否则消息都堆积在客户端内存里，一旦客户端宕机，重新平衡会带来更大的重复处理成本。

6.2 消息重复消费与数据幂等

所有消息中间件都有一个现实问题：消息可能重复。Pulsar 的 At-least-once 语义保证了消息至少送达一次，但这意味着网络闪断、客户端重连、Ack 超时之后，消息会被重新投递。

解决重复消费主要靠业务侧的幂等设计，我整理过一张速查表：

消息中间件只能保证“最终一致”，做不到“恰好一次”。如果你想做恰好一次（Exactly-once），单靠 Pulsar 还不够，需要在消费端配合事务数据库或数仓的幂等合并能力才能做到。

6.3 Broker 节点故障与集群自愈

Pulsar 的高可用机制依赖 BookKeeper 的副本机制。默认情况下，每个消息会被写入多个 Bookie 节点，只要副本数没被击穿，单节点故障不会丢数据。但节点故障时会出现一个现象：部分 Ledger 处于未关闭状态，需要触发 recovery 流程，这个流程会由新的 Owner Broker 自动完成。

这里有一个非常常见的坑：BookKeeper 集群的磁盘规划不合理。如果多个 Bookie 位于同一台物理机或同一块磁盘阵列上，看似做了多副本，实际上一个硬件故障就把所有副本都带走了。生产环境的正确做法是 Bookie 分布在不同的故障域里，尽量做到机架感知，而不是在同一台机器上疯狂压榨磁盘空间。

另外，Bookie 节点删除或替换时，需要关注 ledger re-replication 机制。Pulsar 的自动恢复功能会检测副本数不足的 Ledger 并自动触发数据复制，但如果集群压力太大，恢复过程会非常漫长。在计划内替换节点时，建议先做好权重调整，让流量逐渐迁移，避免一次性摘除多个 Bookie。

6.4 客户端连接反复断连怎么排查

Pulsar 客户端断连是一个让不少新手头疼的问题。常见的诱因有三类：网络不稳定导致长连接断开；Broker 端负载过高主动断开空闲连接；客户端参数配置不当，比如 keepalive 间隔设置太短或者 TCP 参数不合理。

排查时先看 Broker 端的日志，搜索 unexpectedly closed 或 connection reset 等关键字。如果大量连接在同一时间断开，大概率是 Broker 端 GC 停顿或磁盘 IO 阻塞导致的心跳超时。如果只是个别客户端断连，先排查客户端所在机器的网络环境，确认是否能稳定访问 Pulsar 集群的 6650 端口。

客户端侧的 keepAliveInterval 参数值得仔细设置。TCP 层默认的 keepalive 时间太长，可能等不到检测断开就已经触发数据重传。我一般会把 keepAliveInterval 设置为 30 秒，让客户端和服务端保持健康感知，同时把 operationTimeout 设置成 30 秒以上，避免因为偶发 GC 导致操作超时被误判为断连。

7. 消息中间件未来演进：Pulsar 还有哪些想象空间

7.1 消息与流计算一体化的趋势

消息中间件和流计算正在走向融合。Pulsar 本身提供了 Pulsar Functions 这样的轻量级流处理能力，可以直接在消息链路上做简单的转换、过滤和聚合，不需要额外引入一套流处理框架。对于中小团队，这可以减少组件数量；对于大团队，可以让一些简单的 ETL 逻辑消息化，让架构更简单灵活。

但需要冷静看待的是，Pulsar Functions 目前更适合轻量场景，复杂的流处理任务仍然要交给 Flink、Spark 这类专业计算引擎。消息中间件做好了，把事件送入计算引擎只是临门一脚而已。

7.2 消息中间件的 Serverless 化

Serverless 也是消息中间件的重要演进方向。Kafka 生态的 Confluent Cloud 、AWS MSK 已经把运维压力大幅降低，Pulsar 社区也在做类似的事情。存算分离的架构让 Pulsar 在 Serverless 化这件事上，有天然的优势，因为 Broker 无状态、存储层独立，理论上可以做到按需扩容到极限。

对于业务研发来说，Serverless 消息中间件意味着不再关心集群规模、磁盘水位、节点扩容，只管申请 Topic 和往里面发消息就行。对于平台团队来说，这意味着要构建一套自动伸缩、成本管控、租户配额管理的平台能力，复杂度反而更高。

7.3 从活动看 Pulsar 生态的未来

回到 Pulsar Developer Day 本身。一个开源项目生态是否健康，不只看核心代码提交了多少，更要看社区里的实践案例多不多、能否持续产出高质量内容。Pulsar 这些年慢慢在国内技术社区形成影响力，说明它的架构理念正在被更多团队验证。

如果这次活动上能听到一线团队分享他们在 Pulsar 上真实的技术选型、性能调优、以及踩过的坑，那就是最有价值的部分。每个技术决策背后的思考和代价，比结果本身更能帮助你构建自己的判断力。

8. 写在最后：我觉得值得关注的几个点

再分享一些个人体会吧。我不建议你把这场活动当成一次“技术布道”来看。更值得关注的是：一是 Pulsar 在消息模型上的灵活性，能否成为你团队重构消息层的契机；二是存算分离架构在你们当前基础设施条件下是否真的能落地，比如运维能力、网络环境、团队学习成本；三是生态工具链是否成熟到能支持你的业务需求。

消息中间件的选型不是一次技术投票，而是一次长期承诺。它像地基一样，一旦打下去，后续所有架构演进都受它影响。Pulsar 的先进架构固然诱人，但最终决定项目成败的，永远是你的团队对这项技术的理解深度和运维确定性。

最后给一个小建议：如果你准备深入 Pulsar，一定要先花时间把 BookKeeper 吃透。很多 Pulsar 的疑难问题，根源都在存储层。理解了 Ledger、Entry、Journal 和 Ensemble 的关系，你才能真正理解 Pulsar 为什么能扛住大规模消息压力，也能在故障发生时冷静应对，而不是到处翻文档、盲目重启。