訊息消費異常時會自動進行消費重試，達到最大重試次數後還未成功，則訊息會轉為死信狀態。雲訊息佇列 RocketMQ 版支援將這些死信訊息儲存至指定Topic，方便後續進行業務恢複或回溯。本文介紹死信訊息的應用情境、死信策略、使用限制、配置方法和使用建議。
應用情境
典型死信訊息處理情境
訊息重試失敗後，您可以選擇將死信訊息儲存到指定的死信Topic中，通過另外建立一個ConsumerGroup消費這些死信訊息來處理異常鏈路或分析死信訊息。
典型錯誤使用死信訊息情境
處理死信訊息時，如果將死信訊息多層流轉，轉儲回原Topic，會引起死信訊息再次被迴圈重試，可能會引起雪崩效應。
死信策略
什麼時候訊息會轉為死信狀態
訊息重試達到最大重試次數後還沒有被成功消費，訊息將不再被投遞，轉為死信狀態。
死信訊息儲存規則
雲訊息佇列 RocketMQ 版預設不儲存死信訊息，訊息轉為死信狀態後將被丟棄。
您可以通過控制台開啟死信訊息儲存功能，開啟後，死信訊息將被儲存至指定的Topic中，該Topic被稱為死信Topic。具體操作，請參見配置死信訊息儲存規則。
死信訊息是作為一條新的訊息被儲存到死信Topic中，其訊息屬性變更如下：
Message ID：死信訊息轉儲到死信Topic後會產生新的Message ID。
使用者自訂屬性、訊息體等使用者佈建的資訊不變。
死信訊息的儲存時間長度：從進入死信Topic後重新開始計算。例如，某條訊息生產者發送到服務端的時間為13∶00∶00，2個小時後（15∶00∶00）該訊息消費失敗且重試失敗被儲存至死信Topic，則該訊息的儲存時間長度從15∶00∶00開始計算。
使用限制
儲存死信訊息的Topic只支援普通訊息和順序訊息類型的Topic，事務訊息類型和定時訊息類型的Topic不能作為死信Topic。
不支援將生產原訊息的Topic作為死信Topic（避免出現迴圈雪崩的問題）。在死信訊息轉存流程中，若系統發現死信Topic和生產訊息的原Topic相同，則該條訊息將被丟棄。
不同Topic的死信訊息可以儲存到同一個死信Topic中。
刪除某個ConsumerGroup時，對應的死信Topic不會被刪除。
若某個Topic被死信策略引用，刪除該Topic前，您必須先解除該Topic的死信策略關係。
配置死信訊息儲存規則
您可以在雲訊息佇列 RocketMQ 版控制台配置是否儲存死信訊息。
操作入口如下：
在執行個體列表頁面中單擊目標執行個體名稱。
在左側導覽列單擊Group 管理，然後在Group 管理頁面單擊创建 Group。
死信訊息可觀測指標
指標說明
指標類型 | 指標項 |
rocketmq_send_to_dlq_messages：每分鐘轉為死信狀態的訊息量 | |
|
指標應用
雲訊息佇列 RocketMQ 版支援配置死信訊息相關警示，可以協助您在業務反饋前及時發現異常，並結合Dashboard指標結果可以進一步排查異常來源。
情境一：查看每分鐘轉成死信狀態的訊息量
您可以在儀錶盤中查看每分鐘轉為死信狀態的訊息量的錶盤資料，也可以通過CloudMonitor添加每分鐘轉為死信狀態的訊息量（GroupId&Topic）警示進行監控。
情境二：查看還有多少死信訊息未處理
當死信訊息被儲存至指定Topic中，您可以在儀錶盤中查看指定死信Topic的消費堆積量指標資料，也可以通過CloudMonitor添加訊息堆積量（GroupId&Topic）警示進行監控。
使用建議
消費者如何擷取原Topic資訊
方案一：在設定死信Topic時，將死信Topic和原Topic進行一一對應。
例如，原訊息Topic為testTopic，則將死信Topic設定為DLQ-testTopic。
方案二：將原Topic的資訊設定到訊息的自訂屬性中。樣本如下：
messageBuilder.addProperty("originalTopic","testTopic")
死信訊息和主業務區分處理
死信訊息是正常商務程序中訊息重試仍然失敗的訊息，需要和主商務程序分開處理，避免影響正常業務。
死信Topic和原訊息發送Topic不能相同，避免死信訊息通過迴圈配置流轉回原Topic，導致無法消費的訊息影響正常的ConsumerGroup業務，引起業務雪崩。
避免使用生產流程中的ConsumerGroup去消費死信訊息，影響正常訊息的消費。