与 Kafka 对比:同一场景下的吞吐与延迟

先说前提

实测 · 本机执行输出

  RabbitMQ: 4.3.6;Kafka: 4.3.1

两个 broker 都是单节点、本机,客户端语言不同(pika 是纯 Python,librdkafka 是 C),数字主要反映客户端与批量策略,不是 broker 上限的比较。

实测 · 本机执行输出

  RabbitMQ 异步 confirm: 1635 ms  61155 条/秒
  Kafka acks=all linger.ms=5: 47 ms  2135302 条/秒
  Kafka acks=all linger.ms=0: 65 ms  1549576 条/秒

Kafka 追加日志并由客户端批量发送,单节点上发布吞吐比 pika 异步 confirm 的 RabbitMQ 高了 25~35 倍;其中多少来自 broker、多少来自客户端,这里没有拆开。

实测 · 本机执行输出

  RabbitMQ(推送 + confirm):p50 0.60 ms,p99 3.37 ms
  Kafka(acks=all,linger.ms=0,拉取):p50 0.34 ms,p99 5.44 ms

低速率下 p50 都是亚毫秒(0.60 对 0.34 ms),p99 两次运行排名翻转,不下结论。

实测 · 本机执行输出

  RabbitMQ(3 个队列各存一份): 数据目录增长 174 MiB
  Kafka(1 个 topic,3 个 group 共读): 数据目录增长 49 MiB

RabbitMQ 用多个队列做扇出,每个下游存一份;Kafka 的多个消费组共享一份日志。50000 条 1 KB 扇出到 3 个下游:174 MiB 对 49 MiB。

实测 · 本机执行输出

  RabbitMQ 经典队列:第一次读 20000 条,第二次读 0 条(消息被 ack 之后就删除了)
  Kafka:第一个 group 读 20000 条,另一个 group(或重置 offset)再从头读 20000 条(日志保留着,读取不删除)

RabbitMQ 经典队列读完即删,不能重读;Kafka 日志保留,新的消费组可以从头读(RabbitMQ 的 stream 队列也有类似能力)。

与 Kafka 对比

本步的对象

本机 macOS 27 arm64 / RabbitMQ 4.3.6 / Erlang/OTP 28.5 / pika 1.4.4(Homebrew 与临时虚拟环境);所有节点都是本机自己起的 RabbitMQ 进程(127.0.0.1,端口 9500 以上,每个实验独立的数据目录与节点名,不连任何外部服务);命令输出来自真实的 rabbitmqctl 与管理 API,发布与消费用 pika 的真实连接;计时用 time.perf_counter,数字每次运行会有小幅抖动。Kafka 用 Homebrew 的 4.3.1,本机单节点 KRaft(broker 与 controller 合一,1 分区、1 副本),客户端 confluent-kafka 2.16.0;RabbitMQ 为经典队列,持久化,pika 异步 confirm;延迟是单次 2000 条的 p50 / p99,p99 波动大;磁盘大小用 du -sk
没有验证:多分区 / 多消费者下的 Kafka 吞吐扩展;多副本 Kafka(acks=all 需要 ISR 同步)与 3 副本 quorum 队列的比较;RabbitMQ stream 队列与 Kafka 的比较(这里只比了经典队列);同一语言客户端下的公平对比;消费吞吐;运维复杂度、生态、事务语义等非性能因素;保留策略与压缩