rabbitMQ的消费者消息确认机制的说明 Consumer ACK

---

## rabbitMQ如何保证消息被消费者成功消费？

---

前面我们讲了生产者发送确认机制和消息的持久化存储机制，然而这依然无法完全保证整个过程的
可靠性，因为如果消息被消费过程中业务处理失败了但是消息却已经出列了（被标记为已消费了），我
们又没有任何重试，那结果跟消息丢失没什么分别。
RabbitMQ在消费端会有Ack机制，即消费端消费消息后需要发送Ack确认报文给Broker端，告知自
己是否已消费完成，否则可能会一直重发消息直到消息过期（AUTO模式）。
这也是我们之前一直在讲的“最终一致性”、“可恢复性” 的基础。
一般而言，我们有如下处理手段：

1. 采用NONE模式，消费的过程中自行捕获异常，引发异常后直接记录日志并落到异常恢复表，
   再通过后台定时任务扫描异常恢复表尝试做重试动作。如果业务不自行处理则有丢失数据的风
   险
2. 采用AUTO（自动Ack）模式，不主动捕获异常，当消费过程中出现异常时会将消息放回
   Queue中，然后消息会被重新分配到其他消费者节点（如果没有则还是选择当前节点）重新
   被消费，默认会一直重发消息并直到消费完成返回Ack或者一直到过期
3. 采用

@RabbitListener(queues = "topic.queue", ackMode = "AUTO")
public void handleMessageTopic(Channel channel,
@Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag, @Payload byte[]
message) {
	System.out.println("RabbitListener消费消息，消息内容：" + new
String((message)));
try {
// 手动ack，deliveryTag表示消息的唯一标志，multiple表示是否是批量确认
channel.basicAck(deliveryTag, false);
// 手动nack，告诉broker消费者处理失败，最后一个参数表示是否需要将消息重新
入列
channel.basicNack(deliveryTag, false, true);
// 手动拒绝消息。第二个参数表示是否重新入列
channel.basicReject(deliveryTag, true);
} catch (IOException e) {
e.printStackTrace();
}
}