分佈式事務設計與實踐

1. 異步消息隊列：用於在服務之間傳遞事務信息和狀態，確保各服務可以異步地處理事務操作。

2. 事務協調器：負責協調和管理全局事務的狀態，包括提交和回滾操作。

3. 補償機制：在事務失敗時，通過補償操作來回滾或修復之前的操作，以保證數據的一致性。

設計步驟

1. 事務初始化

• 事務發起者：事務開始時，由事務發起者（例如用戶請求服務）向事務協調器發起一個全局事務。

• 事務 ID：事務協調器生成一個全局唯一的事務 ID，並將其傳遞給所有參與服務。

2. 本地事務執行

• 參與服務：每個參與服務接收到事務 ID 後，執行本地事務操作（例如數據庫操作），但不立即提交。

• 異步消息隊列：參與服務在完成本地操作後，通過異步消息隊列向事務協調器彙報操作結果（成功或失敗）。

3. 事務協調

• 事務協調器：根據所有參與服務的反饋結果，決定是提交還是回滾全局事務。

• 全局提交：如果所有參與服務都成功，則事務協調器向所有服務發送提交指令，所有服務提交本地事務。

• 全局回滾：如果有任何一個服務失敗，則事務協調器向所有服務發送回滾指令，所有服務回滾本地事務。

4. 補償機制

• 補償操作：如果全局事務需要回滾，參與服務需要執行補償操作，以撤銷之前的操作。這通常通過補償接口實現，確保數據回到一致狀態。

• 重試機制：在異步場景下，可能需要多次嘗試補償操作，直到成功爲止。

分佈式事務補償服務

• tstate：事務狀態管理模塊，負責記錄和維護事務的狀態信息，確保事務的執行狀態可以被追蹤和管理。

• tschedule：事務調度模塊，負責調度和執行事務補償操作，確保補償操作按計劃進行。

• deserialize：反序列化模塊，負責將事務相關的數據從存儲中讀取並轉換爲可操作的對象。

• rpc client：RPC（遠程過程調用）客戶端模塊，負責與其他微服務進行通信，執行遠程調用以進行事務補償操作。

微服務網關層

• 微服務網關層：用於處理所有進入微服務的請求，執行統一的路由、認證和流量控制。

微服務業務邏輯層

• 微服務業務邏輯層：包含業務邏輯處理的主要部分，負責執行核心的業務操作。

• proxy（代理）：代理模塊，用於攔截和處理數據訪問請求，確保請求可以被正確路由到對應的補償接口或原子接口。

微服務數據訪問層

• 微服務數據訪問層：負責與數據庫進行交互，執行數據的讀寫操作。

• 原子接口：直接與數據庫進行交互的接口，執行基本的數據操作。

• 補償接口：用於事務補償操作的接口，負責在事務失敗時進行數據的回滾或補償。

數據庫

• TDB：事務數據庫，專門用於存儲和管理事務相關的數據和狀態信息。

• DB1 和 DB2：業務數據庫，存儲業務數據。在分佈式事務中，這些數據庫可能位於不同的物理位置或節點上。

數據流向

• TDB 與分佈式事務補償服務的交互：tstate 模塊從 TDB 獲取事務狀態，tschedule 模塊根據事務狀態調度補償操作，rpc client 通過遠程調用執行補償操作。

• 微服務業務邏輯層與數據訪問層的交互：業務邏輯層通過代理模塊訪問數據，代理模塊根據需求選擇調用原子接口或補償接口。

• DB1 和 DB2 與數據訪問層的交互：原子接口直接與 DB1 和 DB2 進行數據讀寫操作，補償接口則在需要進行事務補償時進行操作。

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