本文部分內容節選自華為雲幫助中心的分布式訊息服務（dms）服務的產品介紹
死信訊息是什麼
死信訊息是指無法被正常消費的訊息。分布式訊息服務dms支援對訊息進行異常處理。當訊息進行多次重複消費仍然失敗後，dms會將該條訊息轉存到死信佇列中，有效期為72小時，使用者可以根據需要對死信訊息進行重新消費。消費死信訊息時，只能消費該消費組產生的死信訊息。全域性有序的普通佇列的死信訊息依然按照先入先出（fifo）的順序儲存在死信佇列中。
如何消費死信訊息
消費指定消費組產生的死信訊息。可同時消費多條訊息，每次消費的訊息負載不超過512kb。僅normal佇列和fifo佇列可以開啟死信訊息，因為只有normal佇列和fifo佇列可消費死信訊息。
uriget /v1.0//queues//groups//deadletters?max_msgs=&time_wait=&ack_wait=
引數說明請參見下表：
引數說明
名稱
型別
是否必選
說明
取值範圍
project_id
string
是專案id。
n/aqueue_id
string
是指定的佇列id。
n/aconsumer_group_id
string
是消費組的id。從檢視指定佇列的所有消費組的響應訊息中獲取消費組id。
n/amax_msgs
int否
獲取可消費的死信訊息的條數。
說明：
單次消費返回的訊息數量可能會少於指定條數，但多次消費最終可獲取全部訊息。
取值範圍：1~10。
預設值：10
time_wait
int否
設定消費組中可消費的死信為0時的讀取訊息等待時間。
如果在等待時間內有新的死信訊息，則立即返回消費結果，如果等待時間內沒有新的死信訊息，則到等待時間後返回消費結果。
取值範圍：1~60s
預設值：3s
說明：不帶該引數或者配置為空，都預設為3s。
ack_wait
int否
commit提交超時時間，在該時間內提交確認，確認有效，如果超過指定時間，系統會報訊息確認超時，或handler無效。
取值範圍：15~300s
預設值：30s
說明：不帶該引數或者配置為空，都預設為30s。
響應引數
引數
型別
描述
message
json物件
訊息的內容。
handler
string
訊息handler。
message引數
引數
型別
描述
body
json
訊息體的內容。
attributes
json物件
屬性的列表。
如何確認已消費死信訊息
在消費者消費死信訊息期間，死信訊息仍然停留在佇列中，但死信訊息從被消費開始的30秒內不能被該消費組再次消費，若在這30秒內沒有被消費者確認消費，則dms認為死信訊息未消費成功，將可以被繼續消費。
如果死信訊息被確認消費成功，該死信訊息將不能被該消費組再次消費，死信訊息的保留時間為72小時（除非消費組被刪除），72小時後會被刪除。
訊息批量消費確認時，必須嚴格按照訊息消費的順序提交確認，dms按順序判定訊息是否消費成功，如果某條訊息未確認或消費失敗，則不再繼續檢測，預設後續訊息全部消費失敗。建議當對某一條訊息處理失敗時，不再需要繼續處理本批訊息中的後續訊息，直接對已正確處理的訊息進行確認。
注意，僅normal佇列和fifo佇列可以開啟死信訊息，因為只有normal佇列和fifo佇列可消費死信訊息。
uripost /v1.0//queues//groups//deadletters/ack
引數說明請參見下表：
引數說明
名稱
型別
是否必選
說明
project_id
string
是專案id。
queue_id
string
是佇列id。
consumer_group_id
string
是消費組id。
請求引數和message引數如下表所示：
請求引數
名稱
型別
是否必選
說明
message
array
是確認訊息陣列。
message引數
名稱
型別
是否必選
說明
handler
string
是消費時返回的id。
status
string
是客戶端處理資料的狀態。
取值為「success」或者「fail」。
響應引數
響應引數如下表所示：
表4響應引數
引數
型別
描述
success
int確認成功的數目（如果為n，則表示前n條死信訊息確認成功）。
fail
int確認失敗的數目（如果為n，則表示後n條死信訊息確認失敗）。
分布式服務如何設計分布式事務
1 如果a b c強相關 考慮採用tcc框架 try confirm cancel bytetcc，himly 阿里的fescar，seata 推薦使用seata tcc框架 2 如果a 與bc並不強相關 考慮可靠訊息最終一致性解決方案，例如a成功後通過傳送kafka事件，bc監聽事件來處理。roc...
訊息佇列實現分布式事務
訊息佇列中的 事務 主要解決的是訊息生產者和訊息消費者的資料一致性問題。電商下單步驟 1 生成訂單 2 刪除購物車 在分布式系統中，任何乙個步驟都有可能失敗，可能出現訂單資料與購物車資料不一致的情況，比如說 1 建立了訂單，沒有清理購物車 2 訂單沒建立成功，購物車裡面的商品卻被清掉了。訂單系統給訊...
分布式訊息佇列
以下是訊息佇列以下的大綱，本文主要介紹訊息佇列概述，訊息佇列應用場景和訊息中介軟體示例 電商，日誌系統 訊息佇列概述 訊息佇列應用場景 訊息中介軟體示例 jms訊息服務 見第二篇 大型 架構系列 分布式訊息佇列 二 常用訊息佇列 見第二篇 大型 架構系列 分布式訊息佇列 二 參考 推薦 資料 見第二...