🚀 一、RocketMQ 的优点（为什么大厂都爱它）
RocketMQ 的优势其实是围绕“高吞吐 + 可控 + 企业级”展开的，我按工程价值给你拆：
✅ 1. 高吞吐、高性能（顺序写 + mmap）
- CommitLog 顺序写磁盘，吞吐非常高
- mmap（内存映射）+ pageCache 利用操作系统缓存
- 异步刷盘、批量处理
一句话：
RocketMQ 写入速度接近内存写，读写性能极其稳定。
这是 Kafka 级别的能力。
✅ 2. 超高可用（主从复制 + Dledger 自动选主）
- 支持 Master–Slave
- 支持 Dledger 多副本 + 自动选主（RocketMQ 5 的亮点）
也就是：
Broker 挂了，自动切换，不停服。
✅ 3. 灵活的 Topic + 队列结构（天然支持顺序消息）
RocketMQ 很适合：
- 分区顺序
- 全局顺序
- 局部有序业务
相比 Kafka，RocketMQ 原生实现更自然。
✅ 4. 功能丰富（延迟级别、事务消息、重试、DLQ 都是标配）
RocketMQ 原生就支持：
- 18 个延迟级别（秒级 → 小时级）
- 事务消息（最终一致）
- 消费重试机制
- 死信队列（DLQ）
- 消费幂等
这些 Kafka 都要你自己折腾。
✅ 5. 易用性好（API 更贴近业务）
- Producer / Consumer API 灵活
- Spring Boot Starter 很成熟
- 比 Kafka 的 API 更偏向业务工程师
🚀 二、RocketMQ 的缺点（必须心里有数）
东西再好，仍有边界。
❌ 1. 管理成本比 Kafka 高
Kafka 完全靠分片 + 副本自动负载均衡，RocketMQ 的 Broker/Queue 管理更人工一些。
❌ 2. Dledger 前的版本主从切换依赖人工
RocketMQ 4.x 的主从切换是：
半自动/人工切换，不如 Kafka 那么自动化
（不过 RocketMQ 5 已经完全补齐）
❌ 3. 社区生态不如 Kafka 大（尤其是监控、Connector 体系）
Kafka 有：
- Kafka Connect
- Flink Sink/Source 完整链路
- Schema Registry
RocketMQ 这方面稍弱。
❌ 4. 大量分区扩容麻烦（队列数量扩容并不线性）
RocketMQ Topic 一旦创建了队列数，后续扩容不够自然。
不像 Kafka 自动 rebalance。
❌ 5. 跨机房架构相对复杂（Topic、Queue 多副本管理）
需要合理规划：
- 切片方式
- HA 策略
- 消费端负载
🚀 三、适用场景（这个你一定要会）
下列业务，RocketMQ 都是经典方案：
✔ 1. 大规模异步解耦
例如：
- 订单下单 → 营销系统通知
- 用户注册 → 发送短信、邮件
- 业务事件驱动架构（EDA）
RocketMQ 强调高可靠+高并发，非常适合。
✔ 2. 高并发高吞吐日志/事件流
例如：
- 电商订单事件
- 营收流水事件
- 用户行为事件上传
- IoT 大规模设备消息
✔ 3. 顺序消息场景
例如：
- 订单状态流转（支付 → 发货 → 收货）
- 交易记录（加减余额必须有序）
- 仓储出入库操作（FIFO）
RocketMQ 比 Kafka 更容易实现队列级有序。
✔ 4. 延迟队列业务（Kafka 不支持）
例如：
- 订单 30 分钟未支付自动取消
- 定时关单
- 延迟触发营销活动
- 延迟发送通知
RocketMQ 延迟 Topic 是原生能力，使用超级简单。
✔ 5. 分布式事务（本地事务 + 消息最终一致）
例如：
- 扣库存 + 发消息统一成功
- 创建订单 + 发送流水消息
- 资金交易流水保障一致性
RocketMQ 的事务消息两阶段模型非常成熟。
🚀 四、如何保证消息“不丢失”？（重点！面试高频！）
不丢失 = Producer 不丢、Broker 不丢、Consumer 不丢
我分成三段给你讲：
⭐ A、Producer 侧防丢措施
1）必须使用“同步发送”
SendResult sendResult = producer.send(msg);
异步、oneway 都有潜在丢失可能 → 不要用。
2）开启重试机制
RocketMQ 默认：
- 同步发送失败重试 2 次
- 异步发送失败重试 0 次（需手动配）
建议：
producer.setRetryTimesWhenSendFailed(3);
producer.setRetryTimesWhenSendAsyncFailed(3);
3）不要让 Producer 业务事务先提交再发消息（顺序错误）
正确方式：
本地事务 → half message → commit|rollback
RocketMQ 自带事务消息机制解决这个问题。
⭐ B、Broker 侧防丢措施
Broker 是最关键的环节，主要靠 刷盘策略 + 主从复制。
1）刷盘策略：必须选择同步刷盘（SYNC_FLUSH）
默认异步刷盘 = 电源断电可能丢数据。
同步刷盘：
- 消息写到 CommitLog
- 等待刷入磁盘后才 Ack
缺点是吞吐下降，但“绝不丢”必须用它。
2）主从复制：必须选择同步复制（SYNC_MASTER）
ASYNC_MASTER 有风险：
- Master 写成功 → Ack 返回给 Producer
- Master 崩溃未同步 Slave → 数据丢失
强一致场景必须用同步复制。
3）使用 DLedger 自动选主，避免单点丢失
DLedger 机制：
- 多副本一致性
- 自动选主
- 任意节点挂掉不丢消息
这是 RocketMQ 5 的亮点。
⭐ C、Consumer 侧防丢措施
消费者主要靠：正确提交 offset + 消费幂等 + 失败重试
1）必须在“处理完业务后再提交 offset”
不要自动提交、不要提前提交。
PushConsumer：
- 默认会自动提交 offset
⚠ 稳定业务必须手动控制 retry 流程
2）消费失败时必须返回 RECONSUME_LATER
RocketMQ 会自动投递到 retry topic（最多 16 次）
3）业务必须幂等（至少一次消费语义）
不幂等 → 重试就乱套。
典型的做法：
- Redis 去重
- MySQL 唯一键约束
- 本地消息表去重
⭐ D、总结：消息100%不丢的配置组合
这是大厂真实用法：
| 阶段 | 防丢措施 |
|---|---|
| Producer | 同步发送 + 重试 + 本地事务 |
| Broker | SYNC_FLUSH + SYNC_MASTER + DLedger |
| Consumer | 手动提交 offset + 失败重试 + 幂等 |
你要记住一句话：
只要你没有使用异步、没有使用异步刷盘、没有使用异步复制，RocketMQ 就能做到极高可靠性。
🚀 最后，我给你一句工程师总结
RocketMQ 是一款“业务友好型”的中间件，它关注业务一致性与可靠性，比 Kafka 更贴近企业级系统，而不是单纯“吞吐优先”。