（一）支付架構流程

1、網關層

2、 支付處理層

支付處理層是支付中臺的核心，負責處理支付請求并與各大支付平臺、銀行等外部系統進行交互。其功能包括：

支付信息校驗：驗證支付請求的合法性，如訂單號、金額、商戶信息等。

支付請求發起：根據用戶的支付方式，調用不同的支付平臺API，發起支付請求。

支付狀態查詢：定期或根據需要查詢支付狀態，確保支付完成。

退款與撤單：支持支付的退款操作或撤銷未完成的交易。

3、支付服務層

• 多支付渠道集成：如銀行卡支付、第三方支付（支付寶、微信支付、PayPal等）、錢包支付、跨境支付等。
• 支付業務邏輯：管理支付流程的業務邏輯，處理支付成功或失敗的回調，確保數據的一致性。
• 支付風險控制：通過風險識別和防范系統（如風控引擎、反欺詐機制等）對支付請求進行實時監控，防止欺詐。

4、支付清算層 (Settlement Layer)

支付清算層主要負責交易的結算和資金的轉移，確保支付款項最終準確到達商戶或用戶賬戶。包括：

• 資金清算：將支付結果與商戶賬戶進行匹配，并進行資金的清算和結算。
• 多幣種和跨境支付：支持不同幣種的清算，處理跨境支付的匯率轉換和結算。
• 賬務管理：管理交易的賬務流水，生成財務報表，確保資金流的合規性和透明性。

5、支付安全層

支付安全層負責保障支付過程中的安全性，避免用戶信息泄露或資金被盜取。主要包括：

• 加密與簽名：使用SSL/TLS加密技術和數字簽名對支付數據進行加密，防止數據泄露。
• 認證與授權：通過多因素認證（如動態驗證碼、指紋識別等）和權限控制，確保只有授權的用戶和系統才能進行支付操作。
• 反欺詐系統：通過實時監控、交易行為分析、風控規則等手段，防止欺詐行為。

6、日志與監控層 (Logging and Monitoring Layer)

• 交易日志：記錄每一筆交易的詳細信息，包括支付請求、響應、成功與失敗的原因等。
• 實時監控：通過監控系統實時檢查支付系統的運行狀態，及時發現潛在問題。
• 告警與分析：當發生異常或錯誤時，自動觸發告警，并通過數據分析進行問題排查。

7、數據分析層

• 支付數據分析：通過對交易數據進行分析，幫助商戶了解支付渠道、支付方式的使用情況，進行優化。
• 用戶行為分析：分析用戶的支付習慣和偏好，為市場營銷、產品優化等提供數據支持。
• 風控分析：通過分析支付行為，識別潛在的風險點，為風控模型提供數據支持。

8、 外部接口與API層

• 商戶接口：為商戶提供方便的API接口，方便他們接入支付系統、獲取支付狀態、發起退款等操作。
• 第三方支付接入：通過開放API與各類第三方支付服務提供商（如支付寶、微信支付等）進行對接。

（二）下面是可能被問到的問題和回答：

這個中臺的支付服務請求響應是同步還是異步的？或者是混合模式？

微信小程序支付支付一般采用同步與異步結合的方式。

同步階段

• 在用戶發起支付請求時，小程序調用微信支付API（wx.requestPayment）。
• 微信支付服務會立即返回支付發起結果 success或fail），這些結果反映了支付請求的執行狀態：

同步成功（支付請求發起成功）：表示支付流程已經啟動，但支付的最終狀態（成功或失?。┬枰ㄟ^后續異步確認。

同步失敗：如用戶取消支付或請求參數錯誤，立即返回錯誤信息，用戶無需等待。

異步階段

• 支付的最終結果（成功或失?。┩ㄟ^異步通知 方式發送給商戶。
• 商戶系統需要實現支付結果的回調接口，接收微信支付服務器推送的支付結果通知。
• 商戶可以通過查詢訂單接口（orderQuery）主動確認支付結果。

同步模式適用場景

• 支付請求從發起到返回結果在一次通信中完成，用戶實時獲得支付狀態。
• 適合對即時反饋有高需求的場景。

