柔性事務的分佈式事務解決方案設計探究

作者 | 京東雲開發者 - 鄭朋輝

原文鏈接：https://my.oschina.net/u/4090830/blog/5585963

1 背景

市面上常見的有，2pc/3pc、tcc、saga 等常見的分佈式事務解決方案，但是實際實施起來框架比較重，設計開發比較繁瑣，不易於快速開發上手。本文提供一種基於柔性事務設計的簡單易上手的分佈式事務設計方案，用於解決常見的分佈式事務常見場景。

2 常見分佈式事務場景

2.1 同步場景

常見的場景，方法內依賴外部微服務多個同步接口，等同步接口返回再展開後續邏輯，如下圖 1 描述。


圖 1 分佈式事務同步場景

存在的問題：B/C 失敗後，A/B 不能回滾，造成數據不一致？

2.2 異步場景

方法內依賴外部微服務多個同步接口同時，本地事務提交併發出異步 MQ，如下圖 2 描述。


圖 2 分佈式事務異步場景

存在的問題：詢價系統無法保證本地事務和 mq 消息的發送同時成功或失敗，會造成數據不一致。

3 解決方案

3.1 數據模型設計

事務表：記錄每次同步方法執行的狀態，包括：1 - 進行中（同步方法執行開始）、2 - 已完成（同步方法執行成功）、3 - 失敗（同步方法執行失敗）、4 - 已回滾（回滾方法執行成功）；

方法調用表：記錄一個完整的事務內所有方法的執行前入參、同步方法接口、回滾接口、回滾入參、方法執行順序，如下圖 3 描述：


圖 3 事務服務數據模型

3.2 設計原理

原理：一個完整事務內，1. 首先每個方法提供回滾接口，其次，事務內每次同步方法執行時，優先維護入參數據到事務表，方便後續做回滾補償；2. 整個事務內某一個方法執行失敗時，結束整個事務，並更新事務表狀態 = 失敗；3. 事務表通過輪詢狀態 status=3 (失敗) 事務，調用回滾接口，利用回滾入參進行接口補償；4. 回滾邏輯：找到事務表中失敗的執行方法的順序值，只調用小於失敗順序值的所有回滾接口、入參，注意並不回滾失敗值的接口，並根據順序倒序進行接口回滾補償。


圖 4 回滾原理圖

3.3 執行時序


圖 5 回滾執行時序圖

3.4 回滾失敗處理方案：

  1. 事務服務的高可用保障：柔性事務前提是保證事務服務高可用性，重點保障；

  2. 回滾服務重試機制：回滾接口失敗重試機制，保證數據一致性；

  3. 爲了避免架構複雜度，做日誌記錄、報警、人工處理。

4 注意問題

  1. 回滾服務的冪等性：回滾做好業務防重和系統防重，防止因爲回滾帶來的業務數據不一致；

  2. 髒數據：整個事務中某一方法執行失敗，前面調用方法的數據作爲髒數據使用。簡單的解決方案：依賴事務表整個事務執行狀態來決定能否使用髒數據。但缺點就是這樣會耦合業務邏輯；

  3. 中心化：整個事務的維護完全依賴事務服務完成，需要保證事務服務的高可用性；

  4. 實時性：事務維護本方案通過定時任務維護，如果業務場景有實時性要求，方式可以改爲：在整個事務中某一方法執行失敗時，catch 異常，catch 內更新任務狀態成功時，直接進行回滾邏輯調用。

5 總結

除了通過常規本地大事務保證事務完整性方案，本次方案提供了一套基於柔性事務回滾補償的方式來保證分佈式事務，通過維護事務服務和事務服務中心對應數據表，從而保障整個分佈式事務的完整性。實現方式簡單、輕量、易於操作，方便地解決了常見分佈式事務場景。

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

猜你喜歡