Apache Pulsar开源集市指南：存算分离与多租户架构解析

这周末，COSCon'25开源集市要开了，Apache Pulsar社区也会在会场出现。你可能在技术推送里见过Pulsar这个名字，也可能正在几个消息中间件之间做选型对比，又或者单纯想找个机会跟真正写开源的人面对面聊几句——这三种人，在开源集市上都能找到属于自己的收获。

我给准备去现场的朋友一个建议：别把它当成一个领完贴纸就走的打卡展位。Pulsar这一两年在架构上的讨论热度不低，尤其存算分离、多租户、跨地域复制这几个设计，和传统消息队列的路数差别挺大。提前花二十分钟把核心概念过一遍，到了现场你能问到点子上，也能真正理解为什么这么多大厂愿意把它放到生产环境里扛业务。

所以这篇文章既是给没法到场的读者补课，也是给准备去面基的人一份预习提纲。

1. 为什么Pulsar要跑到开源集市“摆摊”

如果说主论坛是正式演讲厅，那开源集市就是大会的开放广场。各个开源社区搬来易拉宝、笔记本、贴纸和周边，在展位上支起自己的一小片天地。Pulsar社区出现在这里，乍一看有点“技术大牛摆地摊”的反差，但仔细想想，这恰恰是开源项目最接地气的打开方式。

1.1 开源集市和普通技术论坛的差别

传统技术论坛的节奏是：台下听PPT，散场扫码加群，多数人跟演讲者之间隔着台子。开源集市不一样，它没有一个固定的“台上台下”关系，每个展位都可以停下来直接对话。你问的问题不用是严格排好队的Q&A，甚至可以在对方说话中途追问一句“等一下，这个点我没太听懂”。

这种面对面交流的效率，远高于自己回去翻文档踩坑。我记得有一次在集市上跟一个开源项目的维护者聊了十分钟，他随口讲了一个配置项在实际生产中的坑，那个细节书里没写、文档里没提，但直接帮我避掉了一次线上事故级别的误配置。

Pulsar来集市，目的也不是搭个华丽舞台。它想让你看到的恰恰是这个项目最真实的一面：有人在实际业务里用它处理每天上亿条消息，有人正在为下一个版本写新特性，也有人只是第一次听说这个项目、过来问一句“这东西跟Kafka到底啥区别”。这三种对话，在开源集市上都成立。

1.2 社区参展的目的：不是发礼品，是找同路人

你可能以为开源社区的展台就是为了刷存在感，其实更深一层的原因是“找人”。一个Apache项目要健康运转，永远缺几类人：

第一类是愿意在生产环境落地它的人。社区需要来自真实场景的反馈——哪些功能好用，哪些接口反直觉，哪个版本升级出了幺蛾子。这些信息比任何问卷调查都宝贵。

第二类是愿意读源码的人。Pulsar的代码量不算小，涉及网络通信、存储引擎、分布式协调，一个认真读源码的贡献者，哪怕只修了一个文档错误，对项目都是增量。

第三类是愿意在中文社区做布道的人。很多项目不缺英文文档，缺的是能把复杂架构讲清楚的本地化内容。

所以你在展位前问的每个具体问题，都不是“浪费人家时间”，反而是在帮社区校准方向。不用怕问题太基础，见过太多人从“Pulsar支持延迟消息吗”这种问题起步，最后成了社区里很活跃的参与者。

1.3 你会在展位遇到哪些人

开源集市的展位通常不会只有一个人在守摊。Pulsar这样体量的项目，展位上大概率会出现这几种角色：

这里有个很实用的判断方法：如果你发现某个人的名牌或自我介绍里有“PMC”“Committer”字样，别紧张，也别一上来就背八股文。你可以直接说“我最近在调研Pulsar，有个场景一直想不明白”，然后描述你遇到的问题。

比问“Pulsar和Kafka比谁好”更有价值的，是问“我有个定时任务削峰的需求，已经用了XX，Pulsar迁移过来会遇到什么坑”。后一种问题会立刻把对话从科普拉入实战。

2. Pulsar架构里那几个值得当面追问的设计

如果去展位前只能预习一件事，那应该是Pulsar的核心架构。这部分的“干货浓度”直接决定你到现场能听懂多少。

提示：如果你只有二十分钟预习时间，优先级是——先搞懂Broker和BookKeeper的分工，再了解多租户，最后看订阅模式。这三个点足够支撑你在现场提出有质量的问题。

2.1 存算分离不是口号，Broker和BookKeeper各管什么

Pulsar最常被提起的设计就是“存算分离”。字面上容易懂，但很多人没细想过它到底拆开了什么。

