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