为了保证消息从队列可靠地达到消费者， RabbitMQ 提供了消息确认机制( message acknowledgement), 消费者在订阅队列时，可以指定autoAck参数, ，当autoAck 等于false时,RabbitMQ会等待消费者显式地回复确认信号后才从内存(或者磁盘)中移去消息(实质上是先打上删除标记，之后再删除) 。当autoAck 等于true时，RabbitMQ 会自动把发送出去的消息置为确认, 然后从内存(或者磁盘)中删除，而不管消费者是否真正地消费到了这些消息。
采用消息确认机制后，只要设置autoAck 参数为false ，消费者就有足够的时间处理消息(任务) ，不用担心处理消息过程中消费者进程挂掉后消息丢失的问题，因为RabbitMQ 会一直等待持有消息直到消费者显式调用Basic.Ack 命令为止。
当autoAck 参数置为false ，对于RabbitMQ 服务端而言，队列中的消息分成了两个部分:一部分是等待投递给消费者的消息:一部分是己经投递给消费者，但是还没有收到消费者确认信号的消息。如果RabbitMQ 一直没有收到消费者的确认信号，并且消费此消息的消费者己经断开连接, 则RabbitMQ 会安排该消息重新进入队列，等待投递给下一个消费者，当然也有可能还是原来的那个消费者。
RabbitMQ 不会为未确认的消息设置过期时间，它判断此消息是否需要重新投递给消费者的唯一依据是消费该消息的消费者连接是否己经断开, 这么设计的原因是RabbitMQ 允许消费者消费一条消息的时间可以很久很久。
RabbtiMQ 的Web 管理平台(15672端口)上可以看到当前队列中的" Ready" 状态和"Unacknowledged" 状态的消息数，分别对应上文中的等待投递给消费者的消息数和己经投递给消费者但是未收到确认信号的消息数
也可以通过相应的命令来查看上述信息:
rabbitmqctl list_queues name messages_ready messages_unacknowledged
在消费者接收到消息后，如果想明确拒绝当前的消息而不是确认，那么应该怎么做呢?
RabbitMQ 在2 .0.0 版本开始引入了Basic.Reject 这个命令，消费者客户端可以调用与其对应的channel.basicReject 方法来告诉RabbitMQ 拒绝这个消息。
Channel 类中的basicReject 方法定义如下:
void basicReject(long deliveryTag, boolean requeue) throws IOException;
其中deliveryTag 可以看作消息的编号，它是一个64 位的长整型值，最大值是9223372036854775807, 如果requeue 参数设置为true ，则RabbitMQ 会重新将这条消息存入队列，以便可以发送给下一个订阅的消费者, 如果requeue 参数设置为false ，则RabbitMQ立即会把消息从队列中移除，而不会把它发送给新的消费者。
Basic.Reject 命令一次只能拒绝一条消息，如果想要批量拒绝消息，则可以使用Basic.Nack 这个命令, 消费者客户端可以调用channel.basicNack 方法来实现，方法定义如下:
void basicNack(long deliveryTag, boolean multiple, boolean requeue) throws IOException;
其中deliveryTag 和requeue 的含义可以参考basicReject 方法。multiple 参数设置为false 则表示拒绝编号为deliveryTag的这一条消息，这时候basicNack 和basicReject 方法一样;multiple 参数设置为true 则表示拒绝deliveryTag 编号之前所有未被当前消费者确认的消息。
注意要点:
将channel.basicReject 或者channel.basicNack 中的requeue 设置为false ，可以启用"死信队列"的功能。死信队列可以通过检测被拒绝或者未送达的消息来追踪问题。详细内容后面再说^_^
对于requeue ， AMQP 中还有一个命令Basic.Recover 具备可重入队列的特性。其对应的客户端方法为:
1.Basic.RecoverOk basicRecover() throws IOException; 2.Basic.RecoverOk basicRecover(boolean requeue) throws IOException;
这个channel.basicRecover 方法用来请求RabbitMQ 重新发送还未被确认的消息。如果requeue 参数设置为true, 则未被确认的消息会被重新加入到队列中, 这样对于同一条消息来说，可能会被分配给与之前不同的消费者。如果requeue 参数设置为false ，那么同一条消息会被分配给与之前相同的消费者, 默认情况下，如果不设置requeue 这个参数，相当于channel.basicRecover(true) ，即requeue 默认为true