Rabbitmq和spring-rabbitmq中的DLX-拒绝消息的一些注意事项

Question

我确实阅读了以下参考资料： https : //www.rabbitmq.com/dlx.html ，但是它不能解决我的疑问，即：
在接受消息的情况下没有问题spring-rabbitmq发送确认并且一切都很好， DLX不知道确认的消息。

问题在于万一拒绝回答，即抛出MessageConverterException怎么办？ 此消息已删除或移至DLX ？

如果还有其他例外情况呢？ 例如Exception ？ 是否将其删除/重新排队/移动到DLX ？

@Gary回答后编辑
我认为，在答案为@Gary之后，我应该添加更多有关我的案例的详细信息以及@Gary答案的一些摘要。 @Gary完全掌握了我的用例。

我不希望重新排队-从不（我害怕循环），但是当抛出异常（例如，丢失与数据库的连接）时，我不想丢失消息-该消息应重新发送给DLX 。 另一方面，消息的转换应视为致命错误-不重新排队，不重新发送到DLX-只是永久删除消息。 通常，在依赖异常的情况下，拒绝（=如果配置，则返回DLX）或接受，从不重新排队。

总结一下@Gary提出的简单方法。
首先 ：我们可以重写ExceptionHandler来管理发送nack / ack，这给了我们完全的控制权。
其次 ：IMO更简单，解决方案是设置defaultRequeueRejected=false并在转换器中引发ImmediateAcknowledgeAmqpException 。 它使RabbitMQ认为答案已被接受（与第一个解决方案的情况相同），而且不会调用侦听器。 **Conclusion**: Using InstantAcknowledgeAmqpException or ExceptionHandler`异常，我们可以完全控制永久拒绝消息（在高级确认下）并重新发送到DLX。

Answer 1

RabbitMQ对异常一无所知。

当容器捕获异常时，它将调用channel.basicReject(deliveryTag, requeue) 。

如果requeue为true，则重新排队该消息。

默认情况下，除此处提到的例外外

osamqp ... MessageConversionException

osmessaging ... MessageConversionException

osmessaging ... MethodArgumentNotValidException

osmessaging ... MethodArgumentTypeMismatchException

java.lang.NoSuchMethodException

java.lang.ClassCastException

requeue设置为true，因此消息被重新排队。

对于这些例外，认为传递是致命的，并且不重新排队该消息，如果配置了该消息，它将进入DLX / DLQ。

容器具有标志defaultRequeueRejected ，默认情况下为true； 如果设置为false ; 没有例外将被重新排队。

对于应用程序级异常，通常，消息将重新排队。 要动态拒绝（而不是重新排队）消息，请确保原因链中存在AmqpRejectAndDontRequeueException 。 这指示容器不要重新排队该消息，它将转到DLX / DLQ（如果已配置）。 此行为由上述defaultRequeueRejected标志启用。

所有这些都在文档中进行了解释，正如我在其他回答中所讨论的那样，您可以使用自定义错误处理程序来更改此行为。 文档中也对此进行了说明。

无法向DLX / DLQ发送某些例外，而不能发送其他例外。 rabbit仅具有二进制选项，可以重新排队，也可以不重新排队；对于后者，如果配置了DLX / DLQ，则所有此类拒绝的消息都将进入DLX / DLQ。

Spring AMQP提供了另一个异常， ImmediateAcknowledgeAmqpException 。 如果您的侦听器抛出此异常，则该消息将被确认为成功处理（ channel.basicAck() ）。 这是容器提供的唯一技术，用于丢弃错误消息而不将其发送到DLX / DLQ。

当然，您的应用程序本身可以丢弃此类消息。

如果你想DLX / DLQ所有业务异常，但下降的转换异常，抛出AmqpRejectAndDontRequeueException （或设置defaultRequeueRejected为false），并引发ImmediateAcknowledgeAmqpException从您的转换器。