必须用 RabbitMQ 的场景是：需灵活路由与强协议兼容、微秒级响应，如基于内容/headers/routing key 复杂分发，或对接 AMQP 客户端及 SAP/Oracle EBS 等传统系统，且日均消息量小（1MB）、写入高频（>5w TPS）。
选 RabbitMQ 还是 Kafka 或 RocketMQ，关键看你的业务是否真的需要它——不是“用了更高级”，而是“不用会出问题”。RabbitMQ 不是性能弱，而是它压根不为高吞吐设计；Kafka 不是更可靠，而是它把可靠性让渡给了吞吐和生态；RocketMQ 也不是功能多就该默认上，它的事务消息机制有明确的调用链约束。错配比不用更危险。
什么时候必须用 RabbitMQ？
RabbitMQ 的核心价值在「灵活路由 + 强协议兼容 + 微秒级响应」，不是当个管道，而是当个带规则引擎的调度中心。
- 你需要基于消息内容、headers 或 routing key 做复杂分发（比如订单按地区/金额/类型路由到不同下游服务），
Exchange+Binding+Queue模型天然支持，Kafka 和 RocketMQ 都得靠消费者自己做二次分拣 - 系统里已有大量 AMQP 客户端（如 Spring AMQP、.NET 的 EasyNetQ），或要对接传统企业系统（SAP、Oracle EBS），RabbitMQ 是唯一能开箱即用的选项
- 消息量不大（日均 publisher confirms +
mandatory+basic.nack），比如金融行情推送、实时风控决策通知 - 你无法接受消息堆积后性能断崖式下跌——RabbitMQ 在堆积超 100 万条时，内存+磁盘 IO 压力会陡增，但只要控制住堆积量（比如加告警、限流、死信兜底），它反而比 Kafka 更稳
Kafka 适合什么场景？别只盯着吞吐量
Kafka 的吞吐优势只在「持续写入 + 批量消费 + 多消费者并行读」时成立。单生产者、单消费者、小消息体、低频写入，它反而更重、更慢。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 你依赖消息回溯（比如用户行为日志要保留 7 天以上，且随时可重放），
log.retention.hours和segment.bytes配置成熟，RabbitMQ 的 TTL 和磁盘策略做不到长期稳定存储 - 下游是 Flink / Spark / Presto 等流计算组件，Kafka 的
__consumer_offsets和partition分区模型与它们原生对齐，RocketMQ 虽有 flink-connector，但社区维护滞后 - 消息体大（> 1MB）、写入频率高（> 5w TPS）、且允许少量延迟（
- 你不需要「发送即成功」的语义，而要「至少一次 + 消费者自行去重」，Kafka 的
enable.idempotence=true和isolation.level=read_committed组合比 RabbitMQ 的 ack 机制更适合大数据链路
RocketMQ 的事务消息不是银弹，用错反成瓶颈
RocketMQ 的 half message + checkLocalTransaction 是为「本地 DB 更新 + 发送消息」原子性设计的，但它要求：业务代码必须实现回查接口、Broker 必须能主动调用你的服务、网络必须双向可达。这在跨云、多租户、Serverless 场景下极易失败。
- 你做电商订单创建（扣库存 + 生单 + 发通知），且所有服务都在同 VPC 内、可用区可控，
TransactionMQProducer配合LocalTransactionExecuter是最简路径 - 消息堆积能力是刚需（比如双 11 订单洪峰后延时消费），RocketMQ 的
commitlog设计让它在亿级堆积下仍保持毫秒级延迟，Kafka 堆积多了会导致 consumer lag 指标失真，RabbitMQ 直接 OOM - 你需要延迟消息（如 30 分钟未支付自动关单），RocketMQ 原生支持
setDelayTimeLevel(3)（对应 10s/30s/1m），Kafka 要靠时间轮 + 外部调度，RabbitMQ 得靠死信队列+TTL 间接模拟，精度差、运维成本高 - 你用 Java 技术栈且团队熟悉阿里系中间件（Dubbo/Nacos），RocketMQ 的客户端日志、监控埋点、运维工具链（如 rocketmq-console）和现有体系贴合度更高
真正容易被忽略的是部署复杂度：RabbitMQ 单节点就能跑通 90% 场景；Kafka 必须配 ZooKeeper 或 KRaft，且 replication.factor 和 min.insync.replicas 配错会导致数据丢失；RocketMQ 的 NameServer 和 Broker 角色分离看似简单，但 broker.conf 里 flushDiskType（ASYNC_FLUSH vs SYNC_FLUSH）一设错，金融类业务就可能丢消息。选型不是比参数，而是比谁能在你团队的运维水位上不出事。