1）線下支付

• 如掃碼支付、NFC支付、刷臉支付。
• 用戶支付后需要立刻獲得結果，確保交易完成。
• 例：便利店、超市等場景。

2）小額支付

• 如公共交通、共享單車。
• 交易金額低、支付流程簡單，實時性是關鍵。

3）無需復雜處理的場景 ：

• 如虛擬物品購買（如游戲內道具、在線充值），支付后直接發貨。

異步模式

1）電商大促與高并發場景 ：

2）跨境支付

3）大額支付

• 如機票、酒店預訂、企業間交易。
• 涉及銀行間復雜驗證和審批流程，需要異步完成支付確認。

4）分期支付 ：

• 如消費貸款、按揭付款。
• 支付狀態受審批和驗證影響，最終狀態需要異步確認。

支付中臺的核心功能模塊？

一、支付請求處理模塊

1、解析支付信息， 如支付金額、支付平臺、支付方式、訂單編號等。

2、根據支付平臺類型，利用工廠模式創建相應的支付處理器，然后調用支付處理器的支付方法發起支付請求，并進行錯誤處理。

二、支付結果回調處理模塊

1、接收回調并驗證合法性

2、根據回調結果變更訂單的支付狀態

三、訂單管理模塊？

1、負責訂單的創建、查詢、更新和刪除等操作，并將訂單信息存儲到數據庫中。

2、提供訂單狀態查詢接口，負責查詢訂單狀態，在支付結果回調處理時更新訂單狀態。

四、配置管理模塊

1、存放各個平臺的配置信息（ API 密鑰、回調地址、支付參數）

2、提供配置的讀取和更新功能

好書推薦

下面這本書對你會很有幫助的，私信我，享受折上折優惠：

支付對接？

針對微信小程序支付場景

1.商戶申請并設置微信支付

• 商戶需要先注冊微信商戶號，并開通微信支付功能。注冊時需要提供企業的營業執照、法人身份證、銀行賬戶等信息。
• 登錄微信支付商戶平臺（pay.weixin.qq.com），獲取商戶號 和API密鑰 。
• 配置微信小程序的支付相關信息，如在小程序后臺配置支付參數，包括商戶號和API密鑰等。

2.用戶發起支付請求

• 用戶在小程序中選擇商品并提交訂單，點擊“支付”按鈕時，前端會調用小程序支付接口來發起支付請求。
• 小程序調用wx.requestPayment 接口向后端發起支付請求，后端會向微信支付服務器請求訂單信息。

3.后端生成預支付訂單

• 后端通過商戶號、API密鑰以及微信支付相關的支付參數，調用微信支付的統一下單接口（**/pay/unifiedorder** ）來生成預支付訂單。
• 統一下單請求需要提供以下主要參數：

appid：小程序的 AppID。

mch_id：商戶號。

nonce_str：隨機字符串。

sign：簽名（根據請求的參數生成簽名）。

body：商品描述。

out_trade_no：商戶訂單號。

total_fee：訂單總金額（單位為分）。

spbill_create_ip：用戶的客戶端 IP 地址。

notify_url：支付結果回調 URL。

trade_type：支付類型（JSAPI表示小程序支付）。

4.前端調用 wx.requestPayment 接口

• 后端返回的預支付信息（包括prepay_id）將傳遞給小程序前端。
• 前端通過wx.requestPayment 接口調用支付，傳入預支付信息（如timeStamp、nonceStr、package、signType、paySign）。
• 前端調用成功后，用戶的微信支付界面將彈出，用戶可以確認支付。

5.支付結果回調

• 支付成功后，微信支付服務器會向商戶的notify_url 發送支付結果通知。
• 后端接收到支付通知后，驗證簽名并處理支付結果。如果支付成功，可以進行發貨等后續操作。

6.支付結果查詢

• 商戶可以根據需要通過微信支付的訂單查詢接口（**/pay/orderquery** ）查詢訂單支付狀態，確認支付是否成功。

注意事項

1.簽名驗證

• 微信支付的所有請求和返回數據都需要進行簽名驗證。商戶需確保簽名算法的正確性，避免支付過程中的數據篡改。
• 需要使用商戶號的 API 密鑰來生成簽名，簽名時要確保參數的順序和編碼方式正確。

