這篇文章帶給大家的內容是關於分散式事務的圖文詳解，有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。
這次使用分散式事務框架過程中了學習了一些分散式事務知識，所以本文我們就來聊聊分散式事務那些事。首先我們先回顧下什麼是事務。
交易
什麼是交易？這個作為後端開發，日常開發中只要與資料庫有交互，肯定就會使用過事務。現在摘抄一段wiki的解釋，解釋下什麼是事務。
是資料庫管理系統執行過程中的一個邏輯單位，由一個有限的資料庫操作序列構成
#資料庫系統具有事務特性，這是其有別與檔案系統重要特性。傳統的文件系統，如果正在寫文件，作業系統突然崩潰，此時文件可能被破壞。資料庫系統引入事務特性，可以保證資料庫從一種狀態轉換為另一種狀態。在提交工作時,可以確保要么所有修改都被保存，要么所有都不保存。
通常一個交易會有多個讀寫操作構成。
事務有四個基本特性，俗稱ACID。
A(Atomicity):原子性。事務會被當做一個整體，要麼所有語句都成功，要麼都失敗，不能存在部分語句成功，部分失敗的情況。
C(Consistenc):一致性。資料庫的狀態從一種狀態轉變為另一種狀態，事務開始之前和是事務結束之後，資料庫完整性約束不變。什麼叫資料庫完整性約束不變？舉個例子，若一個表格姓名欄位為唯一約束，若在交易提交或回溯後，姓名欄位變成非唯一了，這就破壞資料庫的完整性約束。
I(Isolation):隔離性。多個並發事務執行，互不影響。
D(Durability):持久性。事務提交之後，其對資料庫相關修改能永久保存在資料庫中。所以該特性需要資料庫系統可以在崩潰時需要復原時也能提交的資料都不遺失。
因此早期我們的系統只在存在一個資料來源情況下，這個時候可以依靠資料庫系統事務來保證業務的正確性。
但是隨著業務的不斷擴展，我們業務的一個單表可能就存在千萬數據，在使用再使用一個資料庫實例，就會可能存在性相關能問題。這時候我們就會考慮分庫分錶。但是這樣就有可能導致，單一應用連接多個資料來源的情況。如下圖範例。
上圖一次購買過程，商家餘額表與使用者餘額表處於兩個單獨的資料庫實例中，這樣單獨的事務能保證扣減商家餘額或用戶餘額要麼扣減成功，要麼扣減失敗。但是我們卻無法保證兩個事務同時成功或同時失敗。
還有一種情況，隨著系統越來越龐大，我們會選擇將系統應用程式拆分多個微服務，讓單一應用程式只操作一個資料來源。這時候我們就會碰到，一次業務調用，將會調用多個應用，每個應用單獨操作資料來源的情況，如下圖。
這種情況下我們更無法保證所有呼叫都會成功。
由上面的例子下我們可以看出，隨著業務發展，傳統的單機事務已經無法滿足我們的業務的需求，這個時候我們就需要分散式事務來保證。
分散式交易
摘抄一段 wiki 上解釋。
A distributed transaction is a database transaction in which two or more network hosts are involved.
我們先來講下實現分散式事務一些理論基礎。
分散式事務技術理論
CAP 定理。在一個分散式系統（指互相連接並共享資料的節點的集合）中，當涉及讀寫操作時，只能保證一致性（Consistence）、可用性（Availability）、分區容錯性（Partition Tolerance）三者中的兩個，另外一個必須被犧牲。
摘錄極客時間從0開始學架構第22章解釋
雖然 CAP 理論定義是三個要素中只能取兩個，但放到分散式環境下來思考，我們會發現必須選擇 P（分區容忍）要素，因為網路本身無法做到 100%
可靠，有可能出故障，所以分區是必然的現象。如果我們選擇了 CA 而放棄了 P，那麼當發生分區現象時，為了保證
C，系統需要禁止寫入，當有寫入請求時，系統會傳回 error（例如，目前系統不允許寫入），這又和 A 衝突了，因為 A 要求回傳 no error
和 no timeout。因此，分散式系統理論上不可能選擇 CA 架構，只能選擇 CP 或 AP 架構
BASE 理論，分別是以下三個單字的縮寫。
Basically Available（基本上可用）：分散式系統在發生故障時，允許損失部分可用功能，確保核心功能可用。
Soft state（軟狀態）：允許系統中存在中間狀態，這個狀態不會影響系統可用性，這裡指的是CAP中的不一致。
Eventually consistent（最終一致性）：最終一致是指經過一段時間後，所有節點資料都會達到一致。
BASE 是CAP 中 AP 方案的一種補充。在 BASE 中用軟狀態和最終一致，保證了延遲後的一致性。 BASE 和 ACID 是相反的，ACID 是一種強一致性模型，而 BASE 是犧牲這種強一致性，允許資料在短時間內不一致，最終一致性。
接下來我們來看看分散式事務有哪幾種實作方案。
分散式事務實作方案
基於資料庫資源層級
#基於業務層級
基於資料庫資源層面實作方案，由於存在多個事務，我們需要存在一個角色管理各個事務的狀態。我們將這個角色稱為協調者，事務參與者稱為參與者。參與者與協調者一般會基於某種特定協議，目前比較有名的為 XA 介面協議。基於協調者與參與者的想法設定，分別提出了 2PC 與 3PC 實現XA 分散式事務。
2PC 兩階段提交協議
如名字所知，這個過程主要分為兩個步驟。
第一階段，協調者(事務管理器)將涉及到事務的進行預先提交，這個時候資料庫資源開始被鎖定。參與者將 undo 與 redo 寫入交易日誌。
第二階段，參與者（資源管理器）行提交事務，或利用 undo 日誌回溯事務，釋放資源。
整個過程如下圖。
分散式交易提交成功場景：
#分散式交易回溯場景：
#此方案的優點為:實作比較簡單，主流資料庫都支持，強一致性。 MySQL 5.5 以後基於 XA 協定實作.
相應該方案也存在缺點:
協調者的單點問題。若協調者在提交階段宕機，參與者一直在等待,就一直鎖定資源，一直阻塞。雖然可以重新選舉協調者，但是無法解決這個問題。
同步阻塞時間過長，整個執行過程事務是阻塞的，直到提交完成，釋放資源，若在提交過程/回滾過程，因為網絡延時，參與者一直未收到指令，則參與者一直被阻塞。
資料不一致。第二階段，協調者發出第一個提交訊號後後宕機，則第一個參與者提交事務，第二個參與者因為未收到協調者訊號，無法進行事務提交。
於是針對 2PC 存在的缺點，提出改進方案，3PC。
3PC 三階段提交協議
三階段提交，在兩階段提交的基礎下，改進兩階段。三階段步驟如下。
CanCommit,協調者詢問參與者是否可以進行事務提交。
PreCommit ,若所有參與者可以進行事務提交，協調者下達 PreCommit 指令，參與者鎖定資源，並等待最終命令。
Do Commit，若第二階段全部回應 ack，則下達 Do Commit ，進行事務最終提交，否則下達中斷事務命令，所有參與者進行事務回滾。
具體見下圖。
三階段提交對比兩階段，引入超時機制減少交易阻塞，解決單點故障。在第三階段，一旦參與者無法接受到協調者訊號時，等待逾時之後，參與者預設執行 commit，釋放資源。
三階段任然無法解決資料一致性問題。若協調者發出回滾命令，但是由於網路問題，參與者在等待時間內都無法接收到，這時參與者默認提交事務，而其他事務進行了回滾，造成事務不一致。
TCC
TCC 事務
為了解決在事務運作過程中大顆粒度資源鎖定的問題，業界提出一個新的事務模型，它是基於業務層面的事務定義。鎖粒度完全由業務自己控制。它本質是一種補償的思路。它把事務運行過程分成 Try、Confirm / Cancel 兩個階段。在每個階段的邏輯由業務代碼控制。這樣就事務的鎖粒度可以完全自由控制。業務可以在犧牲隔離性的情況下，獲得更高的效能。
TCC 分別為 Trying，Confirm，Cancel 三個單字縮寫。有別於 2PC 與 3PC 是基於資料庫層面，TCC 是基於應用層面。
TCC 三個動作分別為：
Trying：
完成所有業務檢查(一致性)
預留必須業務資源(準隔離性)
Confirm:
Cancel:
#釋放Try階段預留的業務資源
- ##Cancel運算要滿足冪等性
上面說法，一聽起來有點生澀難懂，沒關係我們使用實際案例解釋。
下面我們模擬商城一次支付流程。用戶下單使用組合支付，即餘額加紅包支付。一次正常流程為：
- 建立訂單
- #下單
- 呼叫餘額系統，扣減餘額
- 呼叫紅包系統，扣減紅包餘額
- 修改訂單狀態為已支付
- 完後付款。
實際流程如下圖。
但是這麼一個支付過程呼叫多個子服務，我們不能保證所有服務都能成功，例如我們在呼叫紅包系統扣減紅包系統失敗。這時候我們就碰到尷尬的場景，由於紅包服務失敗，導致方法異常退出，這個時候訂單狀態為初始狀態，但是用戶餘額已經扣減。這對用戶體驗非常不友善。所以這次支付過程，我們必須存在機制將這次過程當成一次整體的行為，必須保證這其中服務調用，要么都成功，要么都失敗，成為一個整體的事務。
這時我們可以引入 TCC 事務，將整個下單一程序作為一個整體。引進後，由於餘額系統扣減是失敗，這個時候我們回滾訂單系統與紅包系統。整個過程如下圖。
由於餘額系統的失敗，我們需要撤銷這次過程中所有更改，所以我們向訂單系統發送撤銷通知，向紅包系統發出撤銷通知。
因此系統引入 TCC 事務後，我們需要改造我們的呼叫過程。
系統如何引入 TCC 事務
根據 TCC 事務三步，這時候我們必須將各個服務改造成 Try Confirm Cancle 三步驟、
TCC TRY:
根據上面的業務，訂單系統增加 try 方法將訂單狀態修改成 PAYING。餘額系統增加一個 try 方法，先檢查用於餘額是否足夠，然後先將餘額扣減，然後將扣減的餘額增加到凍結金額。紅包系統同餘額系統。從改造過程可以看出，TCC try 方法需檢視各業務資源，且流程需要引入中間狀態。我們根據下圖來看整個過程。
TCC Confirm:
TCC 第一步TRY 如果所有子服務呼叫都成功，這個時候我們就需要確認各服務。各個服務增加 confirm 方法。如餘額系統 confirm 方法用來將凍結金額置為0，紅包系統如上。訂單系統將訂單狀態修改為 SUCCESS。 confirm 方法需要注意實作冪等。如訂單系統更新前，請務必先判斷該筆訂單狀態為 PAYING，才能更新訂單。整個過程如下圖。
講到這裡，必須用到 TCC 事務框架來推動各服務。 TCC 事務管理器感知到 TRY 方法結束後，自動呼叫各服務提供的 confirm 方法，將各服務狀態修改為終態。
TCC Cancle：
如若 TCC Try 過程中，凍結紅包方法失敗，這時我們需要將先前修改撤銷，修改成其初始狀態。 cancle 方法也需要實作冪等如confirm 方法如下圖：
看到這，我們可以看出TCC Try 成功，confirm 一定要成功，try 失敗，cancle 必定成功。因為 confirm 是系統更新為終態的關鍵。但現實這麼無情，生產系統 confirm 或 cancle 肯定會有幾率失敗，這個時候就需要 TCC 框架記錄呼叫 confirm 結果。如果 confirm 呼叫失敗，TCC 框架需要記錄下來，然後間隔一定時間再去呼叫。
總結與思考
看完全文，基本上對分散式事務又一定了解了吧。
我們基於此對此總結下。使用分散式事務，我們需要結合我們實際場景應用。
如果業務還處於開始階段，我們其實可以選擇資料庫事務來保證快速上線迭代。
等到業務一定階段，系統開始拆分，資料庫也拆分，這時如果業務需要保證一致性，這時必須使用分散式事務。這時候使用分散式事務，我們需要基於業務考慮使用哪一個。
使用 2PC 或 3PC 實作的分散式框架，業務應用層無需改動，存取較簡單。但相對應能較低，數據資源鎖定較長。較不適合網路等高並發業務場景。
而使用基於 TCC 實作分散式框架，相對 2PC 效能較高，可以保證資料最終一致性。但對於應用層來說，一個方法必須改造成三個方法，且業務中需引入一些中間狀態，相對而言應用改造程度較大。
#
以上是分散式事務的圖文詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！
