每月花2万在Kafka上，我开始怀疑人生
2025年，我们的Kafka集群每月成本超过2万人民币（3个broker + EBS存储 + 跨AZ流量费）。而我们的日均消息量只有10亿条，峰值吞吐量200MB/s。
“Kafka是行业标准，贵是应该的。"——这是运维团队给我的回答。直到我看到了Redpanda的benchmark：同样的硬件，吞吐量是Kafka的6倍。
“是不是Kafka的替代品已经成熟了？“我决定做一次公平的实测。
四个选手，同一个测试场景
选手：
- Apache Kafka 3.9（Java生态，行业标准）
- Redpanda 24.2（C++重写，Kafka协议兼容）
- WarpStream 1.0（Go实现，零本地磁盘，S3直写）
- NATS 2.11（Go实现，JetStream持久化，极致轻量）
测试环境： AWS i4i.2xlarge（8 vCPU, 64GB RAM, NVMe SSD），3节点集群。
测试场景： 1KB消息，3副本，acks=all（最高可靠性），1个生产者+1个消费者，100分区。
吞吐量对决：Redpanda碾压，WarpStream有惊喜
| 消息队列 | 吞吐量 (MB/s) | 相比Kafka |
|---|---|---|
| Redpanda | 820 | 6.3x |
| WarpStream | 310 | 2.4x |
| Kafka | 130 | 1.0x |
| NATS JetStream | 480 | 3.7x |
Redpanda的C++实现展现出了碾压级的性能优势。同样的硬件，6倍于Kafka的吞吐量。这不是微优化，是架构选择带来的质变。Redpanda用线程-per-core模型替代了Kafka的线程池模型，消除了上下文切换开销；用Raft替代了ZooKeeper，简化了元数据管理。
WarpStream的表现让我意外。它的架构完全不走寻常路：数据不落本地磁盘，直接写S3，网络层用Zero-Copy RPC。这导致它的延迟上限比Kafka高（下一篇会讲），但吞吐量确实不错，而且它没有本地磁盘故障的风险。
NATS JetStream的吞吐量也超过了Kafka，但注意：NATS默认的流控策略和Kafka不完全对等，在"精确一次"语义下性能会下降约30%。
延迟对决：Redpanda又是第一，但Kafka在P99上反击
| 消息队列 | P50延迟 | P99延迟 | P99.9延迟 |
|---|---|---|---|
| Redpanda | 3ms | 12ms | 28ms |
| NATS JetStream | 5ms | 18ms | 42ms |
| Kafka | 8ms | 25ms | 55ms |
| WarpStream | 12ms | 80ms | 350ms |
Redpanda在延迟上的表现同样优秀。P99延迟只有12ms，比Kafka低了一半。
WarpStream的P99延迟高达80ms，P99.9达到350ms。这是它"零本地磁盘"架构的代价 —— 数据要写到S3，而S3的写入延迟在正常情况下是10-50ms，偶尔会飙到几百毫秒。WarpStream用批量写入和异步确认来优化吞吐量，但延迟是它的阿克琉斯之踵。
如果你的场景对延迟极度敏感（如交易系统），WarpStream不适合。但如果你在做日志收集、数据分析这类"延迟不敏感、吞吐量重要"的场景，WarpStream的零运维成本非常诱人。
运维成本：WarpStream的零运维是真实存在的
| 消息队列 | 月运维成本 | 磁盘故障风险 | 扩容复杂度 |
|---|---|---|---|
| Kafka | ~4000元/节点 | 高 | 高（分区重平衡） |
| Redpanda | ~3000元/节点 | 中 | 中 |
| NATS | ~1500元/节点 | 低 | 低 |
| WarpStream | ~500元/节点 | 零 | 极低 |
Kafka的运维成本主要体现在：ZooKeeper/KRaft管理、分区重平衡、磁盘故障处理、JVM调优。Redpanda不需要ZooKeeper，但仍然是本地磁盘架构，磁盘故障风险存在。
WarpStream的运维成本最低，因为它没有本地状态。Agent挂了，换个新的启动就行，数据都在S3上。这对于小团队来说是一个巨大的吸引力。
NATS的运维成本也低，因为架构简单，配置少，但它的持久化功能（JetStream）在极端情况下（如磁盘满了）的恢复机制不如Kafka成熟。
2026年选型指南
选Kafka，如果你：
- 已经在用Kafka并且运行稳定，迁移风险大于收益
- 需要最成熟的生态（Kafka Connect、ksqlDB、Schema Registry）
- 团队有Kafka运维经验
- 需要精确一次（Exactly-Once）语义 —— 这个在Redpanda和WarpStream上还不够成熟
选Redpanda，如果你：
- 需要极致吞吐量和低延迟
- 正在从Kafka迁移，Redpanda的Kafka兼容协议让迁移成本很低
- 不想管理ZooKeeper
- 预算充足，Redpanda的企业版要付费
选WarpStream，如果你：
- 团队小，不想运维消息队列
- 延迟要求不高（P99 < 100ms可以接受）
- 已经在AWS上，S3成本很低
- 做日志、指标、事件溯源这类场景
选NATS，如果你：
- 需要极致的简单性和低运维成本
- 消息量不大不复杂
- 在做微服务通信（NATS的Request-Reply模式非常适合）
- 不需要Kafka那种"持久化流"的语义
我们的选择
我们把Kafka换成了Redpanda。迁移成本很低（Kafka协议兼容，客户端代码一行不改），性能提升明显，运维负担减轻了50%以上。
但说实话，如果你现在的Kafka集群运行稳定，没有性能瓶颈，没必要换。消息队列是你最不应该折腾的基础设施之一。只有当你真的被Kafka的运维成本或性能问题折磨时，这些替代品才值得你花时间评估。