RabbitMQ-消息确认模式
消息接收确认的实现机制
1、通过 ACK机制（消息确认机制）确认消息是否被正确接收，每个 Message 都要被确认（acknowledged），可以手动ACK 或自动 ACK
2、默认情况下，一个消息被消费者正确消费就会从队列中移除
3、自动确认会在消息发送给消费者后立即确认，但存在丢失消息的可能，如果消费端消费逻辑抛出异常，也就是消费端没有处理成功这条消息，那么就相当于丢失了消息
4、如果消息已经被处理，但后续代码抛出异常，使用 Spring 进行管理的话消费端业务逻辑会进行回滚，这也同样造成了实际意义的消息丢失
5、如果手动确认则当消费者调用 ack、nack、reject 几种方法进行确认，手动确认可以在业务失败后进行一些操作
6、如果某个服务忘记确认 ACK 了，则 RabbitMQ 不会再发送此消息数据给它，只要程序还在运行，没确认的消息就一直是 Unacked 状态，无法被 RabbitMQ 重新投递。
7、ACK 机制还可以起到限流作用，比如在接收到某条消息时休眠几秒钟
ACK确认模式
AcknowledgeMode.NONE：不确认
默认情况下消息消费者是NONE模式，默认所有消息消费成功，会不断的向消费者推送消息。
因为rabbitMq认为所有消息都被消费成功，所以队列中不在存有消息，消息存在丢失的危险
AcknowledgeMode.AUTO：自动确认
在自动确认模式下，消息发送后即被认为成功投递，不管消费者端是否成功处理本次投递
优点：这种模式下吞吐量非常高。
缺点：
1，有可能出现投递丢失的情况，不同于手动确认模式，如果消费者的TCP连接或通道在消息成功交互之前关闭，则此消息会丢失
,2，消费者端过载的问题。在手动确认模式中，可以设置一次最多同时处理多少消息，而自动模式不能设置此值。因此，消费者有可能因为消息无法及时处理，堆积中内存中，内存耗尽而奔溃
3，此种模式只推荐在消费者可以快速且稳定处理投递的消息的场景中使用
AcknowledgeMode.MANUAL：手动确认
消费者收到消息后，手动调用basic.ack/basic.nack/basic.reject后，RabbitMQ收到这些消息后，才认为本次投递成功
手动确认模式可以使用 prefetch，限制通道上未完成的（“正在进行中的”）发送的数量
开启手动确认
#配置rabbitMq 服务器rabbitmq:host: xxxx#rabbitmq相关配置 15672是Web管理界面的端口；5672是MQ访问的端口port: xxxusername: xxxpassword: xx#虚拟host 可以不设置,使用server默认hostvirtual-host: testconnection-timeout: 0#确认消息已发送到队列(Queue)publisher-returns: true#确认消息已发送到交换机(Exchange)publisher-confirm-type: correlated # 设置消费端手动 acklistener:simple:acknowledge-mode: manual
确认消息三种模式
分别为basicAck、basicNack、basicReject
basicAck模式
表示成功确认，使用此回执方法后，消息会被rabbitmq broker删除。
void basicAck(long deliveryTag, boolean multiple)
deliveryTag：消息投递序号，
multiple：是否批量确认，true->将一次性拒绝所有小于deliveryTag的消息。
basicNack模式
表示失败确认，一般在消费消息异常时用到此方法，可以将消息重新投递入队列。
void basicNack(long deliveryTag, boolean multiple, boolean requeue)
deliveryTag：表示消息投递序号。
requeue： 表示消息是否重新入队列，true表示重新投入队列中。
multiple：是否批量;true->将一次性拒绝所有小于deliveryTag的消息。
basicReject模式
basicReject：拒绝消息，与basicNack区别在于不能进行批量操作，其他用法很相似。
void basicReject(long deliveryTag, boolean requeue)
deliveryTag：消息投递序号。
requeue：值为true表示消息重新入队列