消息队列怎么选：先想清楚你要它干什么
被问过很多次"我们该用哪个 MQ"。这个问题没法直接答，因为三家产品的设计目标就不一样。先回答两个前置问题，选型自然浮出来。
前置问题一：消息是"数据流"还是"任务"？日志、埋点、监控指标这种，量大、丢了能容忍、按顺序批量消费——这是数据流，Kafka 的主场（分区顺序、高吞吐、消费位移回溯）。下单、扣款、发通知这种，一条都不能丢、要确认处理结果——这是任务，RabbitMQ/RocketMQ 的主场（消息确认、失败重试、死信队列）。
前置问题二：要不要复杂路由？RabbitMQ 的 exchange 模型能玩出很多花样（直连、主题、扇出），路由逻辑复杂的系统用它顺手；RocketMQ 补齐了事务消息和延迟消息，业务系统用得舒坦；Kafka 的路由就是分区，简单粗暴。
| 维度 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 吞吐 | 极高 | 高 | 中 |
| 延迟 | 批量换取吞吐 | 低 | 低 |
| 事务/延迟消息 | 弱 | 强 | 弱（插件） |
| 典型场景 | 日志管道、流计算 | 电商核心链路 | 任务队列、复杂路由 |
落到我们内部的三个真实决策：日志归集上 Kafka（吞吐）；订单异步任务上 RocketMQ（要事务消息和延迟重试）；内部系统间小规模事件直接 RabbitMQ（运维轻）。三个都在跑，没有一个是错的。
选型避坑：别为"可能的高吞吐"提前上 Kafka——它的运维复杂度和消费模型（位移提交、再均衡）对小团队是实打实的负担。先把"消息丢了怎么办、重复了怎么办"这两个问题想清楚，比选哪个产品重要。