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從您的轉換器。