2.訂單號管理

• 商戶必須確保每筆訂單的訂單號唯一。商戶訂單號（out_trade_no）在微信支付系統中是唯一的，且不能重復。
• 訂單號應由商戶自行生成，建議使用時間戳和隨機數等組合來確保唯一性。

3.金額精度

• 微信支付的金額單位為“分”，即傳遞金額時需要將人民幣的元轉換為分。
• 例如，用戶支付金額為10元，傳遞的參數應該是1000（10 × 100）。

4.API調用頻率限制

• 微信支付的API調用有頻率限制，商戶在短時間內不能頻繁調用某些接口，如統一下單接口、訂單查詢接口等。商戶需要合理規劃接口調用頻率，避免被微信支付平臺限制。

5.支付成功回調處理

• 商戶在接收到支付回調時，需要驗證支付通知的簽名，確保通知來自微信支付服務器。
• 如果支付成功，可以執行后續操作，如發貨、提供服務等；如果支付失敗，可以進行相應的錯誤處理。

6.異常支付場景

• 在支付過程中，可能會遇到網絡不穩定、支付中斷等異常情況，商戶需要準備好處理策略，確保用戶支付體驗順暢。例如，提供支付結果查詢功能或異常訂單處理機制。

7.支付成功后的用戶體驗

• 小程序內的支付界面應簡潔清晰，用戶確認支付時無需過多操作，避免出現操作復雜導致支付失敗的情況。
• 小程序應該提示用戶支付成功或失敗，并給出后續操作的指引。

8.退款流程

• 如果需要為用戶退款，商戶可以調用微信支付的退款接口（**/secapi/pay/refund** ）進行退款。
• 退款請求中需要提供原交易的transaction_id 或out_trade_no，以及退款金額等信息。

1）發起支付請求時，確保每個支付請求都有一個唯一的標識符，比如order_id 或者一個專門生成的transaction_id，用于標識每次支付請求的唯一性。

2）使用支付請求冪等性接口 ：微信支付本身提供了一些接口支持冪等性。例如，當你發起統一下單請求時，可以為每個支付請求生成一個唯一的商戶訂單號（out_trade_no）。如果該訂單號的支付請求已經存在，微信支付會返回錯誤提示，商戶可以根據此返回值判斷是否重復請求。

3）支付請求記錄與狀態判斷 ：

在服務端，針對每個支付請求（以order_id 或transaction_id 為標識）應該保存支付的狀態（例如：待支付、已支付、支付失敗、支付處理中等）。在接收到相同的支付請求時，可以根據已保存的狀態來判斷是否需要重新處理，或者直接返回已經完成的支付狀態

• 請求處理步驟：支付請求發起 -> 保存訂單狀態 -> 請求微信支付接口 -> 等待支付結果回調
• 支付回調處理：接收到支付回調 -> 查詢數據庫支付狀態 -> 如果該訂單已經完成支付，返回成功；如果是第一次回調，處理支付成功邏輯。

微信小程序支付場景中我需要手動做冪等性保障和事務處理嗎?

冪等性問題的背景

• 在支付過程中，尤其是通過網絡請求和異步操作時，可能會發生網絡不穩定或者系統重試等問題，導致同一個支付請求被多次提交，或者同一個支付結果被多次處理。
• 微信支付的通知接口（如支付結果回調）也可能會因為網絡原因被多次觸發，商戶需要確保每個支付通知只被處理一次，避免重復操作（例如：重復發貨、重復扣款等）。

如何實現冪等性

• 訂單號唯一性：商戶的訂單號out_trade_no 應該具有唯一性，且在商戶系統中不可重復。每筆訂單必須有獨特的標識，確保系統能夠識別和區分不同的交易請求。
• 支付結果的冪等處理：

支付通知處理：微信支付的支付結果回調接口會向商戶的notify_url 發送支付通知，商戶需要對每個支付通知的處理進行冪等性保障。一個常見做法是，商戶可以記錄支付通知的out_trade_no 或transaction_id，在處理支付通知時，先判斷是否已經處理過該通知。如果處理過，直接跳過。

