一、消息应答的概念
消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并仅只完成 了部分突然它挂掉了，会发生什么情况。RabbitMQ 一旦向消费者传递了一条消息，便立即将该消 息标记为删除。在这种情况下，突然有个消费者挂掉了，我们将丢失正在处理的消息。以及后续 发送给该消费这的消息，因为它无法接收到。
为了保证消息在发送过程中不丢失，rabbitmq 引入消息应答机制，消息应答就是:消费者在接 收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了，rabbitmq 可以把该消息删除了。
二、自动应答
消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权 衡,因为这种模式如果消息在接收到之前，消费者那边出现连接或者 channel 关闭，那么消息就丢 失了,当然另一方面这种模式消费者那边可以传递过载的消息，没有对传递的消息数量进行限制， 当然这样有可能使得消费者这边由于接收太多还来不及处理的消息，导致这些消息的积压，最终 使得内存耗尽，最终这些消费者线程被操作系统杀死。所以这种模式仅适用在消费者可以高效并 以某种速率能够处理这些消息的情况下使用。
三、消息应答的方法
Channel.basicAck(用于肯定确认)
RabbitMQ 已知道该消息并且成功的处理消息，可以将其丢弃了
Channel.basicNack(用于否定确认)
Channel.basicReject(用于否定确认) 与 Channel.basicNack 相比少一个参数 不处理该消息了直接拒绝，可以将其丢弃了
四、Multiple 的解释
手动应答的好处是可以批量应答并且减少网络拥堵
multiple 的 true 和 false 代表不同意思 ：
true 代表批量应答 channel 上未应答的消息。比如说 channel 上有传送 tag 的消息 5、6、7、8，当前tag 是 8，那么此时 5-8 的这些还未应答的消息都会被确认收到消息应答
false 同上面相比 ，只会应答 tag=8 的消息，5、6、7 这三个消息依然不会被确认收到消息应答
五、消息自动入队
如果消费者由于某些原因失去连接(其通道已关闭，连接已关闭或 TCP 连接丢失)，导致消息 未发送 ACK 确认，RabbitMQ 将了解到消息未完全处理，并将对其重新排队。如果此时其他消费者 可以处理，它将很快将其重新分发给另一个消费者。这样，即使某个消费者偶尔死亡，也可以确 保不会丢失任何消息。
这里需要注意的是，一个消息只能被处理一次，不能被处理多次。
例如：
这是正常的消息分发情况
现在C1消费者失去连接，由于没有发送ACK确认，MQ也不知道C1具体处理了多少消息
但是C2可以处理消息，那么就将消息重新入队，由C2来处理
C2处理C1的消息
六、消息手动应答
默认消息采用的是自动应答，所以我们要想实现消息消费过程中不丢失，需要把自动应答改为手动应答。消息在手动应答中不丢失，而是在消费者挂掉后，被放回队列中重新消费。
