📚 课程目录第3章消息中间件选型

3. 消息中间件选型：RabbitMQ vs Kafka vs Redis Streams 对比与选型依据

在多批次并行召回通知链路中，消息中间件是异步解耦、削峰填谷与可靠投递的核心基础设施。选型错误将直接导致通知丢失、链路阻塞或运维复杂度失控。本节从召回场景的典型需求出发，对 RabbitMQ、Kafka 与 Redis Streams 进行系统性对比，并给出明确的选型决策路径。

在进入具体产品对比前，先明确召回场景对消息中间件的 6 项关键需求：

需求维度	说明	优先级
可靠性	消息不丢失、不重复（至少一次语义），支持持久化与确认机制	高
顺序性	同一召回批次内的通知需按生成顺序投递，避免乱序导致状态错乱	高
吞吐量	支持每秒万级以上的通知写入与消费，应对多批次并发峰值	高
延迟	端到端投递延迟控制在秒级以内，避免影响召回时效性	中
消费模型	支持多消费者并行消费同一队列/分区，且能独立管理偏移量	中
运维复杂度	部署、扩缩容、监控与故障恢复的易用性	中

以下从架构模型、投递语义、性能表现与适用场景四个维度进行横向对比：

对比维度	RabbitMQ	Kafka	Redis Streams
架构模型	Exchange → Queue → Consumer 基于 AMQP 协议	Topic → Partition → Consumer Group 基于日志追加模型	Stream → Consumer Group 基于内存+持久化 RDB/AOF
投递语义	至少一次（默认），支持事务与确认	至少一次（默认），支持幂等生产者与事务	至少一次（通过 XACK 确认），支持消费者组
顺序保证	单队列内严格顺序（单消费者）	单分区内严格顺序	单 Stream 内严格顺序
吞吐量	万级/秒（单节点）	百万级/秒（集群）	十万级/秒（单节点）
端到端延迟	微秒～毫秒级	毫秒级（默认）	微秒级（内存操作）
持久化	支持（队列持久化+消息持久化）	强持久化（磁盘日志）	支持（RDB/AOF 快照）
消费模型	队列模式：一条消息只能被一个消费者消费	发布-订阅：一条消息可被多个消费组消费	消费者组：类似 Kafka 的消费组模型
运维复杂度	中等（需管理 Exchange/Binding/Queue）	较高（需管理 Topic/Partition/Offset）	低（原生 Redis 生态，无需额外组件）

关键提示： 在召回通知链路中，顺序性与可靠性是硬约束，吞吐量达到万级即可满足多数场景。Kafka 的百万级吞吐在召回场景中属于过度设计，且会引入更高的运维成本。

下图展示了三种消息中间件在召回通知链路中的典型架构差异：

基于召回通知链路的实际需求，构建以下选型决策矩阵：

评估项	RabbitMQ	Kafka	Redis Streams
顺序保证	✅ 单队列严格顺序	✅ 单分区严格顺序	✅ 单 Stream 严格顺序
可靠性（持久化）	✅ 队列+消息双重持久化	✅ 磁盘日志强持久化	⚠️ 依赖 RDB/AOF 配置
吞吐量（万级/秒）	✅ 满足	✅ 远超需求	✅ 满足
延迟（秒级以内）	✅ 毫秒级	✅ 毫秒级	✅ 微秒级
多消费者并行消费	⚠️ 需手动实现（多个 Queue）	✅ 原生消费组支持	✅ 原生消费组支持
运维复杂度	⚠️ 中等	❌ 较高	✅ 低
社区生态与成熟度	✅ 成熟稳定	✅ 成熟稳定	⚠️ 较新，生态相对薄弱

根据召回通知链路的具体规模与团队技术栈，给出以下选型建议：

  推荐方案一（中小规模，团队熟悉 Redis）： 使用 Redis Streams 作为消息中间件。利用其低延迟、消费者组与原生顺序保证特性，配合 RDB 持久化策略，可满足万级吞吐与秒级延迟需求。适合 10 万级以下召回批次、团队 Redis 运维经验丰富的场景。

  推荐方案二（中大规模，需要强可靠性与成熟生态）： 使用 RabbitMQ 作为消息中间件。利用其 Exchange 灵活路由、队列持久化与确认机制，配合死信队列处理失败通知。适合 10 万～100 万级召回批次、需要精细路由与重试策略的场景。

不推荐场景： 除非召回通知链路需要同时支持实时流计算、日志聚合或跨团队多订阅者场景，否则不建议引入 Kafka。Kafka 的运维复杂度与资源消耗在纯通知链路中属于过度设计，且其分区模型在顺序保证上需要额外设计。

以下流程图帮助快速定位适合的中间件：

综合考虑召回通知链路的实际需求与团队技术栈，本课程后续章节将采用 RabbitMQ 作为消息中间件。理由如下：