消息队列技术选型
四条口诀和 MQ 的对应关系可以这样记：
| 场景 | 优先考虑 | 一般不优先 | 说明 |
|---|---|---|---|
| 大促看吞吐 | Kafka、RocketMQ | ActiveMQ、RabbitMQ | 单机都是 10 万级吞吐；万级的 RabbitMQ / ActiveMQ 扛不住大促峰值 |
| 中台看 Topic 数 | RocketMQ（万级 Topic 最稳） | Kafka（百～千级更稳妥） | 中台要接很多业务线，Topic 会很多；Kafka Topic/分区一多，单 Broker 压力大 |
| RabbitMQ（万级队列可用） | ActiveMQ（千级） | RabbitMQ 也能撑多队列，但别堆到十万级；ActiveMQ 更适合 Topic 不多的老系统 | |
| 金融看分布式高可用 | Kafka、RocketMQ | ActiveMQ、RabbitMQ | 两者都是分布式、可用性「非常高」；金融还要叠加事务消息、审计、运维体系等再细选 |
| 时效性不必过度纠结 | 四家都能选，别为微秒选 RabbitMQ | 单独因「微秒」选 RabbitMQ | 生产里多是毫秒 + 网络抖动；这条是排除项：别拿延迟当决定性理由 |
一句话版
- 大促 → Kafka / RocketMQ
- 中台（Topic 多） → RocketMQ 首选，其次 RabbitMQ；Kafka 适合 Topic 可控、偏日志/流式的中台
- 金融 → Kafka / RocketMQ
- 时效性 → 不单独绑定某一家；RabbitMQ 的「微秒」优势在多数业务里可以忽略
若只能二选一
| 场景 | Kafka | RocketMQ |
|---|---|---|
| 大促 / 日志 / 流处理、生态（Flink/Spark） | ✅ 更常见 | ✅ 也够用 |
| 中台 Topic 特别多、要按时间回溯、国内运维/console | 一般 | ✅ 更合适 |
| 金融（强一致、事务消息、顺序消息） | ✅ 精确一次、生态成熟 | ✅ 事务/顺序消息原生支持好 |
ActiveMQ 在这三条主场景里通常都不是首选，更适合遗留系统或小规模、Topic 不多的场景。
下面从多个维度对比 Kafka、ActiveMQ、RabbitMQ、RocketMQ。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级 | 万级 | 10 万级 | 10 万级 |
| 时效性 | 毫秒级 | 微秒级（理想条件下；生产环境多为毫秒级） | 毫秒级 | 毫秒级 |
| 可用性 | 高（主从） | 高（主从 / 镜像队列等） | 非常高（分布式） | 非常高（分布式） |
| 消息语义 | 至少一次 | 至少一次（也可配置至多一次） | 至少一次 / 至多一次 | 至少一次 / 至多一次 / 精确一次（0.11+，需配置开启） |
| 消息顺序性 | 有序（单队列内） | 有序（单队列内） | 顺序消息（同一 MessageQueue 内有序） | 分区有序 |
| 支持主题数 | 千级 | 万级（队列过多时元数据与内存开销明显） | 万级（CommitLog 对海量 Topic 较友好） | 百～千级较稳妥（Topic / 分区过多时单 Broker 文件开销大，性能下降） |
| 消息回溯 | 不支持（无按时间/位点的大规模回溯能力） | 不支持（消费确认后消息即删除，非日志型回溯） | 支持（按时间回溯） | 支持（按 offset 回溯） |
| 管理界面 | 普通 | 普通 | 完善 | 普通 |
选型时需要结合业务场景与上表特性综合判断。
高吞吐、短时峰值（如大促秒杀）
管理界面、消息回溯等往往不重要，吞吐量是首要指标，可优先考虑 Kafka、RocketMQ 这类高吞吐方案。
中台、多业务接入（Topic / 队列数量多）
主题（或队列）数量会成为关键约束。Kafka 在 Topic、分区过多时运维与性能压力较大，生产上常控制在百～千级；RocketMQ 凭借 CommitLog 可支撑万级 Topic；RabbitMQ 可支撑万级队列，但不宜盲目堆到十万级以上（官方也不建议单机维护海量队列）。
金融等对稳定性、合规要求高的场景
重点看高可用、分布式、持久化与运维成熟度，分布式架构的 Kafka、RocketMQ 通常更合适。
关于时效性
RabbitMQ 常以微秒级延迟作为卖点，但在绝大多数业务里，毫秒与微秒的差异难以感知，网络抖动也会抹平这一差距，生产选型时通常不会把它当作决定性因素。
其它常见考量
消息确认机制、消息回溯、多租户隔离等也常被纳入评估；管理界面则视公司而定——不少团队更依赖自研或统一的运维平台，而不依赖 MQ 自带控制台。