探索分布式事務解決方案：八種方案解析

前面已經學習了分布式事務的基礎理論CAP 理論和 BASE 理論，以理論為基礎，針對不同的分布式場景業界常見的解決方案有2PC、TCC、可靠消息最終一致性、最大努力通知等方案,**以下 總結8 種常見的解決方案，取名 八奇技**。幫助大家在實際的分布式系統中更好地運用事務。。

1.2PC

二階段提交協議（Two-phase commit protocol），簡稱 2PC。2PC是將整個事務流程分為兩個階段：

• 1.準備階段（Prepare phase）
• 2.提交階段（commitphase）

2是指兩個階段，P是指準備階段，C是指提交階段

在計算機中部分關系數據庫如Oracle、MySQL支持兩階段提交協議，如下圖：

• 準備階段（Prepare phase）：事務管理器給每個參與者發送Prepare消息，每個數據庫參與者在本地執行事務，并寫本地的Undo/Redo日志，此時事務沒有提交。（Undo日志是記錄修改前的數據，用于數據庫回滾，Redo日志是記錄修改后的數據，用于提交事務后寫入據文件）
• 提交階段（commit phase）：如果事務管理器收到了參與者的執行失敗或者超時消息時，直接給每個參與者發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據事務管理器的指令執行提交或者回滾操作，并釋放事務處理過程中使用的鎖資源。

注意:必須在最后階段釋放鎖資源

下圖展示了2PC的兩個階段，分成功和失敗兩個情況說明：

• 成功情況：

圖片

• 異常情況：

圖片

2PC優缺點：

優點

• 簡單直觀：邏輯清晰，易于理解和實現。
• 原子性保證:能夠保證跨多個分布式節點的事務的原子性。

缺點：

• 同步阻塞：因為一階段需要鎖定數據庫資源，等待二階段結束才釋放，性能較差，在高并發場景下不適用
• 單點故障問題，如果協調者在第二階段崩潰，參與者可能會無限期地等待指令，因為它們不知道應該提交還是回滾。這使得整個系統容易受到單點故障的影響
• 數據不一致問題，如果在第二階段中協調者向某些參與者發送了提交指令，而其他參與者因為網絡問題沒有收到指令，那么這些沒有收到指令的參與者可能會選擇回滾，導致數據不一致

2.3PC

3PC，即Three-Phase Commit，是一種分布式事務協議，用于在分布式系統中確保多個參與者之間的事務操作的一致性和可靠性。它是在兩階段提交（2PC）協議的基礎上發展而來，解決了2PC協議可能出現的懸掛事務問題。

3PC協議將提交操作分為三個階段，分別是準備階段、提交準備階段和提交階段，每個階段都有對應的操作和協議。

準備階段（CanCommit）：

• 協調者：向所有參與者發送CanCommit準備請求，詢問它們是否可以提交事務。
• 參與者：執行本地事務，檢查是否能夠執行，如果可以執行則返回可以提交，否則返回不可以提交。

提交準備階段（PreCommit）：

• 協調者: 根據參與者的反饋情況決定是否進行提交準備

• 如果所有參與者都返回“可以提交”，協調者向所有參與者發送提交請求，告知它們可以進行提交準備。
• 如果有任何參與者返回“不可以提交”或者超時未響應，則協調者向所有參與者發送中止請求，取消事務。

提交階段（DoCommit/DoAbort）：

• 如果協調者 接收到所有參與者的確認提交消息，則向所有參與者發送最終的提交請求，提交事務。
• 如果協調者接收到任何參與者的中止請求，或者在提交準備階段超時未收到所有參與者的響應，則向所有參與者發送中止請求，取消事務

3PC協議相對于2PC協議的改進在于增加了一個準備階段，使得參與者在準備階段就能夠知道是否可以提交事務，從而避免了懸掛事務問題。然而，3PC協議仍然存在著協調者單點故障、消息丟失等問題，因此在實際應用中并不常見，一般更多地使用2PC、Saga等分布式事務解決方案

3.TCC

TCC是Try、Confirm、Cancel三個詞語的縮寫，TCC要求每個分支事務實現三個操作：預處理Try、確認Confirm、撤銷Cancel。Try操作業務檢查及資源預留，Confirm做業務確認操作，Cancel實現一個與Try相反的操作即回滾操作。TM首先發起所有的分支事務的try操作，任何一個分支事務的try操作執行失敗，TM將會發起所有分支事務的Cancel操作，若try操作全部成功，TM將會發起所有分支事務的Confirm操作，其中Confirm/Cancel操作若執行失敗，TM會進行重試。

• 分支事務成功情況：

圖片

• 分支事務失敗的情況：

圖片

TCC分為三個階段

• Try 階段：是做業務檢查(一致性)及資源預留(隔離)，此階段僅是一個初步操作，它和后續的Confirm 一起才能真正構成一個完整的業務邏輯。
• Confirm 階段：是做確認提交，Try階段所有分支事務執行成功后開始執行 Confirm。通常情況下，采用TCC則認為 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。若Confirm階段真的出錯了，需引入重試機制或人工處理。。
• Cancel 階段：是在業務執行錯誤需要回滾的狀態下執行分支事務的業務取消，預留資源釋放。通常情況下，采用TCC則認為Cancel階段也是一定成功的。若Cancel階段真的出錯了，需引入重試機制或人工處理