Pulsar里的Broker你可以理解为“服务层”，它负责接收生产者的消息、把消息推给消费者、维护订阅游标、做权限校验和路由。注意一个关键点：Broker本身不保存消息数据，它只做转发和调度，所以它是无状态的（严格说会有少量缓存和游标信息，但没有持久化负担）。

消息真正落盘的地方是BookKeeper，一个分布式存储系统。Pulsar把每个Topic的消息切成一段段有序的Sealed Ledger，这些Ledger分布存储在多个BookKeeper节点上。Broker向BookKeeper写入消息，消费时再从中读取。

用餐厅来类比：Broker是前台服务员，负责接单、上菜、记下哪位客人点了什么；BookKeeper是后厨和仓库，所有食材和半成品都储存在那里。服务员可以随时增减，因为菜不在他手里；后厨可以根据客流扩展炉灶，因为菜都在后厨做。

这个设计带来的直接好处有两个。第一，Broker扩缩容非常快，新加一个Broker不需要迁移任何数据，它只要加入集群就能开始服务。第二，单个Topic的分区数不再受“一个分区必须落在某个固定节点”的限制，Topic可以分散到任意Broker上处理。

如果你到现场只记住一个词，记住“存算分离”。这四个字几乎解释了Pulsar一半的设计选择。

2.2 多租户与跨地域复制：生产环境最关心的两件事

第二个值得问的点是多租户。Pulsar的命名空间分三层：租户（Tenant）、命名空间（Namespace）、主题（Topic）。租户是最上的隔离单元，一个租户下可以有多个命名空间，命名空间下挂一堆Topic。

这套三级结构的价值在于：多个业务部门可以共用一套Pulsar集群，但彼此之间在权限、配额、消息保留策略上完全隔离。A部门误删了Topic不会影响B部门，B部门的流量突刺也不会把集群打挂导致A部门背锅。对中大型公司来说，这省去了“一个业务一套集群”的运维噩梦。

跨地域复制也是一样，它不在Topic层级配置，而是在Namespace层级配置。你只要告诉Pulsar“这个命名空间里的消息要在北京、上海、新加坡三地复制”，剩下的由系统搞定。消息在一地写入后，通过底层BookKeeper的异步复制机制同步到其他集群，任何一个地域故障，应用流量可以切到另一地域继续消费。

在现场跟社区成员聊这个话题时，可以追问一句“故障切换时已消费的消息状态怎么保证”。这会让对话很快深入。

2.3 统一队列与流模型：一个平台覆盖两类场景

第三个值得琢磨的设计是订阅模型。很多消息中间件要么只擅长队列（点对点），要么只擅长发布订阅（Pub/Sub），Pulsar想用一套模型把两类场景都吃掉。

它提供了四种订阅类型：Exclusive（独占）、Shared（共享）、Failover（故障转移）、Key_Shared（按键共享）。独占模式适合一条消息只能被一个消费者处理的场景；共享模式让消息轮询分发给多个消费者，适合削峰填谷的队列场景；故障转移模式下同一时刻只有一个消费者活跃，但备胎随时准备顶上；按键共享则保证同一个Key的消息永远落到同一个消费者手里。

Plus，Pulsar还提供Reader模式。Consumer读消息时会自动维护游标，而Reader允许你从任意位置开始读，读完不提交游标，下次还能重读。这对流处理场景特别重要，比如你需要从三天前的某个消息位点重放所有数据，用Consumer不容易做到，用Reader就很顺手。

顺带提一个容易被忽略的特性：分层存储（Tiered Storage）。消息在BookKeeper里保存一段时间后，可以自动卸载到对象存储（S3、GCS这类），消费老消息时再从对象存储拉回来。这样你不需要无限扩充本地磁盘，也能保留长期历史数据用于回溯分析。

2.4 现场问什么最能分辨“真懂”和“背文档”

展位上聊技术，最怕对方只会背官方文档。下面这几个问题是我真心建议你带去现场的：

• 生产环境里，你们Broker节点和BookKeeper节点数量大概怎么配比？扩容时优先加哪一边？
• 消息量上去之后，BookKeeper的写入延迟有没有明显抖动？你们怎么做存储节点的热均衡？
• 分层存储触发后，读取几个月前的消息延迟大概什么水平？有没有办法缓存热点数据？
• 从Kafka迁到Pulsar时，消费端位移（Offset）怎么平滑映射到Pulsar的游标上？

这些问题没有标准答案，但能问出具体做法的人，一定在真实环境里跑过。你得到的回答，哪怕只是一个大概思路，也比看十篇博客有价值。

3. COSCon'25开源集市上，Pulsar展位能玩到什么

说了半天架构，回到现场本身。COSCon'25的开源集市里，Pulsar展位到底能玩出什么花？虽然具体安排以现场为准，但从往年开源社区参展的套路和Pulsar项目的特点，可以合理推测出几个方向。

