周晓农1. COSCon'25 同场的 Pulsar Developer Day：倒计时3天，先想清去听什么
我在社区群里看到 COSCon'25 要同场办 Pulsar Developer Day 的时候，第一反应并不是“又要发新闻稿了”，而是赶紧把日历里那个时间块空出来。原因很简单：这是我自己的消息中间件技术必修课，而且不是那种在休息区晃一眼就能补完的大会论坛，它需要你用完整的时间去消化。
活动倒计时只剩三天，可以有两种理解方式。一种是等待议程公布、到时候去混个脸熟；另一种是把它当成一个“验证窗口”，把自己工作中遇到的中间件问题提前列出来，到现场找答案。我倾向于第二种。消息中间件这种基础设施，平时待在业务系统底层，不出事的时候没人提，一出事就是连环告警。真正在选型或者运维过消息队列的人，心里都攒着一堆问题：积压为什么追不上？扩容到底动 Broker 还是存储？多个团队共享集群怎么隔离？这些问题在文档里很难找到统一答案，但开发者日的分享方向通常正好踩在这些痛点上。
所以，与其说是“去听一个活动”，不如说是“去和一群人做一次问题对齐”。特别是 COSCon'25 这种大型开源会议，周边活动密度不低，Pulsar Developer Day 如果只是被当作打卡顺路的一部分，大概率会听得很散。我建议提前至少半天到场，把状态切到“中间件模式”，再进场。
1.1 去看同场活动，别把回放当作唯一的保底方案
很多人觉得，现在大会都有直播、有回放，晚点看也一样。这个想法在我以前参加开源活动时也有过，后来发现损失比想象中大。
现场听消息中间件案例分享和看回放完全是两种体验。视频里的 PPT 内容确实会完整呈现，但真正有意思的部分往往发生在问答环节，比如有人问“你们在共享订阅模式下遇到消息积压时，为什么没有选择直接换 Key_Shared”，演讲者会临时讲出一段代码库里没有的决策过程。这些内容不会被写进切片，也很难被收录进回放重点。同理，线下交流区和展台附近偶遇同行的机会，回放也给不了。
尤其是偏工程向的主题，听众几乎都是某一类系统的维护者。你问一句“你们是怎么做 Schema 兼容的”，对面可能直接掏出手机给你看一段内部设计方案。这种信息密度，隔着屏幕是感知不到的。三天倒计时看着像突发事项，实际上是给你留出了安排行程的空档。
1.2 会前先建立一张 Pulsar 基本概念图，现场才不会迷路
如果对 Pulsar 还比较陌生，我的建议是：入场之前，不必啃完整份文档，但至少要能把几个核心概念串起来，形成一张属于自己的脑图。
我用一个最通俗的方式描述 Pulsar 的运转逻辑：Topic 是消息容器，生产者把消息发布到 Topic，消费者通过订阅模式去读。Topic 上的消息并不是由处理连接的 Broker 永久保管，而是被写入 BookKeeper 这个存储系统。Broker 更像一个前台，负责接收你发来的连接请求、维持订阅关系、处理各种响应；真正把数据落盘、做副本和故障恢复的是后台的 Bookie 节点。
这正是 Pulsar 和不少传统消息队列在底层设计上不一样的地方。传统队列如果数据落在本地磁盘，那么某个节点既承担连接、又承担存储，扩容时往往要把分区从一台机器搬迁到另一台，数据量和迁移时间容易互相拉扯。Pulsar 把存储抽出去之后，Broker 可以相对轻量地水平扩展，BookKeeper 则在存储层通过 Ledger 和条目复制来保证数据可靠。
有了这层图景，再去看活动上的任何分享，至少不会听到“Bookie 磁盘写满”“Ledger 滚动上报”时一头雾水。同一个关键词，在讲台上和在你脑子里的含义一旦对齐，收获会翻倍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Pulsar 的“创新实践”没停留在口号：三个架构分水岭值得反复看
从消息中间件的生态来看，Kafka 这类系统做了“日志即队列”的抽象，把消息的读写速度做得很高；RabbitMQ 这类传统队列则在路由灵活性和多语言客户端上有优势。Pulsar 能在一众方案里挤进讨论范围，靠的不是“多加几个 API”，而是在系统结构上做了几个偏向不同场景的取舍。这次活动既然叫“创新实践”，如果你能从分享里听懂这三条取舍逻辑，基本就不会觉得抽象。
2.1 Broker 与存储拆开后，扩缩容终于不必动同一群机器
先看最核心的计算存储分离。Broker 和 BookKeeper 解耦的价