Kafka 与 RabbitMQ 选型对比

虽然两者都是“消息队列”，但设计哲学、适用场景、性能特征、可靠性机制完全不同。选型错误会导致架构瓶颈或运维灾难。

对比维度一览表

如何选型？

Kafka ：

• 需要高吞吐量（如用户行为日志、点击流、IoT 数据）
• 需要持久化存储+重放能力（如做离线分析、CDC）
• 需要对接流处理引擎（Flink/Spark Streaming）
• 消息允许秒级延迟
• 有专职运维或云平台支持

RabbitMQ ：

• 需要低延迟、实时响应（如支付回调、短信通知）
• 需要复杂路由规则（如按 Header、Topic、Fanout 分发）
• 消息量不大（< 10 万/秒），但对消息模型灵活性要求高
• 希望快速部署、图形化管理
• 业务系统解耦、异步任务、RPC 场景

举个例子：

• 用户下单 → 发送“订单创建”事件 → 更新库存、发券、通知用户 → 选 RabbitMQ（低延迟、可靠、灵活路由）
• 用户点击行为 → 实时收集 → 实时推荐 + 离线分析 → 选 Kafka（高吞吐、可重放、对接 Flink）

消息可靠性保证机制

无论选哪个 MQ，消息不丢、不重、有序（如需） 是核心诉求。我们从三个层面保障：

生产者端可靠性（消息不丢）

Kafka：

• acks 参数控制：
  • acks=0：不等待确认 → 吞吐高，可能丢消息
  • acks=1：Leader 确认 → 平衡性能与可靠性
  • acks=all（或 -1）：所有 ISR 副本确认 → 最安全，性能最低
• 重试机制：retries + retry.backoff.ms
• 幂等生产者（enable.idempotence=true）：避免重试导致重复（需配合 acks=all）
• 事务支持（Kafka Transactions）：实现跨分区原子写入（用于 Exactly-Once 语义）

RabbitMQ：

• 发布确认模式（Publisher Confirms）：
  • 异步监听 basic.ack / basic.nack
  • 可配合事务（性能差，不推荐）或 Confirm 模式（推荐）
• 消息持久化：delivery_mode=2 + 队列 durable=true
• 生产者重试 + 本地缓存未确认消息（防止网络抖动）

最佳实践：生产者本地记录“待确认消息”，收到 ACK 后清除，超时/NACK 则重发或告警。

Broker 端可靠性（消息不丢）

Kafka：

• 副本机制（Replication）：每个 Partition 有多个副本（Leader + Follower）
• ISR（In-Sync Replicas）：只有同步副本才参与选举和写入确认
• min.insync.replicas：控制最少同步副本数（如设为 2，配合 acks=all 保证至少 2 副本写入）
• 日志刷盘策略（flush.messages, flush.ms）→ 但通常依赖 OS PageCache，性能优先

RabbitMQ：

• 镜像队列（Mirrored Queues）：队列内容在多个节点复制
• 持久化队列 + 持久化消息（写磁盘）
• 但注意：RabbitMQ 持久化性能较差，高吞吐场景慎用

注意：Kafka 默认不立即刷盘，靠副本机制保证可靠性；RabbitMQ 持久化会显著降低吞吐。

消费者端可靠性（消息不丢不重）

通用机制：

ACK 机制（手动确认）

• 消费者处理完业务逻辑后，手动发送 ACK，Broker 才删除消息
• 若消费者崩溃/超时，消息重新入队（或进死信队列）

重试机制

• 本地重试（try-catch + sleep + 重试 N 次）
• 重试队列（把失败消息发到另一个队列，延迟消费）
• 指数退避 + 最大重试次数

死信队列（DLQ - Dead Letter Queue）

• 当消息多次重试失败、被拒绝、TTL 过期，自动转入 DLQ
• 用于人工排查、修复后重新投递
• Kafka：无原生 DLQ，需自建 Topic 或用 Kafka Streams 处理
• RabbitMQ：原生支持，通过参数 x-dead-letter-exchange 配置

幂等消费（防重复）

• 因网络抖动、ACK 丢失、消费者重启，可能导致消息重复
• 解决方案：
  • 数据库唯一键约束（如订单号）
  • Redis 分布式锁/SETNX（带过期时间）
  • 业务层状态机（如“订单状态=已支付”，重复消息直接忽略）

消费者最佳实践：

1. 手动 ACK
2. 先处理业务，再 ACK（避免处理失败但已 ACK）
3. 业务逻辑幂等化
4. 失败消息进重试队列 → 最终进死信队列
5. 监控消费延迟、积压、失败率

总结：