關注我
，回復關鍵字「spring」，來源| OSCHINA 社區
作者 | 京東雲開發者-鄭朋輝
原文鏈接：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 回滾失敗處理方案：
事務服務的高可用保障：柔性事務前提是保證事務服務高可用性，重點保障；
回滾服務重試機制：回滾接口失敗重試機制，保證數據一致性；
為了避免架構複雜度，做日誌記錄、報警、人工處理。
4 注意問題
回滾服務的冪等性：回滾做好業務防重和系統防重，防止因為回滾帶來的業務數據不一致；
髒數據：整個事務中某一方法執行失敗，前面調用方法的數據作為髒數據使用。簡單的解決方案：依賴事務表整個事務執行狀態來決定能否使用髒數據。但缺點就是這樣會耦合業務邏輯；
中心化：整個事務的維護完全依賴事務服務完成，需要保證事務服務的高可用性；
實時性：事務維護本方案通過定時任務維護，如果業務場景有實時性要求，方式可以改為：在整個事務中某一方法執行失敗時，catch 異常，catch 內更新任務狀態成功時，直接進行回滾邏輯調用。
5 總結除了通過常規本地大事務保證事務完整性方案，本次方案提供了一套基於柔性事務回滾補償的方式來保證分布式事務，通過維護事務服務和事務服務中心對應數據表，從而保障整個分布式事務的完整性。實現方式簡單、輕量、易於操作，方便地解決了常見分布式事務場景。
SSO 單點登錄和 OAuth2.0 的區別和理解
關注後端面試那些事，回復【2022面經】
獲取最新大廠Java面經
最後重要提示：高質量的技術交流群，限時免費開放，今年抱團最重要。想進群的，關注SpringForAll社區，回復關鍵詞：加群，拉你進群。
留言列表