TCC需要注意三種異常處理

空回滾

在沒有調用 TCC 資源 Try 方法的情況下，調用了二階段的 Cancel 方法，Cancel 方法需要識別出這是一個空回滾，然后直接返回成功。

出現原因：是當一個分支事務所在服務宕機或網絡異常，分支事務調用記錄為失敗，這個時候其實是沒有執行Try階段，當故障恢復后，分布式事務進行回滾則會調用二階段的Cancel方法，從而形成空回滾。

解決思路是

關鍵就是要識別出這個空回滾。思路很簡單就是需要知道一階段是否執行，如果執行了，那就是正常回滾；如果沒執行，那就是空回滾。

冪等

TCC二階段提交重試機制不會引發數據不一致，要求 TCC 的二階段 Try、Confirm 和 Cancel 接口保證冪等，這樣不會重復使用或者釋放資源。如果冪等控制沒有做好，很有可能導致數據不一致等嚴重問題。

解決思路 在上述“分支事務記錄”中增加執行狀態，每次執行前都查詢該狀態。

懸掛

懸掛就是對于一個分布式事務，其二階段 Cancel 接口比 Try 接口先執行。

出現原因： 在 RPC 調用分支事務try時，先注冊分支事務，再執行RPC調用，如果此時 RPC 調用的網絡發生擁堵，通常 RPC 調用是有超時時間的，RPC 超時以后，TM就會通知RM回滾該分布式事務，可能回滾完成后，RPC 請求才到達參與者真正執行，而一個 Try 方法預留的業務資源，只有該分布式事務才能使用，該分布式事務第一階段預留的業務資源就再也沒有人能夠處理了，對于這種情況，我們就稱為懸掛，即業務資源預留后沒法繼續處理。

解決思路：如果二階段執行完成，那一階段就不能再繼續執行。在執行一階段事務時判斷在該全局事務下，“分支事務記錄”表中是否已經有二階段事務記錄，如果有則不執行Try。

TCC優缺點：

TCC的優點：

• 一階段完成直接提交事務，釋放數據庫資源，性能好
• 無需使用全局鎖，性能最強
• 不依賴數據庫事務，而是依賴補償操作，可以用于非事務型數據庫

TCC的缺點

• 有代碼侵入，需要人為編寫try、Confirm和Cancel接口，太麻煩
• 軟狀態，事務是最終一致
• 需要考慮Confirm和Cancel的失敗情況，做好冪等處理

4. 分布式補償事務（Saga）

Saga是一種長事務的解決方案，它將一個大的分布式事務拆分成多個較小的本地事務，并通過異步消息傳遞來串聯這些本地事務。每個本地事務執行成功后，會發送消息觸發下一個事務的執行。如果某個本地事務失敗，Saga會執行一系列補償操作，保持數據的一致性。

分布式補償事務（Saga） 優缺點

優點

• 靈活性： 允許每個小事務獨立管理，提高了系統的靈活性。
• 減少資源鎖定： 不需要持續占用資源，提高了系統的并發能力。
• 容錯性： 通過定義補償操作來處理失敗，增強了系統的容錯能力。
• 適用于微服務架構： 可以跨服務邊界管理事務，每個服務都可以獨立處理自己的事務和補償邏輯。

缺點

• 復雜性： 實現Saga需要定義每個小事務的補償操作，增加了系統的復雜性。
• 數據一致性： 不能提供即時一致性保證，只能保證最終一致性。
• 補償操作的難度： 在某些情況下，補償操作可能很難實現，特別是當事務有副作用時。
• 測試和調試： 涉及多個服務和補償邏輯，測試和調試可能會更加困難。

在選擇使用Saga模式時，需要仔細考慮業務場景是否適合最終一致性，以及是否能夠有效地實現和管理補償邏輯。對于需要高度一致性保證的場景，可能需要考慮其他事務管理機制。Saga模式在適當的情況下可以為分布式系統帶來靈活性和容錯性，但需要慎重考慮其復雜性和實現難度。

5. 可靠消息最終一致性

可靠消息最終一致性方案：是指當事務發起方執行完成本地事務后并發出一條消息，事務參與方(消息消費者)一定能夠接收消息并處理事務成功，此方案強調的是只要消息發給事務參與方最終事務要達到一致。

此方案是利用消息中間件完成，如下圖：

圖片

事務發起方（消息生產方）將消息發給消息中間件，事務參與方從消息中間件接收消息，事務發起方和消息中間件之間，事務參與方（消息消費方）和消息中間件之間都是通過網絡通信，由于網絡通信的不確定性會導致分布式事務問題。

可靠消息最終一致性方案要解決以下幾個問題

1. 本地事務與消息發送的原子性問題

本地事務與消息發送的原子性問題即：事務發起方在本地事務執行成功后消息必須發出去，否則就丟棄消息。即實現本地事務和消息發送的原子性，要么都成功，要么都失敗。本地事務與消息發送的原子性問題是實現可靠消息最終一致性方案的關鍵問題。 先來嘗試下這種操作，先發送消息，再操作數據庫：

