概念

消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了，会发生什么情况。RabbitMQ一旦向消费者传递了一条消息，便立即将该消息标记为删除。在这种情况下，突然有个消费者挂掉了，我们将丢失正在处理的消息。以及后续发送给该消费者的消息，因为它无法接收到。

为了保证消息在发送过程中不丢失，rabbitmq引入了消息应答机制，消息应答就是：消费者收到消息并且处理该消息之后，告诉rabbitmq它已经处理了，rabbitmq可以把该消息删除了。

自动应答

消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权衡，因为这种模式如果消息在接收到之前，消费者那边出现连接或者channel关闭，那么消息就丢失了，当然另一方面这种模式消费者那边可以传递过载的消息，没有对传递的消息数量进行限制，当然这样有可能使得消费者这边由于接收太多还来不及处理的消息，导致这些消息的积压，最终使得内存耗尽，最终这些消费者线程被操作系统杀死，所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。

手动应答

A.Channel.basicAck(用于肯定确认)
RabbitMQ已知道该消息并且成功的处理消息，可以将其丢弃了
B.Channel.basicNack(用于否定确认)
C.Channel.basicReject(用于否定确认)
与Channel.basicNack相比少一个参数
不处理该消息了直接拒绝，可以将其丢弃了

Multiple的解释

手动应答的好处是可以批量应答并且减少网络拥堵

void basicAck(long deliveryTag, boolean multiple) throws IOException;

multiple的true和false代表不同意思

• true代表批量应答channel上未应答的消息，比如说channel上有传送tag的消息5，6，7，8当前tag是8那么此时5-8的这些还未应答的消息都会被确认收到消息应答。
• false同上面相比，只会应答tag=8的消息，5，6，7这三个消息依然不会被确认收到消息应答