探討實現可靠的訊息服務

導讀	分散式事務往往是服務化的痛點，很多場景透過業務避免了分散式事務，但是還是存在一些場景必須依賴分散式事務，下面來講講如何處理分散式事務

一 常用解決方案

解決分散式事務問題的方法有很多種，網路上有很多部落格也提供了各種解決方案。總結起來，一般可以分為以下兩種方式： 1. 兩階段提交（Two-Phase Commit，簡稱2PC）：這是常見的分散式事務解決方案。在這種方法中，協調者節點負責協調參與者節點的操作，並確保所有節點在提交或回溯時達成一

剛性分散式事務和兩階段提交是一種實現強一致性的機制。 剛性分散式事務是指在分散式系統中，多個參與者節點執行的一系列操作需要確保原子性，即要麼全部成功，要麼全部失敗。這種機制要求所有參與者節點在事務執行過程中遵循相同的協議，透過協調者節點的指導來實現事務的

柔性分散式事務是一種在分散式系統中處理事務的方法。它採用最大努力提交的策略，即盡最大努力去完成事務的提交，但是也允許部分操作失敗。在柔性分散式事務中，通常會使用TCC（Try-Confirm-Cancel）模式來實現事務的管理。 TCC模式將交易分解為三個階段：嘗試（Try）、確認（Confirm）和取消（

先解決分散式交易前提保障：介面必須冪等性，防止訊息重複傳送對業務影響

二 可靠訊息系統設計（這個感覺不錯比較簡單，就拿來分享下）

#如上圖

開始執行 例如：
try{
if(prepare()) { //預傳送階段
doService(); //執行業務邏輯
updateMsgStatus();//更新訊息為確認狀態
}
}

1 預先傳送訊息，try階段，如果預先傳送訊息失敗了，業務還未執行，所以 系統A，B還是一致性的 不需要處理

這一點容易理解

2 預發送訊息成功了，開始執行業務邏輯。執行成功 更新預發送訊息轉態為確認發送。如果 此時業務邏輯執行失敗了，那預發送訊息就不會跟新狀態，此時訊息確認系統就開啟工作，到業務系統1上回查此訊息狀態，此時發現業務執行失敗了，就更新預發送狀態至失敗狀態。

3 如果此時 業務執行成功了訊息也被更新成確認發送了 那就ok 完美。如果訊息更新失敗，還是由訊息確認系統回查轉態 更新此訊息被刪除狀態還是確認發送狀態。

4 訊息者開始消費

1> 例如消費失敗了，此時產生不一致， 訊息恢復系統偵測訊息狀態，重新傳送訊息

2>如果執行業務失敗了，此訊息就不會被確認了，還是由訊息恢復系統偵測訊息狀態，重新傳送訊息

3>如果ask失敗了，還是以上邏輯重新發送上訴重新發送當然有次數限制，不能一直發送，超過最大次數就要進入死信隊列，等待人工幹預了

4> ask成功，訊息也就成功消費了，完美，解決了訊息可靠服務

三 努力提交

這個比較簡單 ，將失敗的訊息重複提交，即時性比較弱的一些場景，確保訊息推送成功。

例如交易完成推播第三方訊息。此時可以使用努力提交

# 文章轉載自 開源中國社群 [http://www.oschina.net]

以上是探討實現可靠的訊息服務的詳細內容。更多資訊請關注PHP中文網其他相關文章！