Kafka vs Pulsar 消息队列性能对比：百万级吞吐下的延迟、持久化与运维成本复盘
Kafka vs Pulsar 消息队列性能对比：百万级吞吐下的延迟、持久化与运维成本复盘
一、技术选型的岔路口：Kafka 的统治地位和 Pulsar 的计算存储分离
团队的消息基础设施承担着日均 120 亿条消息的吞吐量，峰值 QPS 约 15 万。现有的 Kafka 集群（12 个 Broker，128 分区/Topic）在运行两年后逐渐暴露出几个结构性问题：Topic 扩容需要手动 Rebalance 分区且耗时长（>4 小时）；冷数据（3 天前）和热数据共享同一存储层，冷数据占用大量 Broker 本地磁盘却很少被读取；跨数据中心复制需要 MirrorMaker 额外组件。
Apache Pulsar 的架构设计——计算存储分离——理论上有解决方案。BookKeeper 作为存储层可以独立扩缩容，Broker 作为计算层可以在流量峰值时水平扩展而不移动数据。但架构优势不等于实际性能优势，需要基于实际业务 Profile 做对等 Benchmark。
二、吞吐量与延迟的 Benchmark 对比
测试环境：8 节点集群（16C32G + 2TB NVMe SSD），10GB 网络。每个 Topic 64 分区，消息体 1KB，异步发送 ACK=1。
| 场景 | Kafka | Pulsar | Pulsar 优势 |
|---|---|---|---|
| 单 Topic 吞吐（1 Producer） | 120 MB/s | 155 MB/s | +29% |
| 单 Topic 吞吐（10 Producer） | 580 MB/s | 720 MB/s | +24% |
| 10 Topic × 10 Producer | 1.2 GB/s | 1.45 GB/s | +21% |
| P50 延迟（稳定） | 1.2ms | 0.8ms | -33% |
| P99 延迟（稳定） | 8.5ms | 5.2ms | -39% |
| P99 延迟（分区 Rebalance 期间） | 350ms | 12ms | -97% |
最显著的差异出现在 Rebalance 期间的延迟稳定性上。Kafka 在分区迁移时会出现消费中断（Consumer Group Rebalance 的 Stop-The-World 效应），P99 从 8.5ms 飙升至 350ms。Pulsar 的 Broker 无状态设计使得 Rebalance 几乎不影响在途消息的延迟。
三、存储层的成本对比
Kafka 的本地存储模式在纯吞吐场景下效率高，但在冷热数据混合的场景中产生了隐性成本：
# Kafka 数据保留策略：所有分区统一按时间清理 # Topic 的日志段文件无法区分"热数据"和"冷数据" log.retention.hours=72 # 所有分区保留 72 小时 # 问题：前 24 小时的数据（热数据）被高频读取， # 后 48 小时的数据（冷数据）几乎不读但占用了同级 SSD 空间Pulsar 的分层存储（Tiered Storage）自动将冷数据卸载到对象存储（S3/MinIO）：
| 存储指标 | Kafka（全 SSD） | Pulsar（SSD + S3） | 节约 |
|---|---|---|---|
| SSD 使用量（7 天数据） | 40 TB | 12 TB | -70% |
| 对象存储使用量 | 0 | 28 TB | — |
| 月存储成本 | ¥42,000 | ¥18,500 | -56% |
| 冷数据读取延迟 | 8ms | 80ms | +10x |
Pulsar 的优势在于冷数据读虽然慢（+10x），但冷数据本身的读取频率极低（<0.1% 的消息回读），多出的 72ms 延迟在可接受范围内。
四、运维复杂度与故障恢复
| 运维场景 | Kafka | Pulsar |
|---|---|---|
| 集群扩容 | 新 Broker 加入后需手动 Rebalance，耗时 4~8 小时 | Broker 无状态，新节点加入后立即分担负载 |
| 磁盘故障恢复 | 需从副本 Copy 全部数据（TB 级），耗时数小时 | 仅 Copy 故障磁盘上活跃的 Ledger（GB 级），耗时 10~20 分钟 |
| 跨数据中心复制 | 需要 MirrorMaker 2.0 组件，独立维护 | 原生 Geo-Replication，Broker 内置 |
| 监控指标数量 | 约 150 个 MBean | 约 400 个 Metrics |
Pulsar 的运维优势在计算存储分离架构中体现明显，但它的监控指标数量是 Kafka 的 2.7 倍（400 vs 150），运维团队的初期学习成本更高。
五、总结
Kafka vs Pulsar 的选择不应基于口号，而应基于团队的优先级：
- 如果弹性伸缩是最高优先级 → Pulsar：Broker 无状态的秒级扩容在流量波动剧烈的场景中价值显著；
- 如果冷数据存储成本是最高优先级 → Pulsar：分层存储可以将存储成本降低 56%，但冷数据查询延迟增加 10 倍；
- 如果运维团队对 Kafka 有深度积累 → 继续 Kafka：Pulsar 架构优势在 4 人以下的小团队中可能被学习成本所抵消；
- 如果 Rebalance 容忍度低 → Pulsar：Kafka 的 Rebalance 是"Stop-The-World"式的，Pulsar 的计算存储分离几乎消除了这个痛点。
推荐路径：新项目或计划大规模扩容时考虑 Pulsar；已有 Kafka 深度积累的团队先优化 Kafka 配置（增大replica.fetch.max.bytes、调优num.network.threads），不到非换不可的地步不要贸然迁移。