一、先问Kafka 不够用吗Kafka 在日志、指标、事件流场景已经是事实标准但它有几个结构性短板分区即存储分区数量直接决定吞吐和扩展性扩分区要迁移数据多租户弱一个 topic 抖动容易影响同集群其他业务队列模型缺失Kafka 本质是发布订阅 日志做不到一条消息被多个消费组独立消费且各自维护进度并支持重放/跳过的队列语义跨地域复制复杂MirrorMaker 配置繁琐Pulsar 正是冲着这些点设计的。但它不是全面碾压——很多场景 Kafka 依然更合适。下面看本质。二、架构根本差异Kafka耦合架构Producer ──▶ Broker(分区副本) ──▶ Consumer │ 本地磁盘文件(segment)Broker 既是计算网络/协议也是存储本地磁盘文件。分区数 并行度 物理文件数。Pulsar计算存储分离Producer ──▶ Broker(无状态) ──▶ BookKeeper(存储) │ │ │ Ledger(分片, 跨节点副本) ▼ ConsumerBroker 无状态只负责协议和路由挂了秒级切换BookKeeper 管存储数据按 Ledger 分片跨节点多副本ZooKeeper/etcd管元数据这种分离带来一个关键能力扩容 Broker 零数据迁移因为存储不在这层。三、消息模型差异这是最容易被忽视但最影响选型的点。模型KafkaPulsar发布订阅✅✅队列(Queue)❌靠消费组模拟✅ 原生消费模式消费组共享一个 offset订阅独立支持 Exclusive/Shared/Key_Shared/Failover消息确认offset 提交单条 ack可累积重放按 offset 重置按 subscription 重置更灵活Pulsar 的Subscription模型让多个业务各看各的进度、互不影响、还能单独跳过死信成为原生能力Kafka 要自己在外围折腾。四、压测实测环境3 节点集群8c16g/节点 SSDProducer 16 线程消息 1KB。指标Kafka 3.7Pulsar 3.3说明峰值吞吐 (msg/s)110 万95 万Kafka 略高存储耦合少了一次网络跳P99 生产延迟8 ms12 ms差 4msBookKeeper 多一跳写入P99 消费延迟15 ms14 ms基本持平单节点故障切换秒级依赖副本同步亚秒级Broker 无状态Pulsar 优势明显扩容 Broker需 reassign 分区分钟~小时秒级无状态零迁移Pulsar 优势明显多租户隔离弱同集群互相影响强tenant/namespace 层级Pulsar 原生结论纯吞吐/延迟 Kafka 略优 5-15%但弹性、多租户、故障切换 Pulsar 显著更强。五、维度对比总表维度KafkaPulsar胜出吞吐极高极高平延迟低低略高Kafka扩展性扩分区麻烦秒级扩 BrokerPulsar多租户弱强(tenant/ns)Pulsar队列语义无原生Pulsar跨地域复制MirrorMaker(繁)Geo-replication(原生)Pulsar生态/周边极丰富成长中Kafka运维复杂度低成熟中多组件Kafka社区/资料海量较少Kafka六、选型决策树经验法则日志管道、事件溯源、已有 Kafka 栈 →Kafka云原生平台、多租户 PaaS、IoT 海量设备接入、需要队列语义 →Pulsar七、踩坑记录问题框架现象解决BookKeeper 磁盘打满Pulsar写入阻塞配diskUsageThreshold告警 独立磁盘ZooKeeper 抖动拖垮集群PulsarBroker 失联用 etcd 元数据服务新版支持分区数过多Kafka文件句柄爆炸控制单 Broker 分区数 4000Consumer rebalance 风暴Kafka消费暂停用 CooperativeStickyAssignor参考前面文章消息乱序两者Key 没设对按业务 key 分区跨地域延迟高Pulsar复制慢调replicationCluster 带宽八、总结Kafka 和 Pulsar 不是新替旧而是两种架构取向耦合 vs 分离纯性能 Kafka 仍略优且生态无敌弹性/多租户/队列语义 Pulsar 胜出选型别跟风日志管道用 Kafka平台级多租户用 Pulsar两者都能扛百万级吞吐真正的差异在运维模型而非性能指标下一篇回到我们最硬的差异化——Edge AI 全栈。周五的 ④ 篇给 IoT 诊断系统加上记忆用向量数据库 RAG 让诊断更聪明。往期回顾Kafka acks 机制性能实测acksall 在百万级吞吐下的延迟代价有多大Kafka 深度解剖 ①StickyAssignor 分区分配策略Kafka 深度解剖 2消费者组再均衡 Rebalance 全流程