Rabbitmq消息重排序分析

一、场景描述

        使用过rabbitmq的同学都知道，客户端在返回Nack时有一个requeue参数，标明是否需要重新排队，没错，的确是这样的。我当时也这么想，可后来进一步思考，到底是放入服务端队列，还是在本地队列呢？

        首先确认以下2点：

        1、如果是放入服务端队列，那么服务端broker的消息会不断增加，应该不可能

        2、消费端断开连接重连后，再次消费消息时，消息还是从队头开始消费

带着疑问，做了一个demo测试一下。

二、过程分析

1、消费端暂且设置qos=5，即服务端会向消费端一次性投递5条消息

 

 

 

2、Consumer消费完0后返回ACK，Broker会删除对应的消息0

 

 

3、继续消费1时，消费端发生了异常并且捕获异常后返回了Nack，且requeue=true

 

大家可以看到，消费端消息消费失败后尝试重新排队，此时消息1回到了本地队列的尾部

4、继续消费2时，消费端又发生了异常并且捕获异常后返回Nack，且requeue=true

 

此时消息2回到了本地队列的尾部

5、继续消费3后返回Ack，Broker和Consumer中的消息3都被删除

注意：如果本地队列中存在未消费完的消息，那么RabbitMQ服务端不会继续投递消息

三、总结

返回Nack且requeue为true时，重新排队是在消费端完成的，对Broker中的队列和消息没有影响