分布式消息服務(wù)DMS如何實現(xiàn)死信消息的消費，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。
創(chuàng)新互聯(lián)建站堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計制作、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的宿城網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
死信消息是什么
死信消息是指無法被正常消費的消息。分布式消息服務(wù)DMS支持對消息進(jìn)行異常處理。當(dāng)消息進(jìn)行多次重復(fù)消費仍然失敗后，DMS會將該條消息轉(zhuǎn)存到死信隊列中，有效期為72小時，用戶可以根據(jù)需要對死信消息進(jìn)行重新消費。消費死信消息時，只能消費該消費組產(chǎn)生的死信消息。全局有序的普通隊列的死信消息依然按照先入先出（FIFO）的順序存儲在死信隊列中。
如何消費死信消息
消費指定消費組產(chǎn)生的死信消息?？赏瑫r消費多條消息，每次消費的消息負(fù)載不超過512KB。僅NORMAL隊列和FIFO隊列可以開啟死信消息，因為只有NORMAL隊列和FIFO隊列可消費死信消息。
URI
GET /v1.0/{project_id}/queues/{queue_id}/groups/{consumer_group_id}/deadletters?max_msgs={max_msgs}&time_wait={time_wait}&ack_wait={ack_wait}
參數(shù)說明請參見下表：
名稱 | 類型 | 是否必選 | 說明 | 取值范圍 |
project_id | string | 是 | 項目ID。 | N/A |
queue_id | string | 是 | 指定的隊列ID。 | N/A |
consumer_group_id | String | 是 | 消費組的ID。從查看指定隊列的所有消費組的響應(yīng)消息中獲取消費組ID。 | N/A |
max_msgs | int | 否 | 獲取可消費的死信消息的條數(shù)。 說明： 單次消費返回的消息數(shù)量可能會少于指定條數(shù)，但多次消費最終可獲取全部消息。 | 取值范圍：1~10。 默認(rèn)值：10 |
time_wait | int | 否 | 設(shè)定消費組中可消費的死信為0時的讀取消息等待時間。 如果在等待時間內(nèi)有新的死信消息，則立即返回消費結(jié)果，如果等待時間內(nèi)沒有新的死信消息，則到等待時間后返回消費結(jié)果。 | 取值范圍：1~60s 默認(rèn)值：3s 說明：不帶該參數(shù)或者配置為空，都默認(rèn)為3s。 |
ack_wait | int | 否 | commit提交超時時間，在該時間內(nèi)提交確認(rèn)，確認(rèn)有效，如果超過指定時間，系統(tǒng)會報消息確認(rèn)超時，或handler無效。 | 取值范圍：15~300s 默認(rèn)值：30s 說明：不帶該參數(shù)或者配置為空，都默認(rèn)為30s。 |
響應(yīng)參數(shù)
參數(shù) | 類型 | 描述 |
message | JSON對象 | 消息的內(nèi)容 |
handler | string | 消息handler |
message參數(shù)
參數(shù) | 類型 | 描述 |
body | JSON | 消息體的內(nèi)容。 |
attributes | JSON對象 | 屬性的列表。 |
如何確認(rèn)已消費死信消息
在消費者消費死信消息期間，死信消息仍然停留在隊列中，但死信消息從被消費開始的30秒內(nèi)不能被該消費組再次消費，若在這30秒內(nèi)沒有被消費者確認(rèn)消費，則DMS認(rèn)為死信消息未消費成功，將可以被繼續(xù)消費。
如果死信消息被確認(rèn)消費成功，該死信消息將不能被該消費組再次消費，死信消息的保留時間為72小時（除非消費組被刪除），72小時后會被刪除。
消息批量消費確認(rèn)時，必須嚴(yán)格按照消息消費的順序提交確認(rèn)，DMS按順序判定消息是否消費成功，如果某條消息未確認(rèn)或消費失敗，則不再繼續(xù)檢測，默認(rèn)后續(xù)消息全部消費失敗。建議當(dāng)對某一條消息處理失敗時，不再需要繼續(xù)處理本批消息中的后續(xù)消息，直接對已正確處理的消息進(jìn)行確認(rèn)。
注意，僅NORMAL隊列和FIFO隊列可以開啟死信消息，因為只有NORMAL隊列和FIFO隊列可消費死信消息。
URI
POST /v1.0/{project_id}/queues/{queue_id}/groups/{consumer_group_id}/deadletters/ack
參數(shù)說明請參見下表：
名稱 | 類型 | 是否必選 | 說明 |
project_id | string | 是 | 項目ID。 |
queue_id | string | 是 | 隊列ID。 |
consumer_group_id | string | 是 | 消費組ID。 |
請求參數(shù)和message參數(shù)如下表所示：
名稱 | 類型 | 是否必選 | 說明 |
message | array | 是 | 確認(rèn)消息數(shù)組。 |
名稱 | 類型 | 是否必選 | 說明 |
handler | string | 是 | 消費時返回的ID。 |
status | string | 是 | 客戶端處理數(shù)據(jù)的狀態(tài)。 取值為“success”或者“fail”。 |
響應(yīng)參數(shù)
響應(yīng)參數(shù)如下表所示：
參數(shù) | 類型 | 描述 |
success | int | 確認(rèn)成功的數(shù)目（如果為N，則表示前N條死信消息確認(rèn)成功）。 |
fail | int | 確認(rèn)失敗的數(shù)目（如果為N，則表示后N條死信消息確認(rèn)失敗）。 |
看完上述內(nèi)容，你們掌握分布式消息服務(wù)DMS如何實現(xiàn)死信消息的消費的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！
重慶分公司
重慶分公司
