RocketMQ常见问题梳理

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

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

一、消息不丢失保障机制

消息丢失风险点

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

生产者保证方案

1. 发送确认机制

java 复制代码

// 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%保证断电不丢消息，需结合生产者确认使用

主从同步策略

RocketMQ普通集群
- 角色模式：ASYNC_MASTER/SYNC_MASTER/SLAVE
- 故障处理：Master宕机后Slave不切换，等待恢复避免数据丢失
Kafka机制差异
- Leader切换后，旧Leader未同步数据直接丢弃（可用性优先）
Dledger集群（推荐）
- 基于Raft协议实现多数派写入
- 网络分区时可能丢失未确认消息

消费者保障

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

java 复制代码

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

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

极端场景：全集群宕机

降级方案：

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

二、消息顺序性保障

局部有序实现原理

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

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

三、消息幂等性保障

重复消费场景

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

解决方案

生产者端

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

消费者端

java 复制代码

// 业务层幂等处理示例
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

五、课程核心总结

设计哲学差异：
- RocketMQ：金融级数据安全（阿里系）
- Kafka：高吞吐日志处理（LinkedIn）
- RabbitMQ：灵活消息路由（传统企业）
方案选择本质：

业务场景技术选型参数调优监控迭代

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