寒水微痕“COSCon‘25 同场活动 Pulsar Developer Day 议程正式发布！聚焦消息中间件创新实践”，这消息前几天一放出来，我朋友圈里好几个搞基础架构的朋友就转发了。说实话，作为一个常年跟消息队列打交道的人，看到这份议程我第一反应不是“又一场技术会”，而是“消息中间件这潭水，终于有人愿意往深里翻了”。
COSCon 是国内开源圈每年绕不开的聚会，Pulsar Developer Day 作为同场活动，直接把话题聚焦到消息中间件上，这本身就释放了一个信号：在云原生和实时数据越来越成为标配的今天，光会“用”消息队列已经不够了，你得知道它为什么这么设计、在什么场景下能发挥最大价值、踩坑之后怎么排查。这篇文章我就从这份议程出发，结合我自己在实际项目里折腾 Kafka、RabbitMQ、Pulsar 的经验，聊聊消息中间件选型、Pulsar 落地实操、常见问题排查这些真正有干货的内容，给准备入手 Pulsar 或者正在纠结“要不要从 Kafka 迁过来”的朋友一份参考。
1. 这场同场活动为什么值得关注：消息中间件格局已到拐点
先聊一个很多人没意识到的背景：消息中间件这个领域，过去十年基本是 Kafka 一家独大，但这个格局正在松动。原因不复杂——业务场景变了。早年 Kafka 解决的是“海量日志收集和离线分析”，它天生为吞吐量而生，但代价是 broker 有状态、分区扩展要搬家、跨地域复制麻烦、多租户支持弱。现在呢？大家要的是实时数仓、事件驱动架构、混合云部署、多团队共享集群。这些需求一上来，Kafka 的设计边界就露出来了。
1.1 COSCon与Pulsar Developer Day：开源社区的一次精准汇合
COSCon’25 把 Pulsar Developer Day 放进同场活动，我觉得是个特别聪明的安排。COSCon 本来就是开源开发者密度最高的地方，来的人不光是看热闹的，更多是真正在选型、在维护、在给自己团队找解决方案的人。Pulsar Developer Day 放在这种场合，天然就能吸引到“有真实需求”的受众，不是讲概念，而是奔着“怎么用起来”去的。
这种开发者日的价值跟普通大会演讲还不一样。普通演讲是“我带你看我的成果”，Developer Day 更接近“我们坐下来一起把某个东西研究透”。从我过往参加类似活动的经验看，这类活动的议题设置一般都会有几条明确的线：一条是服务端深度剖析，一条是客户端和生态集成，一条是真实业务落地案例，还有一条是运维和排障方法论。这次 Pulsar Developer Day 围绕“创新实践”展开，我猜测大概率也是这几个方向里挑重点打深，而不是每个话题都蜻蜓点水。
1.2 消息中间件的现实困境与Pulsar的差异化定位
要理解 Pulsar 为什么能在 Kafka 的阴影下生长出来，得先理解 Kafka 的痛点。Kafka 的存储模型是“分区日志落在 broker 本地磁盘”，这意味着 broker 节点既要干活（处理请求）又要存数据（维护副本），两者耦合在一起。扩容的时候，分区要从旧节点搬到新节点，数据迁移期间集群的均衡性、可用性都会受影响。跨地域复制就更难受了，要么用 MirrorMaker 这种“异步搬数据”的方式，要么就得接受复杂的跨机房同步方案。
Pulsar 从一开始就选择了另一条路：存储和计算分离。Broker 层是几乎无状态的，只管接收请求、路由消息、维护元数据；实际的数据存储交给一个独立的存储层（默认是 Apache BookKeeper）。书库里的存储节点和 broker 节点可以独立扩容，broker 不够用就加 broker，存储不够用就加 bookie，互不干扰。加上 segment 级别的分层存储机制，老数据可以自动沉降到 S3 或 HDFS 这类廉价存储里，消费回溯能力几乎是无限的。
这个架构带来的直接好处有三个：第一，扩容不用搬家，加机器就行；第二，多租户天然隔离，不同团队可以共享一个集群，互不影响；第三，跨地域复制从架构上就支持，消息可以先写入本地，再异步同步到远端，延迟远低于 Kafka 的复制方案。这也是为什么很多从 Kafka 迁到 Pulsar 的团队，核心理由都不是“Pulsar 更快”，而是“Pulsar 在运维上和弹性上更省心”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从议程看核心议题：八成内容都落在“用起来”这件事上
看一份开发者日议程，我一般不看标题华丽不华丽，而是看它有没有覆盖“从开发到运维的全链路”。消息中间件是个典型的“看起来简单、用起来水深”的基础组件，光会写个 producer 和 consumer 是远远不够的。生产环境里你一定会遇到：消息堆积怎么办、顺序性怎么保证、事务消息怎么处理、broker 内存怎么调、backlog 怎么控制、集群配额怎么设置。如果议程里对这些问题有回应，那这场活动就值得去。
2.1 我比较期待的几类议题方向
从个人经验出发，我认为这类 Developer Day 最有含金量的议题集中在以下几个方面。
第一是服务端新特性与性能调优。Pulsar 的迭代速度其实很快，但很多用户对 2.x 之后的版本特性并不熟悉。比如可插拔的存储访问模式、统一的消息协议支持、更细粒度的资源配额控制、IO 线程模型优化这些都是直接影响生产稳定性的东西。如果议程里有这类 session，建议重点关注，哪怕是录播也值得看完，因为这里讲的全是“别人已经在生产环境验证过的东西”。
第二是客户端生态与多协议接入。Pulsar 的优势之一就是协议兼容性，你可以用 Kafka 老客户端直接连 Pulsar 集群，也可以用 MQTT 协议做物联网接入，或者用 AMQP/RabbitMQ 的协议把存量系统接进来。这对很多团队来说是迁移成本最低的一条路。现实中大部分系统不可能“一夜全换成 Pulsar 原生客户端”，协议兼容层就是缓冲带。如果议程里有真实迁移案例，我会特别留心听他们怎么处理 offset 映射、消息格式兼容这类细节。
第三是真实业务场景下的案例分享。我最怕听到的是“我们的系统用了 Pulsar 之后性能提升 300%”这种没有上下文的话。真正有价值的案例应该包括：原来用什么、为什么换、迁移过程踩了什么坑、最终架构长什么样。比如数据同步、订单事件流、游戏在线状态推送、车联网状态上报，每一种场景对消息队列的要求其实差别很大，只有结合具体场景讲才能听出设计思路。
第四是从 0 到 1 的运维与排障经验。Pulsar 的架构比 Kafka 多了一层存储，好处是弹性，代价是增加了理解成本。BookKeeper 的 IO 模型、journal 和 ledger 的区别、ensemble 和 write quorum 的关系，这些概念如果没人帮你理一遍，光看官方文档很容易一头雾水。这类 session 通常是最实用的，因为运维的人最缺的就是“别人帮我趟过一遍坑”的结论。
2.2 Pulsar 技术原理快速回顾
如果你之前没接触过 Pulsar，我建议在去现场或看直播前，先把几个核心概念弄明白。
Pulsar 的整体结构可以类比成“一个中间调度层 + 一个独立存储层”。中间调度层是一组无状态的 broker，它们负责接收生产者的消息、把消息交给存储层、再从存储层取消息发给消费者。存储层是 BookKeeper 集群，由多个 bookie 节点组成，每个节点负责存储多份消息副本，同时维护消息的写入顺序。
消息在 Pulsar 里不是以“分区”为单位直接落盘的，而是先写入一个叫做 ledger 的存储单元。Ledger 可以理解为一组顺序追加的日志文件，每条消息在 ledger 里有个唯一的 entry 编号。Broker 把消息写入 BookKeeper 后，BookKeeper 会通过 ensemble 中的一个或多个 bookie 来同时写入，只要满足 write quorum 的数量，这条消息就算写入成功，这样就能保证即使某台 bookie 挂掉，消息也不会丢。
Topic 在 Pulsar 里可以进一步细分为 subscription，这是消费模型的核心。跟 Kafka 的消费组相比，Pulsar 的订阅模型更灵活，除了支持消费者组模式（exclusive、shared、failover、key_shared），还提供了真正的“主题模式”，适合做 pub/sub 广播。而且 topic 的数据写入是按 segment 切分的，每个 segment 到达一定大小或时间后就会被关闭，之后可以自动被迁移到更廉价的存储上，这就是分层存储的实现基础。
把这几个概念串起来，Pulsar 的设计逻辑就清晰了：broker 无状态所以能水平弹性伸缩，BookKeeper 负责存所以数据可靠性可以做得更高，segment 分层存储让消息数据从“有限期保存”变成了“无限期可回溯”，而这种能力正是实时数仓和事件溯源架构最需要的。
3. 光听不练没有用：消息中间件选型与Pulsar落地实操要点
大会听完，最终还是要回到自己的业务里做判断。我经常被问到“我们该不该上 Pulsar”“能不能从 Kafka 迁过去”，这类问题其实没有标准答案，但我可以分享一套自己的评估框架和落地思路，encompass 了选型、部署、配置三个层面。
3.1 选型评估：什么时候该上 Pulsar，什么时候别折腾
先泼一盆冷水：如果你的团队只有几个人、业务规模还在早期、消息量一天也就几百万条，那 Kafka 或者 RabbitMQ 完全够用，没必要为了“先进架构”折腾一套 Pulsar。Pulsar 的优势要在大规模、多团队、复杂业务场景下才能体现出来，小规模场景下它的优势不明显，运维成本反而是负担。
那我个人认为，出现下面几种情况中的至少两种，才值得认真考虑 Pulsar：
第一，你们有多个业务团队需要共享一套消息基础设施，但又不想让彼此互相影响。Pulsar 的多租户是内置的，每个租户可以有自己的配额、认证、隔离策略，团队之间用 namespace 隔开，天然适合“一个集群服务全公司”的治理模式。第二，你们的消息数据需要保存很长时间，并且支持按时间回溯消费，比如做事件溯源、做数据回放、做风控审计。Kafka 的分区日志保存在本地磁盘，保存太久意味着磁盘成本暴涨；Pulsar 的分层存储可以把老数据自动挪到对象存储，成本低一个量级。第三，你们有跨地域部署或多活需求，Pulsar 的跨地域复制从架构上就支持，不需要额外搭数据同步管道。第四，你们对流量的峰值弹性有要求，希望能在高峰期快速加 broker、低峰期把资源缩回来。
我见过不少团队盲目迁移，最后发现核心痛点并没有被解决，反而引入了一堆新概念的学习成本。所以选型这事，一定得先盘点自己的真实需求，而不是看哪个技术更“新潮”。
下面这张表是我自己整理的一组对比，方便大家对号入座：
| 维度 | Kafka | RabbitMQ | RocketMQ | Apache Pulsar |
|---|---|---|---|---|
| 核心架构 | 分区日志，存储与计算耦合 | 队列 + 交换机，推拉结合 | 队列 + 索引，存储与计算耦合 | 存储与计算分离，Broker 无状态 + BookKeeper 存储 |
| 持久化与回溯 | 本地磁盘保留，受磁盘容量限制 | 短期持久化，以队列为主 | 本地磁盘文件，可配置清理周期 | Segment 分层存储，可无缝回溯到任意历史位置 |
| 多租户隔离 | 靠独立集群或多实例实现 | 支持的比较弱 | 有租户概念，但粒度不够细 | 原生多租户，配额、认证、隔离内置 |
| 跨地域复制 | 需 MirrorMaker 等辅助工具 | 依赖插件或自研 | 有同步双写方案，但成本高 | 内置跨地域复制，支持多活 |
| 协议兼容性 | Kafka Client | AMQP、MQTT、STOMP 等 | 兼容 Kafka 部分 API | 原生 Kafka、MQTT、AMQP 协议兼容 |
| 运维复杂度 | 较低，社区资料多 | 中等 | 中等 | 偏高，要理解 BookKeeper |
| 典型适用场景 | 日志管道、数据集成、实时计算 | 系统解耦、任务分发、微服务 | 交易类消息、金融场景 | 多团队共享、事件溯源、混合云部署、海量 Topic |
3.2 部署层面的关键参数与配置思路
如果决定尝试 Pulsar，先别急着上生产，建议用一个三节点的最小集群把架构跑通。三节点虽然规模不大，但足够你理解 broker、bookie、ZooKeeper 三者之间的关系，也足够暴露大部分常见问题。
部署的时候有几个配置参数我特别想提醒：
首先，内存参数。Pulsar 的 broker 默认会使用系统的大部分内存作为缓存，但在低配机器上反而容易触发频繁 GC。建议在 broker.conf 里显式设置内存上限，比如 -Xms 和 -Xmx 都设为 4GB 或 8GB，别让 JVM “自适应”地乱申请。BookKeeper 同样有自己的内存和 IO 参数，bookie 的内存不能随便给太少，因为它要维护读写缓存、文件句柄和内存表。
其次，存储路径规划。BookKeeper 写入数据主要分两块：journal 和 ledger。Journal 类似于数据库的 WAL，要求低延迟、高吞吐，最好单独挂一块 SSD；ledger 存储实际消息数据，容量要大，普通 HDD 也可以，但如果业务对写入延迟敏感，尽量也用 SSD。用磁盘阵列时注意别把 journal 和 ledger 放在同一个物理盘的同一个分区里，否则两者互相抢占 IO 会让性能变得很难看。
再次，消息保留策略。Pulsar 默认会保留所有未消费的消息，这在生产环境里是个“隐形炸弹”。你可以在 namespace 级别配置 message TTL 和 retention。TTL 是控制未被消费的消息多久后可以被清除；retention 是控制已经被消费但你还想保留多久的消息策略。两者配合使用，才能让集群在“能回放历史数据”和“别爆磁盘”之间取得平衡。
最后，Topic 分区数。分区数不是越多越好。Pulsar 本身对 Topic 数量不敏感，你可以创建成千上万个轻量 Topic，但每个 Topic 的分区会对应一个后台任务和可能的订阅状态。如果某个 Topic 分区数设置得太高，会造成 broker 元数据压力增大。我的建议是先用一个分区起步，等生产和消费能力明显不够时再加分区，或者直接采用 key_shared 订阅模式让消息按 key 有序分发，避免为了并行度盲目拆分区。
4. 实操过程与核心环节实现：最小可用 Pulsar 集群的搭建记录
理论聊了一堆，还是得来点能直接动手的东西。下面是我自己在本地环境搭一套最小 Pulsar 集群的记录，给你参考。这套方案适合学习、功能验证、小规模业务预研，不建议直接照搬上生产，但所有配置参数在生产环境同样适用。
4.1 环境准备与基础规划
我用的是三台 2C4G 的云主机，操作系统是 Ubuntu 22.04 LTS，每台机器预装 OpenJDK 17。Pulsar 的版本我选择当时最新的稳定版（3.x 系列），下载的是官方 release 版的二进制包，没有用 Docker Compose。为什么不用 Docker？一个是多机场景下容器网络和端口映射会增加排障难度，另一个是我想通过手动部署把每个进程之间的关系彻底搞清楚。
规划表如下：
| 节点 | 角色 | IP |
|---|---|---|
| pulsar-a | ZooKeeper + Bookie + Broker | 10.0.1.10 |
| pulsar-b | ZooKeeper + Bookie + Broker | 10.0.1.11 |
| pulsar-c | ZooKeeper + Bookie + Broker | 10.0.1.12 |
三个角色压在三台机器上是学习场景的妥协，生产环境至少要把 ZooKeeper 和 BookKeeper 分开，Broker 独立成层。多一层进程就多一层排查维度，分离开才能准确定位问题。
4.2 部署步骤与关键配置
第一步，解压 Pulsar 安装包，设置环境变量：
bash复制cd /opt
tar -zxvf apache-pulsar-3.x-bin.tar.gz
mv apache-pulsar-3.x /opt/pulsar
echo 'export PATH=/opt/pulsar/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
第二步，配置 ZooKeeper。Pulsar 自带 ZooKeeper 配置模板，路径在 /opt/pulsar/conf/zookeeper.conf。需要修改的核心配置包括：
code复制dataDir=/data/zookeeper
server.1=10.0.1.10:2888:3888
server.2=10.0.1.11:2888:3888
server.3=10.0.1.12:2888:3888
同时在 dataDir 目录下创建 myid 文件，第一台写 1，第二台写 2，以此类推。然后把所有机器上的 ZooKeeper 启动起来：
bash复制/bin/pulsar-daemon start zookeeper
三个节点都起来后，用 bin/pulsar zookeeper-shell 10.0.1.10:2181 ls / 检查一下，能看到 ledgers、namespace 之类的路径就说明集群正常了。
第三步，配置 BookKeeper。编辑 /opt/pulsar/conf/bookkeeper.conf，重点参数如下：
code复制journalDirectory=/data/bookie/journal
ledgerDirectories=/data/bookie/ledger
zkServers=10.0.1.10:2181,10.0.1.11:2181,10.0.1.12:2181
journalSyncData=false
journalSyncData=false 是一个性能向的配置，表示写入 journal 时不等待 fsync 完成再返回，性能提升明显但机器断电会有小概率丢最近几笔数据。学习环境可以开，生产环境建议保持默认的 true，或者配合 UPS 电源再优化。
启动 BookKeeper：
bash复制bin/pulsar-daemon start bookie
第四步，配置 Broker。编辑 /opt/pulsar/conf/broker.conf：
code复制zookeeperServers=10.0.1.10:2181,10.0.1.11:2181,10.0.1.12:2181
advertisedAddress=10.0.1.10
clusterName=pulsar-cluster
managedLedgerDefaultMarkDeleteRateLimit=1000
advertisedAddress 一定要写对，broker 会把这个地址告诉客户端，如果你填了 localhost，客户端在别的机器上是连不过来的。managedLedgerDefaultMarkDeleteRateLimit 用于控制游标确认删除的速度，默认值较低，写入频繁时容易造成消息积压但不消费的情况，这里适当调大一点可以减少“假堆积”。
启动 broker：
bash复制bin/pulsar-daemon start broker
第五步，验证集群。用 bin/pulsar-admin clusters list 看看能不能返回集群名，再用 bin/pulsar-admin tenants list 查看默认租户。然后创建一个测试 namespace 和 topic：
bash复制bin/pulsar-admin tenants create test
bin/pulsar-admin namespaces create test/ns1
bin/pulsar-admin topics create persistent://test/ns1/demo-topic
最后用内置的客户端工具跑一轮生产消费验证：
bash复制bin/pulsar-client produce persistent://test/ns1/demo-topic --messages "hello pulsar"
bin/pulsar-client consume persistent://test/ns1/demo-topic --subscription-name test-sub --num-messages 1
能看到消息正常打印，说明这台最小集群已经能跑通全链路了。
4.3 从 Kafka 迁移的思路与工具
很多人会关心“我现网是 Kafka，怎么迁过来”。这里有个好消息：Pulsar 对 Kafka 协议有原生兼容层，你可以在 Pulsar 集群上开启 Kafka 协议端口，然后把 Kafka 客户端的 bootstrap.servers 指到 Pulsar 的地址，无需修改代码就能把生产流量切过来。
启用方式是在 broker.conf 里加上：
code复制messagingProtocols=kafka
kafkaTenant=public
kafkaNamespace=default
kafkaListeners=PLAINTEXT://0.0.0.0:9092
这样 Kafka 客户端就能直接当 Pulsar 是“一个支持 Kafka 协议的 broker”，分区、消费组、offset 提交都会映射到 Pulsar 的对应概念上。但要注意几点：
第一，Pulsar 的 Kafka 兼容层不是 100% 的功能对齐，比如 Kafka 的幂等事务语义和部分管理接口不完全支持。常规的数据管道、实时计算、日志采集这些场景没有问题，但如果你的业务重度依赖 Kafka 的高级 API，就要先做功能验证再迁移。
第二，迁移过程中尽量先旁路验证，不要直接切主路。我的习惯是先用双写的方式把新消息同时发到 Kafka 和 Pulsar，等 Pulsar 这边的消费验证通过、指标稳定后再逐步停掉 Kafka 的写入流量。
第三，离线数据的搬迁可以使用 Pulsar 自带的 pulsar-admin sinks 和连接器，或者用 Flink CDC 一类的工具从 Kafka 里读历史数据回放到 Pulsar。要注意历史数据的 offset 和 timestamp 尽量保持一致，否则下游做按时间回溯时数据会“参差不齐”。
5. 常见问题与排查技巧实录
Pulsar 的运维排障，很多时候不是不会配，而是不知道从哪里入手。下面这张表是我自己踩过、也帮别人排查过的典型问题速查表，希望能替你省点时间。
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 消息延迟升高，生产链路变慢 | Bookie 磁盘 IO 打满；journal 与 ledger 在同一块盘互相抢 IO | 用 iostat 看磁盘 IO；检查 journal 目录是否单独挂盘；适当增加 Bookie 副本数缓解单盘压力 |
| 消费端有消息积压但实际在正常消费 | mark-delete 速率太低；消费者频繁 rebalance | 查看 managedLedgerDefaultMarkDeleteRateLimit 配置；检查订阅名是否稳定 |
| 客户端报 “Topic does not exist” | 租户、命名空间、Topic 路径写错 | 用 pulsar-admin topics list 确认完整路径；检查是否开启自动创建 Topic 策略 |
| Broker 频繁 Full GC | JVM 堆内存配置过大或过小；缓存配置不合理 | 查看 GC 日志；调整 -XX 参数；限制 broker 的 cache 上限 |
| 某个 Topic 消费延迟非常大 | 分区数过少，消费者数量大于分区数 | 增加分区；改 key_shared 模式；检查是否存在慢消费者阻塞 |
| 多层 storage 数据读取失败 | 对象存储桶权限或连接配置错误 | 检查 s3 connector 配置；确认 bucket 可读写；看 broker 的日志有没有超时报错 |
| 跨地域复制延迟高 | 网络带宽不足；复制消息的 topic 优先级配置不当 | 检查两机房延迟和带宽；为复制主题设置更高的优先级配额 |
5.1 Bookie IO 和磁盘规划：最容易踩的坑
BookKeeper 是 Pulsar 的存储底座，它一慢，整个集群都跟着遭殃。最常见的坑就是把 journal 和 ledger 放在同一块盘上。Journal 是顺序写的小文件，对延迟敏感；ledger 是大块顺序写，对吞吐敏感。两者放一起，轻则 IO 抖动，重则直接导致 write 请求超时。
我后来在正式环境里的做法是：每台 bookie 节点至少配两块数据盘，一块 NVMe SSD 给 journal，另一块大容量 SSD 给 ledger。如果预算有限不能分盘，那至少要保证 journal 目录放在最快的盘上，ledger 可以接受相对慢一些的盘。还有一点，bookie 的 journalSyncData 参数在生产环境建议保持 true，这在极端情况（宕机、断电）下能避免 ledger 元数据损坏，代价是每次写入要等一次 fsync，性能大概下降 10-20%，但换来的可靠性完全值得。
5.2 消费者堆积的误判与真相
消息堆积是运维群最常见的问题。但“堆积”这个词很容易被误判。Pulsar 的 backlog 统计和 Kafka 的 consumer lag 机制不太一样，Pulsar 的 backlog 是指“消息已经写入存储层，但对应订阅的游标还没确认消费完成”。如果游标长时间不推进，backlog 就会一直增长，但这时候数据其实还是在 BookKeeper 里，不会自动删除。
有一次一个业务方找到我，说他们的消费者 lag 一直涨，应用日志里又看不到消费错误。我查了订阅的信息，发现消费者实例的 state 是正常的，但游标一直没做 mark-delete。最后定位到是他们在消费逻辑里对每条消息做了事务处理，但事务因为一个外部接口超时一直没提交，导致游标无法推进。所以排查堆积问题的时候，第一个动作应该是确认“消费者到底有没有在处理消息”，而不是急着加消费者实例。
5.3 内存和 GC：broker 的隐形杀手
Pulsar 的 broker 是 JVM 进程，内存管理是个敏感话题。默认情况下，Pulsar 会倾向于用尽可能多的内存做缓存，这在配置较大的机器上是没问题的，但如果你给 broker 分配了 16GB 堆，而系统可用内存就只有 16GB，那么进程管理和 GC 的压力会非常大。
我的经验是，broker 的堆内存设为 8GB 到 16GB 比较合适，并且要显式指定 -XX:+UseG1GC。同时注意区分 broker 的堆内存和 BookKeeper 的堆内存，BookKeeper 的缓存应该主要放在 DirectMemory 上，这样 GC 压力小。如果发现 broker 的 GC 时间很长，可以用 jstat -gcutil 查看各个代的 GC 情况，通常调大新生代比例、限制缓存池大小就能明显改善。
结尾：一点个人感悟
活动还没开始，但我已经有点期待了。消息中间件这个领域，过去总觉得没什么新故事可讲，但 Pulsar 的出现让我看到“设计再重构”的价值——它不满足于缝缝补补，而是把存储和计算分开，把多租户和跨地域复制做成标配。哪怕你现阶段还没有迁移计划，去现场听一听别人在真实场景里的落地经验，也一定会对下一代的架构设计有新的启发。
如果让我给一个最实际的建议：看议程的时候，别只挑跟当前技术栈匹配的场次，挑一两个“你完全没用过”的方向去听，往往收获最大。毕竟技术在进步，你现在的“用不上”，不代表三个月后还用不上。咱们现场见。