文章目录
- 一、先记住一句话核心定论
- 二、底层设计初衷完全不同（根源差异）
-
- [1、Kafka 生来不是给业务解耦用的](#1、Kafka 生来不是给业务解耦用的)
- [2、RocketMQ 生来就是给金融电商业务用的](#2、RocketMQ 生来就是给金融电商业务用的)
- 三、生产核心关键能力硬性对比（开发最看重）
- 四、实际生产开发：谁必须选Kafka？
-
- [✅ 以下场景**强制选 Kafka**，不要用RocketMQ](#✅ 以下场景强制选 Kafka，不要用RocketMQ)
- 五、实际生产开发：谁必须选RocketMQ？
-
- [✅ 以下场景**强制选 RocketMQ**，不要用Kafka](#✅ 以下场景强制选 RocketMQ，不要用Kafka)
- 六、生产避坑重点（很多公司踩过的坑）
-
- [❌ 坑1：核心订单业务乱用Kafka](#❌ 坑1：核心订单业务乱用Kafka)
- [❌ 坑2：大数据日志采集乱用RocketMQ](#❌ 坑2：大数据日志采集乱用RocketMQ)
- [❌ 坑3：贪图便宜统一只用一个MQ](#❌ 坑3：贪图便宜统一只用一个MQ)
- 七、极简选型总结
在Java后端分布式项目开发中，Kafka和RocketMQ是目前企业生产环境使用率最高的两款消息中间件。很多团队选型纠结：不是两款MQ谁更强，而是两款MQ设计初衷完全不一样，适配的业务场景天生不同。选错MQ不会直接崩，但会出现：事务不可靠、消息丢数据、消费堆积处理不了、运维复杂、线上频繁出事故等一系列生产问题。
一、先记住一句话核心定论
做业务、做订单、做支付、做事务、做延迟消息 → 选 RocketMQ
做日志、做埋点、做大数据、做实时流、超高吞吐采集 → 选 Kafka
这是国内互联网公司、金融公司、大厂统一默认选型标准，不用纠结。
二、底层设计初衷完全不同（根源差异）
1、Kafka 生来不是给业务解耦用的
Kafka最早LinkedIn研发，核心定位是分布式日志收集与流式传输管道。
设计目标：极致高吞吐、海量数据堆积、顺序读写、适合大数据链路。
不是为了：订单业务、金融交易、事务消息、延迟消息、严格不丢消息。
2、RocketMQ 生来就是给金融电商业务用的
RocketMQ阿里开源，核心定位是电商交易、支付、订单核心业务消息中间件。
设计目标：消息绝对可靠、事务支持、重试机制完善、死信队列、延迟消息、运维简单。
不是为了：大数据海量日志采集。
三、生产核心关键能力硬性对比（开发最看重）
| 对比维度 | Kafka | RocketMQ | 生产选型结论 |
|---|---|---|---|
| 核心定位 | 大数据流式管道、日志采集 | 业务交易消息、异步解耦核心MQ | 业务选RocketMQ，数据选Kafka |
| 消息可靠性 | 靠配置硬堆（acks+offset手动提交） | 原生天生支持高可靠，开箱即用 | 金融/订单必须RocketMQ |
| 事务消息支持 | 弱支持，极其复杂，不推荐业务用 | 原生二阶段事务，生产标配 | 做分布式事务只能RocketMQ |
| 延迟消息/定时消息 | 不原生支持，需要自己写代码实现 | 原生支持18个等级延迟，开箱即用 | 订单超时、倒计时必选RocketMQ |
| 消费重试+死信队列 | 需要自己手动写代码处理 | 原生自带重试队列、死信队列 | 线上故障RocketMQ好维护 |
| 吞吐量性能 | 极高（大数据首选） | 高，够用，业务场景完全足够 | 日志采集选Kafka |
| 顺序消息 | 分区内有序，实现复杂 | 严格顺序消息原生支持 | 订单状态流转用RocketMQ |
| 运维难度 | 高，参数多、调参复杂、版本升级麻烦 | 低，纯Java、NameServer轻量、上手简单 | 小团队优选RocketMQ |
| JDK适配 | 新版不兼容JDK8，老项目适配麻烦 | 完美兼容JDK8，企业旧项目适配好 | 传统企业项目RocketMQ更友好 |
四、实际生产开发：谁必须选Kafka？
✅ 以下场景强制选 Kafka，不要用RocketMQ
- 用户行为埋点、点击日志、浏览日志上报
- 系统操作日志、运维日志、监控数据收集
- 实时数仓、大数据计算、Flink/Spark流式计算
- 海量数据高吞吐写入，一秒几十万条数据上报
- 数据同步、数据流转、日志聚合中间管道
理由：Kafka日志存储结构天生适合海量流式数据，吞吐碾压级优势，大数据生态完美适配。
五、实际生产开发：谁必须选RocketMQ？
✅ 以下场景强制选 RocketMQ，不要用Kafka
- 电商订单创建、订单状态流转、订单超时关闭
- 支付交易、资金账务、充值扣款、对账业务
- 分布式事务消息、最终一致性业务
- 需要延迟消息、定时消息（比如30分钟未支付取消订单）
- 业务异步解耦、营销活动通知、短信推送、积分发放
- 小团队运维人手少，不想天天调MQ参数修bug
理由：RocketMQ天生为业务可靠而生，重试、死信、事务、延迟全部原生自带，不用开发者手写代码填坑。
六、生产避坑重点（很多公司踩过的坑）
❌ 坑1：核心订单业务乱用Kafka
Kafka事务弱、重试麻烦、死信要自己写、offset配置一不小心就丢消息。很多公司用Kafka做支付订单，最后出现消息丢失、订单对账不平、重复消费炸库。
解决：核心业务老老实实RocketMQ。
❌ 坑2：大数据日志采集乱用RocketMQ
RocketMQ吞吐不如Kafka，海量日志堆积后性能压力大，资源占用高，不适合做大数据流式管道。
解决：日志、大数据流式处理老老实实Kafka。
❌ 坑3：贪图便宜统一只用一个MQ
正确大厂架构：业务系统用RocketMQ，数据系统用Kafka，两套MQ并存，各司其职，互不干扰。
七、极简选型总结
- 做业务、做交易、做订单、做事务、做延迟 → RocketMQ
- 做日志、做埋点、做大数据、做实时流、高吞吐采集 → Kafka
- 小团队、传统项目、JDK8旧项目 → 优先RocketMQ，省心少出事
- 大数据部门、数仓部门、流式计算业务 → 必选Kafka
- 线上生产不要二选一混用核心场景，各司其职最稳定