3.1 展位常见的Demo与互动设计

开源项目的展位一般不会只贴海报，Pulsar这类消息中间件很适合做实时演示。一个可能出现的经典Demo是：公屏上实时滚动消息流向，生产端持续往Topic里灌数据，消费端消费并把统计数字刷在一个仪表盘上，中间显示Pulsar的Broker集群和BookKeeper存储节点——你可以直观看到每条消息怎么从生产成本到消费端，还能现场点按钮触发扩容，看新Broker几秒内加入集群开始分担流量。

这种演示的技术含量不算特别高，但现场跑起来很有视觉冲击力。如果你没接触过Pulsar，看五分钟基本就知道它在分布式系统里的位置了。

展位互动环节通常会有的几样东西：

• 架构知识问答，答对拿周边，题目难度不高，很多答案就在展位海报上
• 和核心贡献者合影，现场打印出来当书签
• 社区签名墙，写一句你希望Pulsar增加的功能
• 如果人多，可能还有小型闪电分享，10分钟讲一个Pulsar冷知识

别觉得这些环节幼稚，很多持续参与社区好几年的人，最初就是被一个贴纸“骗”到展位前，然后问了一个问题才入坑的。

3.2 “高性能消息平台”在真实项目里长什么样

展位上聊到兴头上，大概率会有人跟你讲Pulsar的实际应用场景。这里我先替你做一个快速背景补充，免得现场懵。

消息中间件的真实使用场景通常分几类。一类是业务削峰填谷，比如电商大促时订单请求瞬间暴涨，后端服务扛不住峰值，就把创建订单的消息先扔进Pulsar，后端按自己的消费能力慢慢处理。

另一类是日志和数据管道。各种业务系统产生的日志、埋点数据、数据库变更事件，通过Pulsar汇聚后投递给计算引擎或数据仓库，做实时分析。Pulsar的分层存储在日志场景里特别吃香，因为它能把久远的历史日志低成本长时间放在对象存储里，需要用的时候还能读出来回放。

还有一类是物联网设备数据接入。海量设备持续上报状态，服务器端把数据接入Pulsar，再分流给规则引擎、实时监控和离线存储。多租户在这里很实用——不同设备厂商的数据天然隔离，互不干扰。

如果现场有人提到这些场景，基本可以判断不是纸上谈兵，因为这几类都是Pulsar被大规模验证过的典型路径。

3.3 开发者和学生分别能从展位带走什么

对不同身份的人，开源集市的“收获”完全不同。

如果你是后端开发者或架构师，展位最值得带走的不是贴纸，而是一份“如果我要上生产环境，该注意什么”的清单。现场问一句“你们生产环境集群规模多大、版本号多少”，得到的回答很可能比官网推荐配置更贴近实际。有人如果在场，可能会直接告诉你哪些版本有坑、升级时该绕开哪个问题。

如果你是在校学生或者刚入行的新人，展位最大的价值是找到一条参与开源的具体路径。开源项目的交往往往是从很小的事开始的：改一个文档错别字、修一个配置文件示例、在Issue下面回复一个复现步骤。展位上的Contributor很容易成为你的引路人，你可以直接问“我现在只会Java基础，想参与Pulsar，从哪块入手比较合适”。

即使你现阶段不打算提交代码，把展位上的架构海报拍下来、跟人聊半小时、回家照着QuickStart跑一遍，也足够值回这张入场券了。

4. 周末逛开源集市的实用姿势

开源集市的体验好坏，很大程度取决于你怎么逛。同样是两小时，有人只领了一圈贴纸，有人却拿到了换工作级别的行业认知。差别就在逛法。

4.1 去之前花十分钟想清楚你的问题

我强烈建议你在出发前，先花十分钟把下面的表填一遍：

有了这个表，你在展位前开口的第一句话就不再是“你们是干嘛的”，而是“我们有个XX场景，最近想用Pulsar解决，想请教一下”。后者能得到的有效信息量，是前者的十倍。

这个准备真的很有用。我见过不少人把开源集市逛成了“随机聊天”，每一个展位聊五分钟，聊完什么都没记住。带着问题逛，才能从一个展位里聊出深度。

4.2 现场交流的三条黄金法则

第一，先交代自己的背景再提问。不要一上来就甩一个巨大的问题，比如“Pulsar和Kafka到底怎么选”。先说你来自什么行业、团队规模多大、现在遇到什么瓶颈，这样对方才能给出有针对性的建议。

第二，尽量问具体场景，不要问抽象比较。抽象比较的答案你也记不住，具体场景的答案你回去直接能用。

