項目經驗處理

訂單取消和支付成功并發問題

這是一個非常經典且重要的分布式系統問題。訂單取消和支付成功同時發生，本質上是一個資源競爭問題，核心在于如何保證兩個并發操作對訂單狀態的修改滿足業務的最終一致性（即一個訂單最終只能有一種確定的狀態）。

核心業務原則與狀態機

首先，必須明確一個堅不可摧的業務規則：一個訂單一旦支付成功，就絕不能被取消。 反之，一個訂單如果先被成功取消，那么后續的支付也應該失敗。

這通常通過訂單狀態機來實現：

初始狀態：待支付
可變為：已支付 （支付操作）或 已取消 （取消操作）
已支付 和 已取消 是兩個終點狀態，不能再相互轉換。

我們的所有技術方案都是為了保護這個狀態機的正確流轉。

方案一：數據庫悲觀鎖 (Pessimistic Locking) - 簡單粗暴

適用場景： 單體架構，數據庫壓力不大，并發沖突相對較少的場景。

實現原理： 在修改訂單狀態前，先通過 SELECT ... FOR UPDATE 鎖定數據庫中的這條訂單記錄。這樣其他事務在嘗試修改這條記錄時會被阻塞，直到鎖被釋放，從而保證了操作的串行化。

實現步驟（以支付和取消同時發生為例）：

無論是支付回調邏輯還是取消邏輯，在開始處理時，首先開啟一個數據庫事務。
在事務中，使用 SELECT * FROM orders WHERE order_id = ? FOR UPDATE 查詢并鎖定訂單記錄。
檢查訂單的當前狀態：
- 如果狀態是 待支付，則繼續執行支付或取消操作，更新狀態。
- 如果狀態已經是 已支付，則取消操作應識別到此狀態，直接返回“取消失敗，訂單已支付”并結束邏輯。
- 如果狀態已經是 已取消，則支付操作應識別到此狀態，直接返回“支付失敗，訂單已關閉”并結束邏輯。
提交事務，釋放鎖。

優點：

實現簡單，直接利用數據庫的能力。
強一致性保證。

缺點：

性能瓶頸：并發高時，大量請求會被阻塞，數據庫連接池容易被耗盡的，響應時間變長。
不適合分布式系統：如果應用是集群部署，多個節點間的數據庫連接是共享的，這個方法仍然有效，但數據庫本身會成為單點瓶頸。
死鎖風險：需要仔細控制業務的加鎖順序。

方案二：數據庫樂觀鎖 (Optimistic Locking) - 推薦常用

適用場景： 絕大多數并發場景，特別是讀多寫少的情況。單體和服務化架構都適用。

實現原理： 不對數據加鎖，而是通過一個版本號（version）字段或時間戳來實現。在更新時，檢查版本號是否和最初讀取時一致，如果一致則更新成功并版本號+1，否則更新失敗，意味著數據已被其他操作修改過。

實現步驟：

訂單表增加一個 version 字段（或使用 update_time 時間戳）。
支付或取消邏輯開始時，先查詢出訂單的當前狀態和當前 version（例如 version=1）。
根據業務邏輯計算下一個狀態。

執行更新操作：

UPDATE orders 
SET status = '已支付', version = version + 1 
WHERE order_id = ? AND version = 1; -- 這里version是之前查出來的值

或

UPDATE orders 
SET status = '已取消', version = version + 1 
WHERE order_id = ? AND version = 1;

檢查更新語句的影響行數（affected rows）：
- 如果影響行數為 1，說明更新成功，搶到了資源。
- 如果影響行數為 0，說明 WHERE 條件不成立（即 version 已經變了），更新失敗。此時可以重新查詢訂單的最新狀態，并告知用戶“操作失敗，請重試”或根據最新狀態進行后續處理（例如支付時發現訂單已取消，則進行退款）。

優點：

性能比悲觀鎖好很多，避免了數據庫鎖的開銷。
適用于分布式環境。

缺點：

需要處理更新失敗的情況，業務邏輯稍復雜（通常需要重試或提示用戶）。
如果沖突頻率非常高，頻繁的重試反而會降低性能。

方案三：狀態機 + 數據庫唯一約束 - 優雅冪等

適用場景： 作為輔助手段，與樂觀鎖結合使用，提供更強的冪等性和一致性保證。

實現原理： 利用數據庫的唯一鍵約束，來防止訂單狀態被重復更新。例如，可以創建一張“訂單狀態變更流水表”。

創建訂單狀態流水表 order_status_log:

