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

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

1.2PC

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

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

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

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

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

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

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

• 成功情況：

圖片

• 異常情況：

圖片

2PC優(yōu)缺點：

優(yōu)點

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

缺點：

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

2.3PC

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

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

準備階段（CanCommit）：

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

提交準備階段（PreCommit）：

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

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

提交階段（DoCommit/DoAbort）：

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

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

3.TCC

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

• 分支事務成功情況：

圖片

• 分支事務失敗的情況：

圖片

TCC分為三個階段

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

TCC需要注意三種異常處理

空回滾

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

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

解決思路是

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

冪等

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

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

懸掛

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

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

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

TCC優(yōu)缺點：

TCC的優(yōu)點：

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

TCC的缺點

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

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

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

分布式補償事務（Saga） 優(yōu)缺點

優(yōu)點

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

缺點

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

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

5. 可靠消息最終一致性

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

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

圖片

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

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

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

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

begin transaction；
//1.發(fā)送MQ
//2.數(shù)據(jù)庫操作
commit transation;

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

begin transaction；
//1.數(shù)據(jù)庫操作
//2.發(fā)送MQ
commit transation;

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

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

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

3. 消息重復消費的問題

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

6. 本地消息表方案

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

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

圖片

交互流程

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

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

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

• 定時任務掃描日志

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

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

• 消費消息

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

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

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

7.最大努力通知原則

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

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

解決方案思想不同

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

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

兩者的業(yè)務應用場景不同

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

技術解決方向不同

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

8. 分布式鎖

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

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

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