Kafka vs RabbitMQ：消息队列怎么选
消息队列是现代分布式系统的脊梁，承担解耦、削峰、异步任务、事件驱动等关键职责。Kafka 与 RabbitMQ 是当今最主流的两种选择，但很多团队在选型时仍只看吞吐量数字，忽视了语义模型、保留策略、运维成本的根本差异。本文从协议、吞吐、顺序、消费模型、典型业务、生态等维度做出系统对比，并附 Pulsar、NATS、Redis Streams 等替代方案的适用边界。
一、两种截然不同的消息模型
RabbitMQ 是基于 AMQP（Advanced Message Queuing Protocol）的传统消息中间件，核心抽象是 Exchange、Queue、Binding，支持 direct、fanout、topic、headers 多种路由模式。消息被消费者 ack 后即从队列删除，模型接近 RPC 异步化或任务调度，强调灵活的路由控制。
Kafka 是基于分布式日志（distributed log）的事件流平台。消息按 Topic 分区，每个分区是 append-only 日志，消息按 offset 顺序持久化。消费者主动拉取并管理自己的 offset，消息不会因消费而删除，仅按保留策略（时间或大小）过期。这种 log-based 模型让 Kafka 天生适合事件溯源（event sourcing）、CDC、流处理。
二、协议与传输层
RabbitMQ 默认使用 AMQP 0.9.1，也支持 STOMP、MQTT、HTTP 插件。AMQP 是有状态会话协议，支持 publisher confirm、consumer ack、prefetch、QoS、事务，灵活性极强。劣势是协议复杂，单连接吞吐受限，cluster 扩展性较弱。
Kafka 使用自定义二进制协议，基于 TCP，多路复用单连接传输大批消息（batching），客户端拉取（pull）模型而非推送。这种设计将吞吐量做到极致：单 broker 节点轻松撑起百万 msg/s。代价是协议较底层，应用层需自己实现重试、去重、幂等。
三、吞吐量与延迟实测
公开基准与生产经验显示：Kafka 单集群可轻松达到 200 万 msg/s 写入，单消息延迟通常 5-20ms（端到端）；RabbitMQ 单实例峰值约 5-10 万 msg/s，延迟可低至 1-2ms。Kafka 强在批量、长链路、磁盘顺序写；RabbitMQ 强在小消息、低延迟、复杂路由。
常见误区：以为 RabbitMQ 永远慢于 Kafka。实际上对于一个发短信、发邮件、订单状态推送类的低 TPS 场景，RabbitMQ 端到端延迟更低且配置更简单，Kafka 反而过度设计。选型应从业务负载特征出发，而非简单比较 benchmark 数字。
四、消息顺序与分区
Kafka 在单分区内严格有序，跨分区无全局顺序保证。要保证某用户的所有事件有序，必须用 user_id 作 partition key，让同一用户的消息总打到同一分区。这意味着分区数决定了并发上限：100 个分区最多 100 个消费者并行。
RabbitMQ 单队列内 FIFO 有序（前提是单消费者），但当多个消费者订阅同一队列做并行消费时，顺序无法保证。要实现跨消费者顺序需引入 consistent hash exchange 或单线程模式，复杂度较高。所以严格事件顺序场景，Kafka 更天然。
五、保留策略与回放
这是两者最本质的差异之一。Kafka 默认保留 7 天（可调），消息消费后仍存在，新消费者可从最早 offset 重新消费历史数据。这一特性使 Kafka 成为事件溯源、CDC、流计算（Flink、Spark Streaming）、数据湖入仓的核心组件。
RabbitMQ 消息一旦被 ack 即删除，无法重放。要实现回放需依赖业务侧持久化或额外的 stream queue（RabbitMQ 3.9+ 引入了类 Kafka 的 stream 类型，部分弥补此短板）。如果业务需要重新计算、补偿历史数据、灾备回放，Kafka 是更好选择。
六、典型应用场景对比
Kafka 适合：日志聚合、CDC（Debezium）、用户行为流、订单事件流、IoT 数据接入、流式计算、跨系统数据同步、事件溯源、Read-replica 解耦。它是大数据平台与实时数仓的事实标准。Apache Flink、Apache Spark、ClickHouse Kafka Engine 等都把 Kafka 当作输入源。
RabbitMQ 适合：异步任务队列（发邮件、发短信、生成报表）、跨服务 RPC 异步化、复杂路由（不同租户路由到不同消费者）、低延迟通知、订单与库存解耦、Worker 扩缩容场景。它在 Web 后端中常作为 Celery、Sidekiq、Bull 等任务框架的传输层。
七、运维成本与可观测性
Kafka 的运维曾经依赖 ZooKeeper，导致复杂度高。Kafka 3.x 推出 KRaft 模式，自带 Raft 共识，移除 ZooKeeper 依赖，运维大幅简化。但 broker 容量规划、分区均衡、磁盘 IO 监控、topic 权限管理仍是长期挑战。云托管（Confluent Cloud、AWS MSK、阿里云 Kafka）可显著降低门槛。
RabbitMQ 集群模式较为简单，management plugin 自带 Web UI，监控指标完善。但跨数据中心复制（federation、shovel）配置复杂，新版 quorum queue 已替代旧的 mirrored queue 提供更强一致性。整体来看 RabbitMQ 中小规模运维更友好，Kafka 大规模运维收益更明显。
八、Pulsar / NATS / Redis Streams 等替代方案
Apache Pulsar 是 Kafka 的强力挑战者：存算分离架构（broker + bookkeeper）、原生多租户、跨地域复制内置、灵活订阅模式（exclusive / shared / key_shared）。在多租户 SaaS、地理分布部署中表现优于 Kafka。生态成熟度与社区规模仍稍逊一筹。
NATS（含 JetStream）主打超低延迟与简单运维，单二进制部署，适合微服务、IoT、边缘计算。Redis Streams 适合已用 Redis 的中小项目，无需额外组件即可获得轻量消息流。NSQ、Pulsar、ActiveMQ Artemis 都有各自适用边界。新项目建议先评估业务规模、团队熟悉度、生态工具，再在 Kafka / RabbitMQ / Pulsar / NATS 中决策。
常见问题
Kafka 一定比 RabbitMQ 快吗？
Kafka 在大批量、顺序写、单 Topic 高吞吐场景下确实快得多（百万 msg/s 级别），但小消息低延迟、复杂路由场景 RabbitMQ 端到端延迟可低至 1-2ms，反而更快。两者面向不同负载特征。
消息绝对不能丢，应该选哪个？
两者都能做到不丢消息：Kafka 通过 acks=all + min.insync.replicas、RabbitMQ 通过 publisher confirm + 持久队列 + mirrored / quorum queue。关键在配置正确、生产端做幂等与重试。
使用 Redis Streams 能否替代 Kafka？
小规模、低 TPS（小于 5 万 msg/s）、消息保留时间短的场景可替代，并简化运维。但 Kafka 的多分区、多副本、长保留、生态工具（Connect、Streams）是 Redis Streams 短期内难以追赶的。
Kafka 的消费组和 RabbitMQ 的队列有啥区别？
Kafka 消费组共享同一 Topic，每个分区只被组内一个消费者消费，offset 由消费者自己管理。RabbitMQ 队列默认每条消息发给一个消费者后即删除，消息消费状态由 broker 管理，模型更接近传统任务队列。
NATS / Pulsar 值得考虑吗？
NATS 适合微服务低延迟通信、IoT、边缘场景；Pulsar 兼具 Kafka 的吞吐与 RabbitMQ 的灵活路由，存算分离架构在多租户场景出色。新项目可优先评估，老项目慎重迁移。