支付中臺：從閘道器層到資料分析層詳解

支付與我們的生活息息相關，在面試中也經常問到，這是我們就業陪跑訓練營中小夥伴總結的文章，和大家分享一下，覺好留贊呦，感謝支援！

（一）支付架構流程

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語言專案中整合和使用更加方便快捷。

歡迎關注 ❤

我們搞了一個免費的面試真題共享群，互通有無，一起刷題進步。

沒準能讓你能刷到自己意向公司的最新面試題呢。

感興趣的朋友們可以加我微信：wangzhongyang1993，備註：sf面試群。