分佈式事務的解決方案—Seata TCC 模式

    在分佈式事務解決方案中有 Seata AT 模式，但是 AT 模式要求是關係型數據庫（因爲 undolog 表需要和業務保持原子性），此時如果事務中存在非關係型數據庫（如 Redis、ES 等），那麼 AT 模式就無法滿足要求了，如下圖所示：

    此時我們就需要 Seata TCC 模式來幫助我們解決這種場景下的分佈式事務問題。

1、認識 Seata TCC 模式

    TCC(Try-Confirm-Cancel) 模式是一種補償性事務模式的解決方案，因爲補償的業務需要使用者自己寫，不像 AT 模式那樣的無侵入性的分佈式事務處理方案，如下是 TCC 模式的執行流程圖：

    TCC 將一個完整的業務操作分爲三個階段，如下圖整理所示：

    Try 階段：嘗試執行業務操作，預留必要的業務資源，並檢查數據的有效性。

    Confirm 階段：如果 Try 階段所有參與的操作都成功，則進入 Confirm 階段就會正式完成業務操作，提交事務，並釋放在 Try 階段預留的資源。

    Cancel 階段：如果 Try 階段有任何一個操作失敗，或者由於某種原因需要回滾事務，則觸發 Cancel 階段，撤銷所有已執行的 Try 操作，回滾到事務開始之前的狀態，並釋放預留的資源。

2、理解 TCC 模式

    爲了方便理解 TCC 模式，以 A（賬戶總額 1000 元）向 B（賬戶總額 2000 元）轉賬 100 元爲例進行解析，那麼 TCC 模式下的操作流程如下圖所示：

    Try 階段的工作：A 賬戶先從總資金中扣除 100 元，但是這個 100 處於凍結狀態；B 賬戶預增加 100 元，這個 100 處於不可用狀態。如下圖所示：

（a）如果 A 與 B 在 Try 階段都正常的執行，接下來就是執行 Confirm 階段的任務，A 賬戶凍結 100 變成 0 元，這個 100 真正的轉給 B 賬戶；B 賬戶的總額增加 100 元，預增加的金額變成 0 元，如下圖所示：

（b）如果 A 與 B 在 Try 階段未正常的執行，接下來 A 賬戶的凍結 100 變成 0 元，恢復 A 賬戶的資金的總額；B 賬戶資金的總額不變化，預增加的金額變成 0 元，如下圖所示：

3、Seata TCC 事務模型的三種異常

    在 TCC 事務模型涉及到的三種異常（空回滾、冪等性、防懸掛）是不可避免的，下面我們來了解這三種異常發生的原因以及處理方案。

（1）空回滾

    A 調用 C 的時候，由於網絡抖動的原因導致 C 沒有請求成功，此時服務超時走兜底機制返回異常給 A，如下圖所示：

    當 A 發現 B 服務異常，TC 就會通知 A、B、C 執行回滾操作，但是 C 由於 Try 階段都沒有執行就直接執行 Cancel 階段，最終就可能導致業務數據的不一致性。

空回滾處理方案：

    Cancel 執行的前提是一定要執行過 Try 階段，所以增加一個日誌表來記錄是否執行 Try 階段，如果沒有執行 Try 階段，那麼 Cancel 階段也不執行。

（2）冪等性

    TCC 中二階段的方法被多次的調用（二階段會有定時器不斷的重試），如下如所示：

冪等性處理方案：狀態機方式

    在日誌表中執行更新操作的時候（update log set status= 2 where status= 1）通過獲取影響行數來判斷是否執行成功，如果影響行數爲 0 就不繼續處理；如果影響行數不爲 0 就繼續 Cancel 的業務邏輯。

（3）防懸掛

    由於網絡擁堵等原因導致 A 調用 C 的 Try 方法的請求發送成功，但是 C 與 A 之間自動斷開了連接，導致 A 認爲 C 執行異常了，此時 TC 發送執行回滾操作命令，這就導致 Cancel 階段比 Try 先執行，如下圖所示：

    當 C 服務做完 Try 階段的工作後，此時資源被預留出來了；但是 Cancel 已經執行完成了，表示那麼整個事務就結束了，進而導致業務數據的不一致性。

防懸掛問題的處理方案：日誌表

    在 Cancel 執行完成之後要保證 Try 方法不能再執行了，此時在日誌表中增加一條 Cancel 的記錄，等到 Try 執行的時候，其也要增加一條記錄，但是由於 Cancel 增加了日誌記錄，此時 Try 就增加失敗，進而阻止 Try 繼續執行。

總結：

（1）TCC 模式資源鎖定時間短：相較於傳統的兩階段提交 (2PC)，TCC 模式可以減少資源鎖定的時間，因爲資源僅在 Try 階段被預留，並在 Confirm 或 Cancel 階段迅速釋放。

（2）TCC 模式業務邏輯靈活：我們可以根據業務需求自定義每個階段的邏輯，使得 TCC 模式非常靈活。

（3）TCC 模式保證強一致性：它可以確保事務要麼都成功，要麼都回滾。

（4）TCC 模式實現複雜（需要爲每個業務操作明確定義 Try、Confirm 和 Cancel 三個階段的邏輯）、增加了協調開銷、業務侵入性（業務邏輯與事務邏輯耦合）。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/voZX95_EoFADkFZjNSE0lg