前言
emm，今天本來沒準備發文的。突然發文的原因是因為，早上@碼海的號主發了下面這張圖片
好傢夥，這位兄臺白嫖了我的文章，然後換個標題轉發到了掘金上就上了首頁，閱讀，點讚等數據都很好。
哎，反觀我兩年前，發的這篇文章，至今還沒有一個點讚[苦澀][苦澀]
當然這哥們還給我留了原文章出處，現在更多情況就是直接複製粘貼，然後就成為他自己的文章了，關鍵是什麼，文章數據還比原作者還好[苦澀][苦澀]
昨天看到@沉默王二 二哥的文章，自己原創的文章發在知乎上被投訴成為不規範轉載，原連結還是一個抄襲者 CSDN 的文章？？？
垃圾知乎，一言不合就幹掉正義？
算了，不說這些不開心的啦，今天就重發下這篇文章，標題浮誇點，直接用這位白嫖者的標題，你白嫖我的文章，我用下你的標題，沒毛病吧~
標題雖然有點標題黨，不過文章真的是由內容的，之前@愛笑架構師雷架轉載這篇文章，沒想到閱讀數據還不錯。說真的要不是他轉載，我還忘了之前寫過這篇文章。。。
好了，不說了，不說了，要去上班了。
寫於2021.01.08 8點55
這次使用分布式事務框架過程中了學習了一些分布式事務知識，所以本文我們就來聊聊分布式事務那些事。首先我們先回顧下什麼是事務。
事務什麼是事務？這個作為後端開發，日常開發中只要與資料庫有交互，肯定就會使用過事務。現在摘抄一段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，釋放資源。
三階段任然不能解決數據一致性問題。若協調者發出回滾命令，但是由於網絡問題，參與者在等待時間內都無法接收到，這時參與者默認提交事務，而其他事務進行了回滾，造成事務不一致。
TCCTCC 事務
為了解決在事務運行過程中大顆粒度資源鎖定的問題，業界提出一種新的事務模型，它是基於業務層面的事務定義。鎖粒度完全由業務自己控制。它本質是一種補償的思路。它把事務運行過程分成 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 性能較高，可以保證數據最終一致性。但是對於應用層來說，一個方法必須改造成三個方法，且業務中需引入一些中間狀態，相對而言應用改造程度較大。
如果覺得好的話，請幫作者點個讚唄~ 謝謝
喜歡本文的讀者們，歡迎長按關注訂閱號小黑十一點半~
讓我與你分享程序那些事。
我的夢想是做科學家，你支持我嗎？