數據庫冗余檢查：在處理支付回調時，商戶應首先檢查訂單的支付狀態。如果訂單已經支付成功，應該跳過后續的處理。如果未支付成功，則繼續執行支付成功后的操作。

• 冪等性關鍵點：

在訂單創建、支付成功、退款等重要操作中，都需要保證操作的冪等性。即每個操作都只能執行一次，防止重復處理。

通過數據庫中唯一的標識（如訂單號、支付交易號）進行冗余檢查，確保同一支付狀態的操作只會執行一次。

這個中臺支付服務的網絡安全是如何保障的？

網絡安全防護技術

• 防火墻：通過設置訪問規則，阻止未經授權的網絡訪問，防止外部網絡的惡意攻擊和非法入侵，只允許合法的網絡流量進入中臺支付服務系統 。
• 入侵檢測與防御系統：實時監測網絡中的異?；顒雍蜐撛谕{，如惡意軟件入侵、黑客攻擊等，并及時發出警報和采取相應的防御措施，如阻斷攻擊源、隔離受感染的設備等，以保護支付系統的安全.
• VPN（虛擬專用網絡）：為遠程訪問中臺支付服務的用戶或分支機構提供安全的加密通道，確保數據在傳輸過程中的保密性和完整性，防止數據被竊取或篡改 。

數據加密技術

• 傳輸加密：采用SSL/TLS等加密協議，對支付數據在網絡傳輸過程中的進行加密處理，使數據以密文形式傳輸，即使被攔截也難以破解，確保用戶的支付信息、賬戶信息等敏感數據的安全 。
• 存儲加密：對存儲在數據庫中的支付數據進行加密，使用對稱加密算法或非對稱加密算法，將數據轉換為密文形式存儲，只有通過授權的密鑰才能解密和訪問數據，防止數據在存儲環節被竊取或泄露.

身份認證與訪問控制

• 多因素身份認證：采用多種身份驗證方式相結合，如密碼、動態口令、指紋識別、面部識別等，增加用戶身份認證的安全性，防止賬戶被盜用和非法登錄.
• 訪問控制列表（ACL）：根據用戶的角色和權限，設置詳細的訪問控制策略，限制不同用戶對中臺支付服務系統資源的訪問權限，確保只有授權用戶能夠訪問和操作相應的功能和數據，防止越權訪問和數據泄露.
• 單點登錄（SSO）：通過單點登錄系統，用戶只需在一個系統中登錄一次，即可訪問其他相互信任的關聯系統，減少用戶在不同系統中重復輸入用戶名和密碼的次數，同時也便于集中管理用戶身份和權限，提高安全性和用戶體驗。

安全審計與監控

• 日志審計：記錄中臺支付服務系統中的所有操作和事件，包括用戶登錄、交易記錄、系統配置變更等，通過對日志的分析和審計，及時發現異常行為和安全漏洞，為安全事件的追溯和調查提供依據 。
• 實時監控：實時監測支付系統的運行狀態、網絡流量、交易數據等，通過設定閾值和告警規則，及時發現系統中的異常交易、流量異常、性能問題等，并及時采取相應的措施進行處理，確保支付系統的穩定運行和數據安全 。
• 風險評估與預警：定期對中臺支付服務系統進行風險評估，識別潛在的安全風險和威脅，并根據評估結果制定相應的風險應對策略。同時，建立風險預警機制，及時發布安全風險預警信息，提醒相關人員采取防范措施，降低安全風險.

安全管理制度與培訓

• 安全策略與制度：制定完善的網絡安全策略和管理制度，明確規定支付服務的安全要求、操作流程、人員職責等，規范員工的行為和操作，確保各項安全措施得到有效執行 。
• 人員培訓與教育：加強對員工的網絡安全培訓和教育，提高員工的安全意識和防范技能，使其了解常見的網絡安全威脅和防范方法，避免因員工的疏忽或不當操作導致安全事故的發生.
• 應急響應與恢復計劃：制定應急預案和災難恢復計劃，明確在發生安全事件時的應急響應流程和責任分工，確保能夠快速、有效地應對安全事件，最大限度地減少損失，并在事件處理后能夠及時恢復系統的正常運行.

支付服務的服務容錯是怎么做的？

事務處理機制

• 原子性保證：采用事務處理機制來確保支付操作的原子性，即一系列相關的支付操作要么全部成功，要么全部失敗，避免因為中斷或失敗導致支付數據不一致的情況。如在數據庫操作中，使用事務來包裹支付相關的插入、更新等操作，若其中任何一個操作失敗，則整個事務回滾，保證數據的一致性.
• 一致性維護：通過嚴格的事務控制和數據校驗，確保支付系統在各種情況下的數據一致性。例如，在處理支付訂單時，不僅要更新訂單狀態，還要同步更新相關的賬戶余額、庫存等信息，所有這些操作都在一個事務中完成，防止出現數據不一致的問題 。

冪等設計

• 唯一鍵校驗：通過唯一鍵實現冪等性，防止重復支付或重復退款等問題。如訂單側常見的以訂單號關聯paymentno做重復支付校驗；支付側交易單以外部單號+商戶號為唯一鍵，支付單以交易單號+操作碼作為唯一鍵.
• 可重入處理：對于已經成功處理的請求，再次接收到相同請求時能夠正確識別并直接返回成功結果，而不會重復執行相同的業務邏輯，避免因重試等操作導致的數據重復或狀態異常.

重試機制

• 異步重試：當支付請求因網絡抖動、服務暫時不可用等原因失敗時，將請求放入消息隊列（MQ）異步重試，并且重試間隔逐次拉長，以避免對故障服務造成過大壓力。例如，第一次重試間隔1分鐘，第二次間隔3分鐘，第三次間隔5分鐘等，直到達到最大重試次數.
• 最大努力通知：采用最大努力通知策略，確保支付結果能夠最終準確地通知到相關方。如支付成功后，若通知下游系統失敗，會進行多次重試通知，直到下游系統成功接收通知或達到最大重試次數為止.

超時設置

• 接口超時：為所有的支付接口調用設置合理的超時時間，防止請求陷入長期等待，導致整個服務不可用。一旦接口調用超過設定的超時時間，即認為此次調用失敗，并根據相應的容錯策略進行處理，如重試或快速失敗等.
• 全局超時控制：在整個支付業務流程中，設置全局的超時時間，以確保支付操作能夠在合理的時間內完成。若超過全局超時時間，系統會自動進行相應的處理，如取消支付、回滾相關操作等，避免因某個環節的長時間阻塞影響用戶體驗和系統性能 。

限流與過載保護

• 流量限制：通過限制單位時間段內的調用量或系統的并發調用程度，來防止系統在流量高峰期被高流量擊垮。常見的限流方式包括固定窗口限流、滑動窗口限流、漏桶算法限流、令牌桶算法限流等，確保系統能夠在承受范圍內處理支付請求，保障系統的穩定性和可用性.
• 熔斷器模式：采用熔斷器模式來防止應用程序不斷地嘗試執行可能會失敗的操作。當服務出現故障或調用失敗率達到一定閾值時，熔斷器會自動打開，暫時切斷對該服務的調用，避免因持續請求故障服務導致資源耗盡和系統雪崩。同時，熔斷器會定期檢查服務是否恢復正常，若恢復則自動關閉，允許再次調用.

艙壁隔離

• 資源隔離：像艙壁一樣對資源或失敗單元進行隔離，確保一個部分出現問題不會影響到其他部分。例如，在多線程或多進程環境中，為不同的支付業務功能分配獨立的線程池或進程，當某個功能出現故障或性能問題時，不會影響到其他正常的業務功能，從而提高系統的整體穩定性和可用性.
• 數據隔離：對不同的支付數據進行分類和隔離存儲，防止因數據之間的相互影響導致故障擴散。如將交易數據、賬戶數據、日志數據等分別存儲在不同的數據庫或數據表中，并采用適當的訪問控制和數據隔離機制，確保數據的安全性和獨立性 。

優雅降級

• 功能降級：當支付系統出現問題，如并發量突然增大系統扛不住時，優先保證核心支付功能的正常運行，對一些非核心功能進行降級處理。如關閉支付查詢相關入口，減少系統的負載壓力，確保支付下單主流程不受影響.
• 數據降級：在系統資源緊張或出現故障時，對支付數據的處理進行適當的降級，以保證系統的基本可用性。例如，暫時降低數據的一致性要求，采用異步方式更新數據，或者返回部分數據而不是完整的數據，待系統恢復正常后再進行數據的同步和補齊 。

數據備份與恢復

• 定期備份：定期對支付數據進行全量備份和增量備份，確保數據的安全性和可恢復性。備份數據可以存儲在本地或異地的存儲設備中，以防止因自然災害、硬件故障等原因導致數據丟失.
• 災難恢復機制：建立完善的災難恢復機制，當發生重大故障或災難導致系統數據丟失或損壞時，能夠快速地從備份數據中恢復系統的運行。災難恢復計劃應包括數據恢復流程、系統重建步驟、應急響應措施等，確保在最短的時間內恢復支付服務的正常運行.

支付服務是否設計到是分布式事務，如果涉及到是怎么處理的？

支付服務通常會涉及到分布式事務，這是因為支付業務流程往往涉及多個不同的系統或服務，例如支付網關、銀行系統、賬戶系統、訂單系統等，這些系統之間需要保證數據的一致性和操作的完整性。以下是一些常見的處理分布式事務的方法：

基于兩階段提交（2PC）協議

• 準備階段：事務協調者向所有參與者（各個相關系統）發送事務內容，詢問是否可以提交事務。參與者執行本地事務操作，但不提交，然后向協調者反饋操作結果（同意或拒絕）。例如，在支付服務中，支付網關完成支付請求處理，賬戶系統完成資金扣除操作準備，訂單系統完成訂單狀態更新準備，它們都將準備好的結果反饋給協調者。
• 提交階段：如果協調者收到所有參與者的同意反饋，就會向所有參與者發送提交事務的指令，參與者正式提交本地事務；如果有任何一個參與者反饋拒絕，協調者就會向所有參與者發送回滾事務的指令。這樣可以保證要么所有系統都成功完成操作，要么全部回滾，維護了事務的原子性。不過，2PC協議存在同步阻塞（參與者在等待協調者指令時處于阻塞狀態）、單點故障（協調者故障可能導致事務阻塞）等問題。

基于補償機制

• 正向操作：各個系統先執行自己的本地事務，不依賴其他系統的事務結果進行操作。例如，支付服務先進行支付處理，扣除用戶賬戶資金；訂單系統同時更新訂單狀態為“已支付”。
• 補償事務設計：如果后續發現某個操作出現問題，例如支付成功但訂單系統更新失敗，就會執行補償事務。對于上述例子，補償事務可能是將扣除的資金退回到用戶賬戶，同時更新訂單狀態為“支付失敗”。補償機制比較靈活，不會像2PC那樣導致長時間的阻塞，但要求開發人員精心設計補償事務，確保能夠正確地撤銷已經執行的操作。

基于消息隊列（MQ）的最終一致性

• 消息生產與發送：當支付操作觸發時，將相關的事件消息發送到消息隊列。例如，支付成功后，發送一個“支付成功”的消息到MQ。這些消息包含了足夠的信息，供下游系統進行后續處理。
• 消息消費與本地事務處理：下游系統（如訂單系統、積分系統等）從消息隊列中獲取消息，然后在本地執行相應的事務處理。以訂單系統為例，收到“支付成功”消息后，更新訂單狀態為“已支付”。如果消息消費過程中本地事務失敗，消息隊列可以保證消息不會丟失，會在一定條件下重新發送消息給消費者，直到消費成功，從而實現最終一致性。這種方法具有很好的異步性和松耦合性，但可能會存在消息延遲等情況導致數據一致性延遲實現。

分布式事務框架的應用

• DTM框架（Go語言實現）：DTM是一款專為分布式事務處理設計的開源框架，在Go語言生態中有著廣泛應用，為處理復雜的分布式事務場景提供了有效的解決方案。
• TCC模式實現：

Try階段：在支付場景下，參與者會執行一些準備操作。比如，支付服務可能會先嘗試凍結用戶賬戶中的相應資金，確保這筆資金在后續交易流程中處于暫不可用狀態；同時，訂單系統可能會預占庫存，標記出即將銷售出去的商品數量，使其不能再被其他訂單占用。這些操作都是在Try階段完成的初步業務邏輯處理，并且它們的執行結果會被記錄下來，以便后續階段進行判斷和處理。

Confirm階段：當所有參與分布式事務的各個部分在Try階段都成功完成了各自的準備操作后，就進入Confirm階段。此時，支付服務會正式扣除之前凍結的資金，完成資金的實際轉移；訂單系統則會確認庫存的減少，將預占的庫存數量從可用庫存中真正減掉，完成商品銷售環節在庫存方面的處理。整個過程確保了所有相關業務操作按照預期有序推進，實現了分布式事務的提交操作。

Cancel階段：倘若在Try階段或者后續的Confirm階段出現了任何問題，比如支付過程中遇到網絡故障導致資金凍結操作未能成功確認，或者訂單系統在預占庫存后發現商品實際庫存不足無法完成銷售等情況，就會觸發Cancel階段。在這個階段，支付服務會解凍之前嘗試凍結但未成功確認扣除的資金，使其恢復到可用狀態；訂單系統也會釋放預占的庫存，讓這些商品重新回到可銷售的庫存池中。通過這樣的取消操作，能夠將業務狀態回滾到分布式事務發起之前的狀態，保證了系統的一致性和穩定性。

• SAGA模式實現：

正向事務鏈編排：在支付業務流程中，可能會涉及多個服務的協同操作，形成一個事務鏈。例如，首先是支付網關接收支付請求并進行初步驗證，然后將請求轉發給支付服務進行資金處理，接著訂單系統根據支付結果更新訂單狀態，最后可能還涉及到積分系統根據支付情況給用戶添加相應積分等操作。這些步驟按照先后順序構成了一個正向的事務鏈，每個步驟都作為一個事務步驟在SAGA模式下進行處理。

補償事務設計：當在這個事務鏈的某個環節出現問題時，就需要進行補償操作。比如，如果支付服務在處理資金時出現故障導致支付失敗，那么就需要設計相應的補償事務。對于前面提到的事務鏈，可能的補償事務包括：支付網關取消對支付請求的初步驗證結果記錄（如果有相關記錄需要清理）；支付服務將可能已經扣除的部分資金（如果在故障前已經有部分資金操作）進行回退處理；訂單系統將已經更新的訂單狀態回滾到支付前的狀態；積分系統撤銷可能已經添加的積分（如果已經添加了積分）。通過這樣一系列的補償事務設計，能夠在出現問題時有效地將業務狀態回滾到合適的狀態，確保系統整體的一致性。

• XA模式實現：

事務管理器協調：在支付場景應用XA模式時，會有一個事務管理器來負責協調各個參與分布式事務的資源管理器（如數據庫、消息隊列等）。事務管理器會向各個資源管理器發送準備事務的指令，類似于其他分布式事務模式中的準備階段操作。

提交與回滾操作：當所有資源管理器都反饋準備好可以提交事務時，事務管理器會下達提交事務的指令，此時各個資源管理器會正式執行提交操作，完成各自業務數據的更新等操作，就像在其他模式下完成分布式事務的最終提交一樣。然而，如果在準備階段或者其他環節有任何一個資源管理器反饋無法進行提交或者出現故障，事務管理器就會下達回滾事務的指令，使得各個資源管理器將業務數據回滾到事務發起之前的狀態，保證了整個分布式事務的原子性和一致性。

DTM框架通過這些不同的分布式事務模式及其具體實現方式，能夠很好地處理支付服務以及其他復雜業務場景下的分布式事務問題，同時其基于Go語言實現也使得在Go語言項目中集成和使用更加方便快捷。

本文轉載自微信公眾號「王中陽Go」，作者「王中陽Go」，可以通過以下二維碼關注。

轉載本文請聯系「王中陽Go」公眾號。