第三，聊得不错就留个联系方式，但最好让对方记住你是谁。不要只扫个微信就算完，可以在加微信的时候补一句“我是今天问XX问题的那个开发者，后续有问题能不能再请教”。这样对方回去翻通讯录时，还能想起你们聊过什么。

4.3 一天时间怎么安排

开源集市通常和大会议程并行，你不会缺参与时间，但会缺“分配时间”。我的建议是：上午先把想听的主论坛演讲听完，中午到下午留给集市，这时候各展位的人比较齐，也容易抓到核心成员聊天。

到了自己的目标展位，如果发现围了一圈人，不要挤在前排，先站在后面听两轮别人怎么问。你会发现很多信息已经被其他人问出来了。等人流稍退，再上前补问自己专属的问题。

如果你是跟同事一起来的，可以分头行动：一个人去听技术演讲，另一个人驻守集市收集资料。事后交换信息，效率最大化。带小朋友或者对技术不太了解的朋友来，也可以让他们先去互动区玩，等技术交流告一段落再汇合。

5. 这周末到不了现场，怎么把Pulsar学明白

肯定有不少人周末有事来不了现场，别着急，Pulsar的资料没有你想象中那么难啃。关键是找对路径，别一头扎进源码里。

5.1 官方路线：文档、源码、视频三管齐下

Pulsar的学习资料大致分三层：

第一层是官方文档的Concepts部分。这部分把核心概念讲得比较清楚，会分别介绍Broker、BookKeeper、Topic、Subscription，每个概念都会配图。建议一天内集中读完，不需要全记住，留个印象就行。

第二层是源码阅读。如果你有Java基础，可以从Pulsar Broker模块的入口开始，顺着消息写入的路径往下追。刚开始不要求读懂全部，能把“生产者发消息Broker转给BookKeeper写入Ledger”这条链路跑通，架构理解就会上一个台阶。

第三层是视频资源。Pulsar社区有专门的Pulsar Summit技术峰会，演讲录像在B站、YouTube和官网都能找到。其中关于设计和迁移的talk质量很高。

5.2 本地二十分钟跑起一个单机Pulsar

学消息中间件最快的途径，永远是亲手把服务跑起来。Pulsar提供了很好的单机模式，一条Docker命令就能启动：

bash复制docker run -d \
  --name pulsar \
  -p 6650:6650 \
  -p 8080:8080 \
  apachepulsar/pulsar:3.3.1 \
  bin/pulsar standalone

启动之后先等一下，看到“Successfully started”字样就说明就绪了。然后进入容器操作：

bash复制docker exec -it pulsar /bin/bash

创建自己的租户和命名空间：

bash复制bin/pulsar-admin tenants create my-tenant
bin/pulsar-admin namespaces create my-tenant/my-namespace

在一个终端里启动消费者，持续监听消息：

bash复制bin/pulsar-client consume 'persistent://my-tenant/my-namespace/my-topic' \
  --subscription-name my-sub

另开一个终端，往这个Topic里发消息：

bash复制docker exec -it pulsar /bin/bash
bin/pulsar-client produce 'persistent://my-tenant/my-namespace/my-topic' \
  --messages "hello, pulsar" --count 10

看到消费端把十条消息都打出来，你的Pulsar入门就算正式完成了。这个过程会用到Docker和基本的命令行知识，对没接触过分布式系统的新手也能搞定。

5.3 从社区获得学习支持的正确姿势

一个常见的误区是：学开源项目时遇到问题就想着自己硬扛，或者去一堆群里发问。实际上社区的支持效率远比你想象的高，前提是你用对方法。

遇到问题先搜官方文档和GitHub Issue，很多基础问题早就有人问过了。然后可以去Pulsar的邮件列表或Slack提问，但提问时带上完整信息：你的版本号、启动参数、完整报错日志，最好还有你已经尝试过的排查步骤。这样别人可以快速定位，你也更容易得到有价值的回复。

如果你看完文档和代码觉得某个地方写得不够清楚，可以直接去GitHub上开Issue说明你的困惑，或者直接提一个改进文档的PR。不要觉得自己是新手不配提PR，文档优化恰恰是新手参与开源最友好的入口。

我在实际参与开源社区的过程中体会很深的一点是：进入一个陌生项目最好的方式，不是先读完全部源码再动手，而是先让自己成为“使用者”，再顺着使用中遇到的问题一步步往深处走。Pulsar的文档体系和社区氛围对新手已经足够友好，缺的只是你迈出第一步。

如果你这周末正好在会场附近，强烈建议去开源集市逛一圈，到Pulsar展位前坐下来聊十分钟。不用准备太多，带着你的业务场景和上面那几个问题去就行。聊完你会发现，开源项目真正吸引人的地方，从来不只在代码里，还在这些面对面的交流中。我大概率也会在那边，遇见的话，欢迎过来打个招呼。