周五晚上九点多，我还在客厅里清点第二天要带去的物料。桌上摊着四件印了 Pulsar Logo 的速干 T 恤、两盒徽章、半袋贴纸，外加一台本地跑着 Pulsar 集群的笔记本。我是 Apache Pulsar 社区里负责周边工具链维护的志愿者，这周末的任务，是替项目在 COSCon'25 开源集市里站好这个“摊”。
说实话，报名的时候我把它想得很简单——无非是找个桌子，摆点周边，跟路过的人聊聊项目。可真正筹备起来才发现，一个开源项目在线下集市里怎么把自己讲清楚、怎么把路过的人变成社区的长期参与者，这中间全是细节。这篇文章我就把自己这两天的完整经历、踩过的坑、以及事后复盘出来的经验整理出来。如果你也打算带着自己参与的项目去开源集市摆摊，或者单纯好奇开源社区线下活动是怎么运作的，这篇应该能给你一些参考。
1. 开源集市不是“发传单”，先想明白 Pulsar 来这里图什么
1.1 为什么一个 Apache 顶级项目也要去线下摆摊
很多人不理解：代码都在 GitHub 上，issue 都写在仓库里，社区讨论有邮件列表、有 Slack，为什么还要专门跑到线下，租个摊位跟人面对面聊天？
我的看法很简单——线上协作解决的是“做事”的问题，线下见面解决的是“信任”的问题。你给一个没打过交道的人提 PR，对方可能会犹豫；但在集市上聊过十分钟，交换过微信，回去之后再提 PR，双方的心理门槛都低很多。尤其是像 Pulsar 这种偏基础架构的消息系统，使用者往往要把它放进自己的核心链路里，信任感的建立非常关键，而线下面基是构建这种信任最高效的方式。
开源集市本质上就是把开源项目从代码仓库里拽出来，放到一个真实的人来人往的广场上。路过的开发者能看到项目的维护者不是一群神秘的远程 ID，而是活生生的人；项目的维护者也能直接听到使用者的真实反馈，而不是等 issue 里的截图和日志。
1.2 摆摊前我们给这次活动定了三个具体目标
既然决定要参加，就不能让这两天变成“发传单 + 送贴纸”的流水线。筹备会上我们给这次出摊定了三个可量化的目标，事后证明这几个目标帮了大忙：
- 让至少 50 位对 Pulsar 完全陌生的人建立正确的第一印象，别让他们带着“这不就是另一个 Kafka 吗”的误解离开。
- 现场收集至少 20 个真实的使用场景或问题，无论对方是用过还是没用过，这些问题带回去就是社区改进的素材。
- 找到 3 到 5 个有潜力的贡献者候选人，哪怕只是聊完主动说“我回去看看源码”的人。
这三个目标一出，摊位的气质就不一样了。我们不再是单向输出，而是带着 listen 的心态去做交流，整个摊位的调性都变了。
1.3 两周的准备：分工、预算和时间线
开源集市的摊位一般由主办方提供基本设备和桌子，但其他东西都得自己准备。我们的分工是这样拆的：
- 技术值班：每天固定两人守在摊位，负责 Demo 演示和深度技术问答。
- 周边管理：负责贴纸、徽章、T 恤的发放登记，控制物料节奏。
- 互动区负责人：引导访客做小任务、解答新手问题，让摊位前不冷场。
预算方面，周边物料是大头。T 恤定制要看工艺和数量，徽章和贴纸反而便宜，但设计费别省。对了，经验之谈，物料定制一定要提前两周以上，预留出打样和快递的意外时间。我们就因为徽章打样多花了三天，差一点没赶上活动。
2. 摊位设计：让路人在五秒内搞懂 Pulsar
2.1 视觉物料：少放字，多用图讲故事
集市上的摊位挨着摊位，路人的注意力是以秒为单位计算的。摆一堆密密麻麻的技术介绍展板，没人会停下来看。我们最后只保留了三个视觉元素，分别回答三个问题：“这玩意儿解决什么问题”、“它和别的消息系统有什么核心区别”、“我能怎么参与”。
第一个问题，我们画了一条消息从生产者发出、进入 Broker、落到 BookKeeper、再被消费者拉取的完整流程图，旁边只配了一句话：“消息服务就是把数据从 A 安全地搬到 B，Pulsar 在这个环节上把算力和存储分了家”。第二个问题，我们把 Pulsar 和传统消息系统的架构差异画成了对比图，Broker 无状态、存储走 BookKeeper、支持多租户，全部用图标表达。第三个问题就是我们的大二维码，旁边写着“本周六，欢迎来领你的第一个开源任务”。
三块物料摆在桌上，路过的人扫一眼就能抓住重点。真别做那种三米长的大展板，字多到根本没人看，最后全是你自己站在那里念。
2.2 现场 Demo：一屏能跑起来的本地集群
集市现场最怕的是断网。我们决定不依赖会场 Wi-Fi，所有演示都用本地环境。跑一个 Pulsar standalone 集群其实很简单，一条命令的事：
docker run -p 6650:6650 -p 8080:8080 apachepulsar/pulsar:latest bin/pulsar standalone启动之后，我用两个终端分别跑生产者和消费者，往一个 topic 里发一条 JSON 格式的消息，另一个终端立刻能收到。这个效果虽然简单，但对路人理解“消息系统是干什么的”非常直观。
我还准备了一个进阶演示：隔几秒发一条延迟消息，让消费者那边看到消息在指定时间后才被投递。这样就能很自然地带出“Pulsar 自带延时队列”这个特性。整个过程约五分钟，中间没有任何外部依赖，稳定可靠。
选本地集群而不是连云端测试环境，原因很简单：一是现场网络质量没保证，二是谁也不想把自己的测试账号和密码留在展览电脑里。本地 standalone 虽然规模小，但 Broker、BookKeeper、ZooKeeper 这些核心组件都是真的，足以支撑演示。
2.3 互动环节：从“集章打卡”到“真实小任务”
很多开源摊位喜欢搞集章打卡，从资料里随便找几个答案让访客找。这种玩法的好处是热闹，坏处是大家拿完章就走了，完全留不下任何印象。
我们换了一个思路，设计了三档小任务卡片：
- 初级：用一句话说出 Pulsar 的计算存储分离是什么意思。说对了拿一张贴纸。
- 中级：在管理界面里新建一个 namespace，然后在 demo 里往这个 namespace 下发一条消息。完成就拿一枚徽章。
- 高级：猜一条消息从生产到消费，中间会发生几次磁盘写入。能答出来或者能推理出来的，那就是我们想认识的人，直接送 T 恤。
这个设计把互动从“查答案”变成了“动手试”。哪怕初级任务，也要求对方真正理解了才说得出那句话。两天下来，最后一天我们还真的用高级任务钓到一位做存储引擎的工程师，聊得非常投机。
3. 现场两天：五类访客与我的应答思路
3.1 “Pulsar 和 Kafka 到底有什么区别”——用比喻回答最高频的一问
这是被问得最多的问题，没有之一。我的固定答案是：Kafka 是“传送带和仓库建在同一栋楼里”，每条传送带都有自己的仓库，扩容的时候传送带和仓库得一起搬。Pulsar 是“传送带归传送带，仓库归仓库”，传送带（Broker）可以加，仓库（BookKeeper）也可以单独加，两边互不拖累。
接下来再补一点实质内容：Kafka 的分区副本跟 Broker 是同机的，存储跟计算耦合在一起；Pulsar 的 Broker 是无状态的，数据交给 BookKeeper 去落地和复制。这意味着 Pulsar 做容量规划时，可以把计算峰值和存储增长拆开评估，也更容易做分层存储、把冷数据卸到廉价的存储上。
碰到明显有一定技术底子的访客，我还会加上一句：Pulsar 的订阅模型有四种，exclusive、shared、failover 和 key_shared，在消费模式上比传统消费组模型更灵活。不过如果对方没有追问，我不会一次倒太多，免得信息过载。
3.2 “这个东西到底能用在什么业务上”——从场景谈起
技术再强，最终也要落到业务上。我准备了三个最容易讲清楚的例子：
第一个是金融交易核对场景。交易系统要保证消息不丢、能重放、能精确处理，Pulsar 的消息保留机制和持久化架构比较契合这类诉求。第二个是 IoT 设备数据汇聚。一台设备一个 topic，或者按地区一个 namespace，天然的多租户模型省去很多隔离上的麻烦。第三个是订单超时之类的延迟任务。不用再自己维护一套定时任务扫库，发一条延迟消息就行。
不过我也特别强调一点：如果你现在的消息量只有每秒几百条，单机部署一套实现同样功能的方案完全够用了，没必要为了用 Pulsar 而用 Pulsar。技术选型不是选最强的，是选最合适的。这个态度反而让很多人更愿意继续聊下去。
3.3 学生和刚转行的工程师——他们真正想要的是“怎么入门”
现场来了不少学生，尤其是计算机专业的。他们看我们桌上有代码，就停下来问“我没用过你们项目，能学吗”。这种时候最好不要去讲架构细节，而是直接给一条入门路径。
我的建议通常是这样的：先把 standalone 在本地或者容器里跑起来，往里面发第一条消息，感受一下收发的完整链路；然后去看官方文档里的概念章节，把 Broker、BookKeeper、Topic、Subscription 这几个词和实际体验对起来；最后到 GitHub 的 issues 列表里找带 good first issue 标签的任务，从最小的改动开始。
有一位同学当场就问“我不会 Java 能不能参与”，我告诉他 Pulsar 有 Python、Node.js 的客户端，而且社区不只是代码贡献，文档翻译、测试、社区运营都需要人。他很兴奋地加了微信，说回去先把 Python 客户端跑通。
3.4 已经在生产环境用过的人——不要推销，直接讨论
这类访客是最有价值的。他们一般不会问“是什么”，开口就是“我在生产环境遇到过某个问题”“你们的延迟队列在某种场景下表现怎么样”。
跟他们交流，我们的姿态要完全转过来：不是介绍项目，而是虚心收集反馈。有一位做日志系统的老哥跟我们聊了很久跨地域复制和消息堆积的关系，说他的集群偶尔会出现消费积压导致端到端延迟升高。这个真实场景对我非常有价值，我当场给社区里负责这块的 committer 发了条消息，几天后就在讨论组里展开了专项复盘。
摊位上最值得的交流，往往不是我们把项目说得有多好，而是用户把真实的坑交给我们。
3.5 纯粹路过和来领周边的人——快速判断，不浪费精力
集市上难免有人是奔着扫荡周边来的。他们通常会先迅速扫一遍桌上的东西，眼神不会在你脸上停留太久。这种时候聪明做法是不要强留。
我们会递一张贴纸，再用一句话做总结：“这是 Apache 基金会下面的开源消息系统，官网搜一下就找到了。旁边那个 Demo 有兴趣可以看一眼。”对方如果只是点点头，我们就不再追着讲了。开源布道也是稀缺资源配置，把精力和时间给到真正愿意停下来的人，整体效果才会好。
4. 摊位上那些“意外”：故障、尴尬瞬间与临时解法
4.1 开场不到一小时，Demo 环境的磁盘 IO 被打满
第一天上午十点半，我们刚给第一波访客演示完，旁边那台笔记本的风扇就疯狂转起来，终端里开始刷一堆日志报错，topic 列表管理页面打不开了。
我第一反应是容器日志把磁盘写满了。检查后发现，由于演示中反复创建 topic 和发送消息，BookKeeper 的 journal 数据在半小时内攒了不小体积，加上笔记本本来剩余空间就不多，就出问题了。
处理方式很简单：停掉 standalone 进程，清理掉日志和临时数据，再重新启动，同时把发消息频率降下来。但这件事情给我们一个教训——集市 Demo 前一定要在本地压测跑至少两个小时，确认长时间低强度写入下资源占用是健康的。别等到现场当着一堆人的面重启。
4.2 易拉宝被风吹倒，贴纸粘在鞋底
下午人流高峰的时候，旁边摊位的人一转身，把我们的易拉宝撞倒了，哐当一声，牌子摔在桌上，把一盒徽章打翻在地上。我们几个人弯腰捡了半分钟，再抬头发现有个访客鞋底粘走了一张“Pulsar × COSCon”的贴纸，走出两步远自己还没察觉。
这种小意外其实不影响大局，但很打断交流节奏。后来我们把易拉宝换成了那种底座更重的 A 字架，又把所有小物件都收进盒子里，不摊在桌面上任人碰。摊位整洁，反而看起来更专业。
4.3 有人问了一个我们三个值班人都答不上来的问题
第二天下午，有位做实时数仓的工程师问了一个关于 Pulsar 的 backlog 机制和消费者游标在特定故障场景下的一致性细节。这个问题涉及很深的内部实现，我们三个人互相看了一眼，确实拿不准。
我的处理方法是：当场告诉对方“这个问题我记下来了，我回去找相关的 committer 确认后答复你”，并且当面在微信备注里写下他的问题关键词。回去后的周一，我把这个问题丢到社区讨论组，拿到结论后专门整理了一段回复发给对方，附带相关的 issue 链接。
后来这位工程师回复说“你们社区的反应速度让人佩服”，一周后成了我们邮件列表里的活跃参与者。坦诚承认不确定，反而比硬着头皮乱讲更容易赢得信任。
5. 集市结束不是终点：从线下“面基”到线上社区的转化链路
5.1 当晚的动作：分类录入名片和微信备注
两天集市结束，我们回到酒店的第一件事不是吃饭庆祝，而是趁记忆还新鲜，把所有加过微信的访客在通讯录里打好备注和标签。分类大概这样：按身份分“学生 / 工程师 / 技术负责人”，按关注度分“高潜贡献者 / 使用者 / 轻度关注”，再在每个人的备注里写一句交流的要点，比如“对延迟队列感兴趣，生产环境在用”。
这一步非常关键。开源项目的线上社区是一个个 ID，线下聊过之后如果不打标签，回头根本想不起来谁是谁，转化就断了。我们整理完大概有 60 多个有效联系人。
5.2 接下来一个月：跟进、拉群、观察留存
活动结束后两周，我们给高潜贡献者发过一轮消息，把社区里近期适合新人的任务整理成清单发过去，并邀请他们加入贡献者讨论群。
一个月后回看，成果比预想的好：有 7 个人在邮件列表或群里发言，4 个人提交了 PR，其中 2 个已经被合并。这比我们平时纯靠线上自然吸引进来的转化率高了一大截。线下面对面的交流，真的可以把“路人”变成“参与者”。
5.3 下次参展我会调整什么
这次实践让我积累了不少改进想法，列出来给以后自己看，也供其他要参展的项目参考：
- 周边物料少带一半，多腾出的空间带一个自带电池的便携路由，做一个真正完全断网也能跑的局域网 Demo 环境，比什么都靠谱。
- 现场值班两个人就够，三个人反而都闲着。轮班不要按半天切，按两小时一切，保证每个人在摊位上都是精力充沛的状态。
- 互动任务卡片要印得再醒目一点，放在摊位最前面，不要让人以为只是摆着好看。
- 准备一份“参与社区第一步”的一页纸，上面就印：跑通命令行、找到 good first issue、加讨论组。很多学生拿到这张纸比拿徽章还开心。
另外我个人最大的体会是：开源集市的主角从来不是展板，也不是技术架构图，而是人。你肯蹲下来跟一个刚入门的同学聊十分钟怎么跑通第一条消息，也许半年之后，PR 列表里就多了一个陌生的 ID。那个 ID，可能就是周六下午在人堆里多看了一会儿 Demo 的年轻人。
