RabbitMQ-ack、nack、reject、unacked

1. 不做任何ack

如果队列使用的是手动ack，但在接收消息后不做任何ack处理，RabbitMQ会把消息标记为 unacked，unacked状态的消息不会被消费，并且占用RabbirMQ资源，只有当消费者channel断开或者服务器重启，消息才会重新回到ready状态被其他消费者消费。

2. ack

确认签收后，消息从队列中删除。

• 自动ack

  消费者接收到消息的那一刻就发送ack信息到RabbitMQ的队列，队列将此条消息删除。

  自动ack的方式只要队列有消息，RabbitMQ会源源不断的把消息推送给客户端，而不管客户端能否消费的完。

• 手动ack

  开发人员决定什么时机进行ack。

  如果没有及时进行ack，RabbitMQ会将来不及做ack的消息标记为unacked丢回RabbitMQ，被标记为unacked的消息无法被立刻重新消费，而是要等channel重启或者服务器重启才会变成ready（可消费的消息）。但等待服务器重启这个过程中如果积压了太多unacked消息，会导致MQ响应越来越慢，甚至崩溃的问题。

  解决方式就是及时处理消息😁（废话）

3. reject

如果消息本身或者消息的处理过程出现问题怎么办？

需要一种机制通知RabbitMQ，这个消息我无法处理，请让别的消费者处理。这里就有两种机制，Reject和Nack。

reject和Nack的差别只有一种 ：reject一次只能拒绝一条消息，Nack支持批量拒绝。

还记得死信队列中的消息来源吗？有一条就是“被拒绝的消息”。

在拒绝消息时，可以使用requeue标识。

requeue为true，被拒绝的消息会重新发送给别的队列（一般为死信队列），发送的消息在队首。

requeue为false，不重新发送，这个消息就会被丢弃。

// requeue: 该消息是否重新入队
void basicReject(long deliveryTag, boolean requeue);

4. Nack

nack与reject作用相同，不过它支持批量处理多条消息。

// multiple：是否批量.true:将一次性拒绝所有小于deliveryTag的消息。
// requeue：被拒绝的是否重新入队列
void basicNack(long deliveryTag, boolean multiple, boolean requeue);

但是这两种方式都会出现一种情况 ：消息被发送到其他队列或者本队列之后，一直重复消费，为什么呢？

因为reject和nack会将消息发送到队列首部，这个消息本来就出现异常拒绝消费了，你放在首部，下一次它又被发送，又拒绝、又发送、又拒绝，一直套娃。。。当然新的消息不会消费，导致消费堆积。