一致性框架：供應鏈分布式事務問題解決方案
一、前言
二、一致性理論基礎
1. 一致性模型概述
2. 最終一致性的必要性
三、供應鏈一致性框架總體架構
1. 一致性框架的核心功能
2. 一致性框架整體框架
3. 一致性框架整體流程
四、一致性框架實現原理
1. 核心組件設計
2. 異步執行實現原理
3. 重試機制實現
五、領域模型
六、數據模型
七、一致性框架案例
八、結語
一、前言
在當今微服務架構盛行的時代，分布式系統已經成為企業級應用的標準模式。然而，隨之而來的分布式事務問題也成為了開發人員的一大挑戰。在復雜的供應鏈系統中，
各個業務模塊之間的數據一致性一直是一個重要且棘手的問題。物流、庫存、訂單等系統相互協作，如何在保證業務高效運轉的同時，確保跨系統操作的數據一致性？
今天，我們將深入探討一個專為解決供應鏈分布式事務問題而設計的框架——「一致性框架」。
二、一致性理論基礎
一致性模型概述
在分布式系統中，一致性模型主要分為幾種類型。
一致性模型類型
※ 強一致性
任何時刻，所有節點看到的數據都是一樣的。
※ 弱一致性
不保證所有節點同時看到相同的數據。
※ 最終一致性
在一段時間后，所有節點最終會看到相同的數據。
其中，最終一致性是CAP理論（一致性、可用性、分區容忍性）中的一個重要妥協方案，它在保證系統高可用性的同時，通過異步機制確保數據的最終一致。
圖片
最終一致性的必要性
在微服務架構的系統中，我們常常面臨著跨服務調用中的分布式事務問題、網絡暫時性故障導致的調用失敗、第三方系統響應慢導致的超時問題等。這些問題如果使用強一致性方案解決，往往會導致系統可用性下降、響應時間增加。因此，"先完成本地事務，異步確保遠程調用的最終成功"的最終一致性方案被廣泛采用。
三、供應鏈一致性框架總體架構
一致性框架的核心功能
供應鏈一致性框架包含以下核心功能：
- 聲明式API：簡潔易用的接口供開發者使用
- 操作記錄持久化：記錄操作信息，以便重試
- 自動重試機制：失敗后按策略自動重試
- 并發控制：避免并發重試導致的問題
- 超時與熔斷：防止無效重試消耗資源
- 監控與告警：重試失敗達閾值時進行告警
一致性框架整體框架
圖片
一致性框架整體流程
供應鏈的一致性框架基于Spring Boot生態，這提供了簡單易用的注解式API 。其總體流程如下：
初始化階段
- 應用啟動時，加載一致性框架配置。
- 初始化線程池、策略組件、監聽器等核心組件。
- 注冊定時任務（重試任務、清理任務）。
方法攔截階段
- AOP攔截標注了 @EventualConsistency 注解的方法。
- 解析注解參數（referenceNo、是否異步、重試策略等）。
- 創建一致性操作上下文（ConsistencyContext）。
事務處理階段
- 執行業務方法，記錄執行結果。
- 事務提交后，進行一致性操作的執行。
一致性框架執行階段
- 根據配置決定同步執行或異步執行。
- 保存執行記錄到數據庫。
- 同步執行直接調用目標方法，異步執行提交到線程池。
- 根據執行結果更新記錄狀態（DONE、EXCEPTION、FAILED）。
重試階段
- 從數據庫找出異常狀態的記錄，包含執行方法名、方法參數等。
- 執行器重試方法。
- 根據執行結果更新記錄狀態（DONE、EXCEPTION、FAILED）。
一致性框架整體流程如下 ：
圖片
四、一致性框架實現原理
核心組件設計
我們的一致性框架包含以下核心組件：
注解層
@EventualConsistency 注解是框架的入口，它是一個運行時注解，可以應用于方法和類。其核心屬性如下：
- async() ：控制第一次執行是否為異步執行，默認為 true 。
- maxRetryTimes() ：設置最大重試次數，默認為6次。
- delay() : 配置重試延遲策略，使用嵌套的 @Delay 注解。
- listeners() ：指定監聽器的Bean名稱，用于監聽重試過程。
- beanName() ：指定Bean名稱，用于定位執行目標。
- referenceNo() ：設置業務參考號，用于業務追蹤和冪等性控制。
- serializerListener() ：指定用于序列化和反序列化的監聽器Bean名稱。
攔截層
AnnotationAwareRetryOperationsInterceptor 負責攔截帶有注解 @EventualConsistency 的方法，根據注解配置創建相應的執行策略。
執行層
執行層負責根據當前帶有一致性注解方法的狀態來選擇合適的執行器，執行帶有一致性框架注解的方法。一致性框架會記錄執行方法的狀態，包含初始化、異常、失敗和完成狀態。
根據狀態不同，會選擇不同的執行器：
- SyncConsistencyExecutor ：同步執行器，在當前線程中執行。
- AsyncConsistencyExecutor ：異步執行器，通過異步線程執行，不等待執行結果立即返回成功。
- RetryConsistencyExecutor ：重試執行器，專門對執行狀態為異常的記錄進行重試。
- NestedConsistencyExecutor ：嵌套執行器，專門處理嵌套一致性調用場景，記錄執行信息但不立即執行方法，通過重試機制來執行嵌套任務，解決同一事務中嵌套調用的問題。
持久層
使用數據庫存儲執行記錄，支持記錄的創建、更新和查詢。大消息存儲到MongoDB，避免數據庫性能問題。
異步執行實現原理
異步執行的核心是將操作持久化，然后在事務提交后異步執行。這種設計確保了只有當原事務提交成功后，才會執行異步操作，避免了事務回滾后執行異步操作的問題。
圖片
重試機制實現
重試機制基于以下幾個關鍵點：
- 持久化記錄：記錄每次執行的參數和狀態
- 定時掃描：定期掃描需要重試的記錄
- 分布式鎖：確保在集群環境下只有一個實例執行重試
- 反射調用：通過反射動態調用目標方法
五、領域模型
圖片
六、 數據模型
圖片
七、一致性框架案例
買家在得物App下單后，供應鏈會接收商品發貨單據。商品從倉庫發貨時，倉儲域要將發貨信息通知履約域，并扣減倉儲庫存。代碼如下：
public void ship(String orderCode){
//通知履約域
notifyOfcShip(orderCode);
//庫存扣減
inventorySubtract(orderCode);
}
@EventualConsistency(referenceNo = "#orderCode")
public void notifyOfcShip(String orderCode){
// 發貨調用履約域
}效果：即使履約系統出現異常，庫存也能正常扣減，確保商品發貨成功。一致性框架會重試通知履約域的方法，確保履約域發貨單狀態變更并通知交易域。
八、結語
在分布式系統中，一致性框架是確保系統可靠性的重要工具。通過正確使用一致性框架，我們可以構建既高可用又最終一致的系統，應對各種復雜的分布式場景。希望本文能幫助您更好地理解一致性框架的原理和應用，為您的系統添磚加瓦。
