探索分布式事務(wù)解決方案：八種方案解析

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

1.2PC

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

• 1.準(zhǔn)備階段（Prepare phase）
• 2.提交階段（commitphase）

2是指兩個階段，P是指準(zhǔn)備階段，C是指提交階段

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

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

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

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

• 成功情況：

圖片

• 異常情況：

圖片

2PC優(yōu)缺點：

優(yōu)點

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

缺點：

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

2.3PC

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

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

準(zhǔn)備階段（CanCommit）：

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

提交準(zhǔn)備階段（PreCommit）：

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

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

提交階段（DoCommit/DoAbort）：

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

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

3.TCC

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

• 分支事務(wù)成功情況：

圖片

• 分支事務(wù)失敗的情況：

圖片

TCC分為三個階段

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

TCC需要注意三種異常處理

空回滾

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

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

解決思路是

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

冪等

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

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

懸掛

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

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

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

TCC優(yōu)缺點：

TCC的優(yōu)點：

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

TCC的缺點

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

4. 分布式補償事務(wù)（Saga）

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

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

優(yōu)點

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

缺點

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

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

5. 可靠消息最終一致性

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

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

圖片

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

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

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

本地事務(wù)與消息發(fā)送的原子性問題即：事務(wù)發(fā)起方在本地事務(wù)執(zhí)行成功后消息必須發(fā)出去，否則就丟棄消息。即實現(xiàn)本地事務(wù)和消息發(fā)送的原子性，要么都成功，要么都失敗。本地事務(wù)與消息發(fā)送的原子性問題是實現(xiàn)可靠消息最終一致性方案的關(guā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消息失敗，就會拋出異常，導(dǎo)致數(shù)據(jù)庫事務(wù)回滾。但如果是超時異常，數(shù)據(jù)庫回滾，但MQ其實已經(jīng)正常發(fā)送了，同樣會導(dǎo)致不一致。

2. 事務(wù)參與方接收消息的可靠性

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

3. 消息重復(fù)消費的問題

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

6. 本地消息表方案

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

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

圖片

交互流程

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

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

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

• 定時任務(wù)掃描日志

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

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

• 消費消息

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

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

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

7.最大努力通知原則

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

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

解決方案思想不同

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

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

兩者的業(yè)務(wù)應(yīng)用場景不同

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

技術(shù)解決方向不同

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

8. 分布式鎖

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

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

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