rabbitMQ处理消息队列时的自动应答机制浅述

                                                                                                                         原创者：文思

网络资料(基本方向)：

1：当出现异常时，我们需要把这个消息回滚到消息队列要么抛弃此消息：

2：经过开发中的实际测试，当让消息回滚到消息队列时，这条消息不会回到队列尾部，而是仍是在队列头部，这时消费者会立马又接收到这条消息，进行处理，接着抛出异常，进行回滚，如此反复进行。这种情况会导致消息队列处理出现阻塞，消息堆积，导致正常消息也无法运行。对于消息回滚到消息队列，我们希望比较理想的方式时出现异常的消息到达消息队列尾部，这样既保证消息不会丢失，又保证了正常业务的进行，因此我们采取的解决方案是，将消息进行应答，这时消息队列会删除该消息，同时我们再次发送该消息到消息队列，这时就实现了错误消息进行消息队列尾部的方案。

实际应用：

在做jodconvert结合mq进行文档异步转换时，因在process函数中没有捕获convert方法(文档转换时的方法)中抛出的异常，导致mq的消费方(process函数)接收消息消费时失败->返回队列第一位->执行->消费失败->返回队列第一位,如此反复导致后续mq消息被阻塞无法接收执行，用catch()捕获异常后，线应答成功，不会再次进入队列执行，解决。

以此总结出mq自动应答的1个知识点：

Spring 与RabbitMq集成对消息的处理方式是默认自动应答(百度)，但是mq消息消费与否的标志，网络上百度出来的资料有些是错误的，现在通过程序来进行验证和判断，结论是：以process函数是否抛出异常或者异常是否被catch捕获为标准，以下是程序推论：

process是消息放处理接收mq消息函数

在使用mq消息进行业务处理的过程中，也就是使用消息进行业务处理的时候（convertUrl = queueBusinessHandlerService.ms2pdfByQueueExternalUtil(inputUrl)），什么情况下系统会认为消息消费不会失败，已经应答了呢，现在验证异常依次上抛，在最外层捕获(异常一定要依次通过throw抛出，否则程序就因为发生异常而中断)：

1

1.1

1.1.

1.1.1

1.1.1.1

从1.1.1.1依次上抛到1

然后在最外层捕获：

通过命令行看日志可以看到，不会再执行那条mq记录了，也就说明：

当convertUrl = queueBusinessHandlerService.ms2pdfByQueueExternalUtil(inputUrl)抛出异常时被catch捕获，则process方法会认为消息消费成功，因为异常被捕获了嘛，process程序体没有中断，执行完了，所以认为消费成功，进行了自动应答，即使业务函数处理失败了，也不在会出现队列中了。

如果需要对失败的记录进行处理，建议在catch{}中：

//手动进行应答channel.basicAck(msg.getMessageProperties().getDeliveryTag(), false);

//重新发送消息到队列尾部channel.basicPublish(message.getMessageProperties().getReceivedExchange(),message.getMessageProperties().getReceivedRoutingKey(), MessageProperties.PERSISTENT_TEXT_PLAIN,JSON.toJSONBytes(new Object()));

不需要再次处理的就不用管了。

什么情况下算消费失败，没有应答成功呢，如果不在process中捕获异常，或者在try{}catch(){}以外的地方发生异常，如下：

process中报了异常且没有被catch捕获，则process认为消息接收时出现错误，没有消费成功，则自动返回到队里第一位，再次重复执行：

.

反复回到队列重复执行...

.

在使用spring boot时，默认的是自动应答，如果想手工应答，在application.propretes中：

spring.rabbitmq.listener.acknowledge-mode=manual

则：

mq顺利执行完没有报错，但再次发送mq：

无法接收到新的mq消息。就需要在程序中进行手工消息应该操作：