| 導讀 | 分散式事務往往是服務化的痛點，很多場景透過業務避免了分散式事務，但是還是存在一些場景必須依賴分散式事務，下面來講講如何處理分散式事務 |
解決分散式事務問題的方法有很多種，網路上有很多部落格也提供了各種解決方案。總結起來，一般可以分為以下兩種方式： 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成功，訊息也就成功消費了，完美，解決了訊息可靠服務
三 努力提交這個比較簡單 ，將失敗的訊息重複提交，即時性比較弱的一些場景，確保訊息推送成功。
例如交易完成推播第三方訊息。此時可以使用努力提交
以上是探討實現可靠的訊息服務的詳細內容。更多資訊請關注PHP中文網其他相關文章！
