消息队列选型最容易陷入两个误区：
- 只看吞吐，不看业务语义
- 只看“别人用什么”，不看团队能力
Kafka 和 RabbitMQ 都成熟，关键不在谁“更好”，而在谁“更适合当前场景”。
【场景：同一个系统里有两类消息】
典型业务里常见两类需求：
- 订单创建后需要多个系统异步消费（对吞吐敏感）。
- 支付结果通知要求高可靠送达（对投递语义敏感）。
这两类消息如果强行用同一策略，通常会牺牲一侧。
【核心对比：先看需求，再选组件】
1）吞吐与积压处理
- Kafka：高吞吐、顺序读写、适合大规模日志流
- RabbitMQ：吞吐中等，适合中小规模业务消息
2）路由能力
- Kafka：主题+分区，路由模型相对简单
- RabbitMQ：交换机路由灵活（direct/topic/fanout）
3）消费语义
- Kafka：至少一次为主，依赖业务幂等
- RabbitMQ：ACK/NACK 控制细，重试与死信机制成熟
4）运维复杂度
- Kafka：集群治理和参数调优门槛更高
- RabbitMQ：上手快，但大规模场景也需精细治理
【选型决策表（可直接套用）】
- 如果你要处理海量事件流、日志采集、行为埋点：优先 Kafka。
- 如果你要做业务任务分发、复杂路由、失败重投：优先 RabbitMQ。
- 如果两类需求并存：允许“双队列并存”，不要强行统一。
【落地关注点：不是选完就结束】
Kafka 侧重点
- 分区设计与键选择（避免热点分区）
- 消费位点管理
- 消费幂等（去重键、幂等表）
RabbitMQ 侧重点
- 交换机与队列绑定关系
- 死信队列和重试策略
- 消费者并发与预取参数
【示例：统一消息契约】
无论选哪个 MQ，建议先统一消息格式：
{
"eventId": "e20260227001",
"eventType": "ORDER_CREATED",
"occurredAt": "2026-02-27T10:15:30Z",
"source": "order-service",
"data": {
"orderId": 10001,
"userId": 1024
}
}
统一契约能显著降低跨团队联调成本。
【一份可复用的 MQ 选型清单】
- 当前消息规模（峰值 TPS、日消息量）是多少？
- 是否需要复杂路由与死信处理？
- 是否接受至少一次投递并做幂等？
- 团队是否有对应运维与治理经验？
- 是否有明确监控（积压、消费延迟、失败率）？
- 是否定义了消息版本与兼容策略？
下期预告：
《分布式事务实战：Seata、TCC、本地消息表怎么选》
