消息队列选型

选消息队列不是选「最好的」，而是选「最适合的」。本章聚焦 RabbitMQ 的核心优势与适用场景。完整技术对比见 Kafka · 消息队列选型。

RabbitMQ 的核心优势

维度	RabbitMQ 的特点
路由能力	4 种 Exchange（Direct/Topic/Fanout/Headers），路由规则灵活
延迟	消息路由与投递模型适合对交互延迟敏感的业务，实际端到端延迟取决于队列类型、确认策略、持久化与负载
协议支持	支持 AMQP，可通过插件支持 MQTT、STOMP，适合有 MQTT 接入需求的 IoT 场景
死信队列	提供原生死信机制，需配置 DLX 及触发条件
延迟消息	可经 TTL+DLX 延迟转发；RabbitMQ 4.4 起 Quorum Queue 原生支持延迟投递，旧版延迟交换机插件已停止维护
运维成本	小规模业务场景下部署较轻，实际成本取决于集群规模、高可用要求与运维方式

选 RabbitMQ 的场景

• 复杂路由规则（按 routing key 精确/模糊匹配）
• 消息量中等，吞吐需求可由单节点或小集群满足
• 对交互延迟敏感的业务
• IoT 设备通信（MQTT 协议）
• 企业内部微服务间可靠投递
• 需要死信队列、延迟消息等高级特性

通常优先考虑其他方案的场景

场景	原因	推荐
日志收集/大数据流	长期保留、大规模事件流及多消费者独立回放通常更适合成熟日志流平台；RabbitMQ Streams 也具备日志式保留与 offset 消费能力	Kafka
极高吞吐	需评估集群与队列类型实际上限后再决定	Kafka / Pulsar
消息回溯	经典队列无基于 offset 的原生历史重读，重新入队/重发布语义与成本不同；RabbitMQ Streams 支持日志式保留与 offset 消费	Kafka
流处理	无原生流处理引擎	Kafka Streams / Flink

组合使用

实际项目中经常组合：

IoT 设备 ──MQTT──▶ RabbitMQ ──AMQP──▶ 业务服务
                                      │
                                      ▼
                              Kafka（日志/事件流）

上图表达的是业务服务处理 RabbitMQ 消息后，将日志/事件写入 Kafka 的转发链路。若 RabbitMQ 与 Kafka 承载的是互不相关的独立消息流，应去掉该箭头。生产环境需处理 Kafka 写入失败、重复投递与重试；要求可靠转发时应设计幂等机制与补偿方案。

不要为了「统一技术栈」强行用一个 MQ 解决所有问题。RabbitMQ 擅长业务消息、灵活路由；Kafka 擅长大数据量、高吞吐。各取所长。