CREATE TABLE order_status_log (id BIGINT PRIMARY KEY AUTO_INCREMENT,order_id BIGINT NOT NULL,from_status VARCHAR(20),to_status VARCHAR(20) NOT NULL,create_time DATETIME,-- 唯一約束：一個訂單的每次狀態變更必須是唯一的UNIQUE KEY uk_order_id_status (order_id, from_status, to_status)
);

在更新訂單主表狀態時，在同一數據庫事務中，向流水表插入一條記錄。
- 例如，從 待支付 變更為 已支付，則插入 (order_id, ‘待支付’, ‘已支付’, now())。
如果兩個操作同時發生，比如支付和取消都通過了樂觀鎖的版本檢查，嘗試更新主表和插入流水表。由于流水表的 UNIQUE KEY uk_order_id_status (order_id, from_status, to_status) 約束，第二個插入操作必然會失敗，從而導致整個事務回滾。
最終只有一個操作能成功。

優點：

提供了極強的數據一致性保證，幾乎不可能出現狀態錯亂。
流水表本身也具有審計和追溯的價值。

缺點：

業務邏輯更復雜，需要維護兩張表。
依然依賴數據庫事務。

方案四：消息隊列 + 最終一致性 - 分布式解耦

適用場景： 大型分布式系統，業務解耦要求高，吞吐量大的場景。

實現原理： 將同步的、可能沖突的操作，通過消息隊列串行化處理。支付成功和取消請求都先發送到消息隊列，由一個消費者按順序逐個處理，從而從根本上避免并發沖突。

實現步驟：

消息生產：
- 支付回調異步通知和用戶取消請求，都不直接處理業務邏輯。
- 它們只負責校驗基礎參數，然后向一個特定主題的消息隊列（如 RocketMQ/Kafka）發送一條消息。消息體包含訂單ID和操作類型（e.g., {"orderId": 123, "event": "PAYMENT_SUCCESS"}）。
消息消費：
- 創建一個順序消息消費者，監聽這個主題。確保同一個訂單ID的消息被發送到同一個MessageQueue，并被同一個消費者順序處理。
- 消費者接收到消息后：
  a. 開啟事務。
  b. 查詢訂單（無需FOR UPDATE，因為消息是順序的）。
  c. 檢查訂單狀態機：
  - 若當前狀態允許執行目標操作（如狀態是待支付，目標是已支付），則更新狀態。
  - 若不允許（如狀態已是已取消，目標是已支付），則丟棄消息或記錄日志（說明發生了沖突，但由消費者優雅處理了）。
  d. 提交事務。
  e. 消費成功，確認消息。

優點：

高吞吐量，性能好。
徹底解耦，支付和取消的發起方不需要等待業務處理完成。
通過順序消息天然解決了并發問題。

缺點：

架構復雜，引入了消息隊列組件。
一致性是最終一致性，處理會有毫秒級或秒級的延遲。
需要保證消息的可靠投遞和不重復消費（冪等），通常消息隊列本身能提供Exactly-Once或At-Least-Once語義，消費端需要做冪等（方案二的樂觀鎖或方案三的狀態流水正好可以用來做冪等）。

方案五：分布式鎖 - 通用方案

適用場景： 分布式系統，需要對某個分布式資源進行互斥訪問。

實現原理： 在執行業務邏輯前，先嘗試獲取一個基于訂單ID的分布式鎖（如 Redis 的 SET order_id:123 random_value NX EX 30）。只有拿到鎖的操作才能繼續執行查詢和更新訂單狀態的邏輯。

實現步驟：

支付或取消邏輯開始時，先嘗試獲取指定 order_id 的分布式鎖。
獲取成功，則繼續執行數據庫查詢和更新邏輯（此時可以用簡單的先查后改，因為鎖保證了互斥）。
獲取失敗，則重試或直接返回“系統繁忙，請稍后再試”。
業務邏輯處理完成后，釋放分布式鎖。

優點：

通用性強，不依賴于數據庫特性。
適用于任何需要互斥訪問的分布式場景。

缺點：

引入新的組件（如Redis），增加了系統復雜性。
如果鎖失效時間設置不當，可能導致鎖提前釋放（業務沒做完）或死鎖（業務做完鎖沒釋放）。
性能開銷比數據庫樂觀鎖大。

總結與選型建議

方案	復雜度	一致性	性能	適用架構	核心思想
悲觀鎖	低	強一致性	差	單體	先加鎖，再操作
樂觀鎖	中	最終一致性	好	單體/分布式	無鎖檢測，失敗重試
狀態機+約束	中	強一致性	中	單體/分布式	利用數據庫約束防沖突
消息隊列	高	最終一致性	極好	分布式	異步化與串行化
分布式鎖	高	最終一致性	中	分布式	外部組件實現互斥