RabbitMQ消费过程中对消息ack处理不当,经常会带来一下的问题:
- 消息ack异常造成消息处于unack状态,一直pending得不到正常处理;
- 依赖rabbitmq自身的nack的enqueue逻辑,让消息重新入列,反复的处理,造成死循环;大量出现时会引起rabbitmq server端的内存泄露问题(3.5.x版,3.6.x之后没有测试过);
- 消息快速重试造成下游消费的负载严重过高,缺乏较好的容错机制;
- 重试消息进入同一个queue,对消费延迟要求比较苛刻的程序,会造成一定的延时影响,特别大量重试情况下;
为解决以上问题:
1. 封装用户直接调用ack接口,而是由用户处理完逻辑后,通过返回状态值k来进行内部ack处理比如:比如重试,丢弃,消费完成等状态;
2. 消费消息成功时,内部提交直接 basicack完成就好;
3. 消费失败时,如果需要重试,则将消息发回到独立的重试队列(内部declare的一个队列%RETRY%queue),该队列的消息发布时有一定的特殊性,后续会有介绍;
4. 消费失败,但不需要重试,直接采用basicNack(ackIdx, false, false)丢弃该消息;
针对以上重试机制,采用不同延时的等级来进行