消息队列选型：RabbitMQ vs Kafka vs Redis Streams 的架构差异

先说结论：没有最好的消息队列，只有最适合的消息队列

消息队列的选型是最容易被”跟风”影响的技术决策之一。Kafka 火就上 Kafka，RabbitMQ 稳就上 RabbitMQ，Redis Streams 简单就上 Redis Streams——但选错了，后面的运维代价会很高。

---

1. 核心对比

维度	RabbitMQ	Kafka	Redis Streams
消息模型	队列（消费即删除）	日志（按偏移量读取）	流（按 ID 读取）
吞吐量	万级/秒	百万级/秒	十万级/秒
持久化	磁盘 + 可选内存	磁盘（顺序写入）	磁盘（RDB/AOF）
消费模式	竞争消费	消费者组	消费者组
消息回溯	不支持	支持（按偏移量）	支持（按 ID）
运维复杂度	中	高（需要 ZooKeeper）	低（无需额外组件）
适用场景	任务分发、RPC	事件流、日志聚合	轻量级队列、实时数据

---

2. 选型决策树

需要消息队列？
├── 需要高吞吐量（百万级/秒）？
│   ├── 是 → Kafka
│   └── 否 ↓
├── 需要消息回溯/重放？
│   ├── 是 → Kafka
│   └── 否 ↓
├── 需要复杂路由（Topic → Exchange → Queue）？
│   ├── 是 → RabbitMQ
│   └── 否 ↓
├── 已经有 Redis 了，不想引入新组件？
│   ├── 是 → Redis Streams
│   └── 否 → RabbitMQ（默认推荐）

---

3. 消息可靠性配置

RabbitMQ 可靠配置

// 生产者：开启 Publisher Confirms
const channel = await connection.createConfirmChannel();
await channel.publish('exchange', 'routingKey', content, { persistent: true });
await channel.waitForConfirms(); // 等待 Broker 确认

// 消费者：手动确认
channel.consume('queue', (msg) => {
  try {
    process(msg);
    channel.ack(msg); // 处理成功，确认
  } catch (err) {
    channel.nack(msg, false, true); // 处理失败，重新入队
  }
}, { noAck: false });

Kafka 可靠配置

// 生产者：等待所有副本确认
const producer = new KafkaProducer({
  acks: 'all',      // 等待所有副本写入
  retries: 3,       // 重试 3 次
});

// 消费者：手动提交偏移量
consumer.run({
  eachMessage: async ({ message }) => {
    await process(message);
    await consumer.commitOffsets([{ topic, partition, offset: message.offset + 1 }]);
  },
});

---

4. 场景推荐

场景	推荐方案	理由
任务队列（一条消息一个消费者）	RabbitMQ	队列模型天然匹配
事件流（一条消息多个消费者）	Kafka	日志模型支持多消费者
日志聚合	Kafka	高吞吐量 + 消息持久化
实时通知（WebSocket 推送）	Redis Streams	低延迟 + 简单部署
微服务异步通信	RabbitMQ	灵活的路由 + 成熟稳定
数据管道（ETL）	Kafka	高吞吐量 + 消息回溯

---

总结

维度	RabbitMQ	Kafka	Redis Streams
学习曲线	中	高	低
运维成本	中	高	低
吞吐量	万级	百万级	十万级
消息持久化	支持	支持	支持
消息回溯	不支持	支持	支持
适用场景	任务分发、微服务	事件流、日志	轻量级队列

消息队列的选型不是”选一个最好的”，而是”选一个最不坏的”。 每个方案都有取舍，关键是理解你的场景对吞吐量、可靠性、消息模型的需求，然后选一个在这些维度上”最不坏”的。

需要消息队列方案设计或后端架构咨询？联系我们，说清你的通信场景与规模，24 小时内回可行性。