begin transaction；
//1.發送MQ
//2.數據庫操作
commit transation;

這種情況下無法保證數據庫操作與發送消息的一致性，因為可能發送消息成功，數據庫操作失敗立馬想到第二種方案，先進行數據庫操作，再發送消息：

begin transaction；
//1.數據庫操作
//2.發送MQ
commit transation;

這種情況下貌似沒有問題，如果發送MQ消息失敗，就會拋出異常，導致數據庫事務回滾。但如果是超時異常，數據庫回滾，但MQ其實已經正常發送了，同樣會導致不一致。

2. 事務參與方接收消息的可靠性

事務參與方必須能夠從消息隊列接收到消息，如果接收消息失敗可以重復接收消息。

3. 消息重復消費的問題

由于網絡2的存在，若某一個消費節點超時但是消費成功，此時消息中間件會重復投遞此消息，就導致了消息的重復消費。要解決消息重復消費的問題就要實現事務參與方的方法冪等性

6. 本地消息表方案

本地消息表這個方案最初是eBay提出的，此方案的核心是通過本地事務保證數據業務操作和消息的一致性，然后通過定時任務將消息發送至消息中間件，待確認消息發送給消費方成功再將消息刪除。

下面以注冊送積分為例來說明： 共有兩個微服務交互，用戶服務和積分服務，用戶服務負責添加用戶，積分服務負責增加積分。

圖片

交互流程

• 用戶注冊 用戶服務在本地事務新增用戶和增加 ”積分消息日志“。（用戶表和消息表通過本地事務保證一致）

begin transaction；
//1.新增用戶
//2.存儲積分消息日志
commit transation;

這種情況下，本地數據庫操作與存儲積分消息日志處于同一個事務中，本地數據庫操作與記錄消息日志操作具備原子性。

• 定時任務掃描日志

思考:如何保證將消息發送給消息隊列呢？

經過第一步消息已經寫到消息日志表中，可以啟動獨立的線程，定時對消息日志表中的消息進行掃描并發送至消息中間件，在消息中間件反饋發送成功后刪除該消息日志，否則等待定時任務下一周期重試。

• 消費消息

如何保證消費者一定能消費到消息呢？

這里可以使用MQ的ack（即消息確認）機制，消費者監聽MQ，如果消費者接收到消息并且業務處理完成后向MQ發送ack（即消息確認），此時說明消費者正常消費消息完成，MQ將不再向消費者推送消息，否則消費者會不斷重試向消費者來發送消息。

積分服務接收到”增加積分“消息，開始增加積分，積分增加成功后向消息中間件回應ack，否則消息中間件將重復 投遞此消息。由于消息會重復投遞，積分服務的”增加積分“功能需要實現冪等性

7.最大努力通知原則

最大努力通知也是一種基于消息的分布式事務解決方案，但它不保證 100% 的消息傳遞成功。它的工作原理是：

• 在本地事務執行成功后，系統會嘗試通知其他的參與者或服務。
• 通知操作會盡最大努力去執行，但如果失敗，系統不會無限重試。
• 該方案通常結合人工干預，例如，如果通知失敗，系統可能會記錄日志、發送報警、或者提供管理界面供操作人員手動處理。思考:最大努力通知與可靠消息一致性有什么不同？

解決方案思想不同

可靠消息一致性，發起通知方需要保證將消息發出去，并且將消息發到接收通知方，消息的可靠性關鍵由發起通知方來保證。

• 最大努力通知，發起通知方盡最大的努力將業務處理結果通知為接收通知方，但是可能消息接收不到，此時需要接 收通知方主動調用發起通知方的接口查詢業務處理結果，通知的可靠性關鍵在接收通知方。

兩者的業務應用場景不同

• 可靠消息一致性：關注的是交易過程的事務一致，以異步的方式完成交易。
• 最大努力通知：關注的是交易后的通知事務，即將交易結果可靠的通知出去。

技術解決方向不同

• 可靠消息一致性：要解決消息從發出到接收的一致性，即消息發出并且被接收到。
• 最大努力通知：無法保證消息從發出到接收的一致性，只提供消息接收的可靠性機制。可靠機制是，最大努力的將消息通知給接收方，當消息無法被接收方接收時，由接收方主動查詢消息（業務處理結果）。

8. 分布式鎖

在某些業務場景，使用分布式鎖是確保多個分布式節點不會同時操作同一資源的有效方法。這一機制可以通過使用像Redis、ZooKeeper等分布式協調服務來實現

應用場景： 在電商秒殺活動中，為了防止超賣現象，需要確保同一時間只有一個請求能夠對庫存數量進行修改。這時，可以使用Redis作為分布式鎖的后端存儲，以確保秒殺活動的進行順利和公平。

推薦場景： 當需要協調多個節點對共享資源進行訪問控制時，分布式鎖是一個非常有效的解決方案。例如，在分布式系統中，多個節點需要同時對同一資源進行讀取或更新操作時，為了保證數據的一致性和避免競態條件，可以使用分布式鎖來進行并發控制。