RocketMQ常见问题梳理

MQ常见问题深度剖析：消息不丢失、顺序性、幂等性与积压处理

本文基于RocketMQ核心原理，结合Kafka/RabbitMQ对比，深入分析MQ四大核心问题解决方案

---

一、消息不丢失保障机制

消息丢失风险点

1. 跨网络传输：生产者→Broker、Broker→消费者、主从同步
2. Broker缓存机制：PageCache异步刷盘导致数据未持久化
3. 极端故障：整个MQ集群宕机

---

生产者保证方案

1. 发送确认机制

// RocketMQ同步发送（强安全）
SendResult result = producer.send(msg, 20*1000); 

// Kafka Future获取（同步效果）
RecordMetadata metadata = producer.send(record).get();

// RabbitMQ Publisher Confirms
channel.addConfirmListener(ackCallback, nackCallback);

2. RocketMQ事务消息（双保险）

Commit

Rollback

发送半消息

执行本地事务

事务状态?

提交消息

丢弃消息

设计本质：通过多次网络确认+本地事务绑定，解决业务操作与消息发送的一致性

---

Broker存储保证

刷盘策略对比

MQ	同步刷盘	异步刷盘
RocketMQ	flushDiskType=SYNC_FLUSH	默认策略
	实际10ms间隔刷盘(非实时)
Kafka	log.flush.interval.messages=1	默认Long.MAX
RabbitMQ	经典队列不支持实时刷盘	流队列依赖OS刷盘

关键结论：任何MQ都无法100%保证断电不丢消息，需结合生产者确认使用

---

主从同步策略

1. RocketMQ普通集群

   • 角色模式：ASYNC_MASTER/SYNC_MASTER/SLAVE
   • 故障处理：Master宕机后Slave不切换，等待恢复避免数据丢失

2. Kafka机制差异

   • Leader切换后，旧Leader未同步数据直接丢弃（可用性优先）

3. Dledger集群（推荐）

   • 基于Raft协议实现多数派写入
   • 网络分区时可能丢失未确认消息

---

消费者保障

核心原则：同步处理+消费确认

// 错误示范（异步处理导致丢失）
consumer.registerMessageListener((msgs, context) -> {
    new Thread(() -> processMsg(msgs)).start(); // 异步线程
    return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; // 立即确认
});

正确做法：业务处理完成后再提交ACK/Offset

---

极端场景：全集群宕机

降级方案：

1. 生产者写入本地缓存（DB/文件）
2. 独立线程异步重试投递
3. MQ恢复后优先处理缓存消息

---

二、消息顺序性保障

局部有序实现原理

组件	生产者保证	消费者保证
RocketMQ	相同Hash写入同一MessageQueue	单线程消费队列（并发控制）
Kafka	指定Partition key	单Partition单线程消费
RabbitMQ	绑定同一队列	单消费者消费单队列

全局有序代价：设置Topic/Partition=1，严重牺牲吞吐量（不推荐）

---

三、消息幂等性保障

重复消费场景

1. 生产者重试导致重复发送
2. 消费者ACK丢失触发重投

解决方案

生产者端

MQ	幂等机制
RocketMQ	MessageID去重（不适用于事务消息）
Kafka	开启idempotence： - PID+SequenceNumber
	Broker维护序列号

消费者端

// 业务层幂等处理示例
ConcurrentHashMap<String, Boolean> processedMsgIds = new ConcurrentHashMap<>();

void processMessage(Message msg) {
    String bizId = msg.getKeys(); // 业务唯一标识
    if(processedMsgIds.putIfAbsent(bizId, true) != null) {
        return; // 已处理则跳过
    }
    // 核心业务逻辑...
}

最佳实践：优先使用业务唯一标识（如订单ID）而非MessageID

---

四、消息积压处理

积压根源

• 消费者吞吐量不足：处理逻辑复杂或资源不足
• 设计缺陷：生产者速率 >> 消费者能力

应急方案

1. 消费者扩容

MQ	扩容限制	优化手段
RocketMQ	Consumer数 ≤ MessageQueue数	增加队列数（需重建Topic）
RabbitMQ	Classic Queue无明确限制	调整Qos权重

2. 建立临时Topic

积压Topic

新建临时Topic

迁移未消费消息

启动只读消费者组快速消费

结果写入DB/缓存

3. 死信队列兜底

• RocketMQ默认保留72小时
• 需手动订阅处理：%DLQ%ConsumerGroupName

---

五、课程核心总结

1. 设计哲学差异：

   • RocketMQ：金融级数据安全（阿里系）
   • Kafka：高吞吐日志处理（LinkedIn）
   • RabbitMQ：灵活消息路由（传统企业）

2. 方案选择本质：

   业务场景

   技术选型

   参数调优

   监控迭代

不存在完美解决方案，只有最适合业务场景的平衡点设计