稗官无印不知道大家有没有这种感觉：这几年聊到消息中间件，再也不像前几年那样只有Kafka一个声音，团队里做技术选型时讨论得越来越细。是选Kafka保持“主流”，还是把目光转向Apache Pulsar，用存算分离的思路来应对更复杂的业务压力？这个问题我反反复复被问到过，也是每次开源活动上互动最热烈的环节。刚好COSCon‘25的同场活动Pulsar Developer Day议程放了出来，作为一个从0到1摸过Pulsar、也在生产环境里踩过不少坑的人，我觉得有必要结合这个消息中间件领域的动态，把Pulsar到底适合谁、能解决什么问题、实际跑起来有哪些门道，系统性拆一遍。无论你是正在做技术选型，还是已经在用Pulsar但想找更多实践参考，这篇内容应该都能帮上忙。
这次Pulsar Developer Day最大的价值不在于告诉你Pulsar“很牛”，而是把消息中间件的底层原理、真实业务场景、以及社区沉淀的运维经验集中摆出来。我始终认为，看技术会议不能只看热闹，关键是想清楚一件事：它解决了我的什么问题，别人踩过的坑我要怎么绕过。所以下面我不去逐条复述议程表，而是从我的实际经验出发，把Pulsar值得关注的特性、部署调优时的关键参数、以及日常运维最容易翻车的几个隐蔽问题，掰开揉碎讲清楚。
1. 消息中间件选型进入深水区，Pulsar为什么值得被认真对待
1.1 从Kafka到Pulsar，大家在纠结什么
先说一个我自己亲身经历的场景。之前在一家日活千万级的平台做技术架构升级，消息链路承担了订单事件、用户行为日志、风控实时计算、数据同步四类核心流量。早期用的Kafka集群规模一路增长，整个团队最怕的就是两件事：一是Broker节点磁盘故障导致分区不可用，二是扩容时Rebalance引发的长时间分区不可用。这些痛点是Kafka架构本身带来的，它把分区的存储和服务的状态绑在一起，数据落在本地磁盘，想扩展存储能力或者做平滑的节点升级，操作成本和风险都不小。很多团队在Kafka集群上百个节点之后都会遇到类似瓶颈，这也是Pulsar开始被频繁提起的原因。
Pulsar最核心的差异在于它把“计算”和“存储”分开设计和独立扩展。Broker不保存数据，只负责消息的路由、订阅管理、各项协议处理，真正干存储的是一套叫Apache BookKeeper的底层系统。这么做带来的直接好处，就是任何Broker节点都可以随时增减，因为底层数据并不依赖这些节点存在。我在测试环境里验证过，干掉一个Broker节点，只要元数据服务还在，生产消费几乎不受影响，数据也不会丢。这种架构基因上的不同，决定了它在弹性伸缩、跨地域复制、多租户隔离这些场景下的表现，和Kafka走的是完全不同的路子。
但我不建议团队仅仅因为“Pulsar架构听起来更先进”就盲目切换。消息中间件选型本质上是对团队运维能力、业务模型和长期规划的综合考量。Kafka的优势在于生态成熟、人力资源好找、周边组件齐全；Pulsar的优势在于更现代的架构设计，尤其当你对“存储成本”和“数据弹性”有较高要求时。这里可以把Kafka理解为一家生意火爆但场地固定的实体店，客人多起来就只能不断在店里加椅子；Pulsar更像是仓库和门店分离的连锁模式，门店不够就开新店，仓库压力大就单独扩仓库，互不拖累。
1.2 Pulsar到底拿什么解决实际问题
围绕着Pulsar的技术讨论虽然多，真正落到实际业务上，它出众的优势集中在几个具体方向。第一是多租户能力，你可以用租户和命名空间把不同部门、不同环境、不同优先级的数据彻底隔离开。以前在公司里，订单组和数据组共享一套Kafka，互相影响的时候协调成本极高。改成Pulsar之后，用不同的租户隔离资源和配额