在電商、新零售等業務場景中,商品庫存的準確扣減是核心且敏感的環節。完全依賴數據庫處理庫存扣減,其核心目標是在高并發下保證數據的一致性(不超賣)、操作的原子性以及系統的性能。以下是幾種經過實踐檢驗、相對“好一點兒”的數據庫處理方案。
方案一:基于樂觀鎖的版本號控制
這是最經典且易于理解的方案。其核心思想是假設并發沖突不常發生,在更新時檢測數據是否被其他事務修改過。
實現方式:
1. 在商品庫存表中增加一個版本號字段(如 version,初始為0)。
2. 扣減時,將版本號作為更新條件。
UPDATE product_stock
SET stock = stock - #{purchase_quantity},
version = version + 1
WHERE id = #{product_id}
AND stock >= #{purchase_quantity}
AND version = #{current_version}; -- 帶入查詢時獲取的版本號
優點: 實現簡單,在沖突率低的場景下性能很好。
缺點: 在高并發搶購場景下,大量事務會因版本號不一致而更新失敗(需要業務層重試或提示用戶),成功率低。
方案二:基于數據庫行級鎖(悲觀鎖)SELECT ... FOR UPDATE
在事務內,先鎖定要更新的庫存行,再進行操作,確保操作的串行化。
實現方式:`sql
BEGIN; -- 開啟事務
-- 1. 鎖定目標行,防止其他事務修改
SELECT stock FROM productstock WHERE id = #{productid} FOR UPDATE;
-- 2. 應用層判斷庫存是否充足
-- 3. 執行更新
UPDATE productstock SET stock = stock - #{quantity} WHERE id = #{productid};
COMMIT; -- 提交事務`
優點: 絕對保證一致性,邏輯簡單直接。
缺點: 性能瓶頸明顯,大量請求會排隊等待鎖,數據庫連接容易被打滿,不適合超高并發場景。
方案三:直接條件更新(無鎖方案,推薦)
這是最推薦的純數據庫扣減方案。它利用數據庫更新語句本身的原子性和行鎖,在一個SQL中完成判斷和扣減。
實現方式:`sql
UPDATE productstock
SET stock = stock - #{purchasequantity}
WHERE id = #{productid}
AND stock >= #{purchasequantity}; -- 核心:將庫存判斷放在WHERE條件中`
執行后,通過判斷數據庫返回的“受影響行數”(affected rows):
- 如果受影響行數為 1,說明扣減成功,庫存充足且已原子性扣減。
- 如果受影響行數為 0,說明扣減失敗,原因是庫存不足或商品不存在。
優點:
1. 極致高效: 單條SQL,網絡開銷小,利用數據庫原生原子性,無需額外鎖。
2. 絕對安全: 在WHERE條件中校驗庫存,徹底杜絕超賣。
3. 簡單可靠: 業務邏輯清晰,依賴數據庫本身能力,維護成本低。
這是處理數據庫庫存扣減的黃金法則,在絕大多數場景下應作為首選。
方案四:設置庫存字段為無符號整數
這是一個輔助性的“防御”策略,與上述方案結合使用。
實現方式:
在數據庫表設計時,將庫存字段 stock 定義為 UNSIGNED(無符號整數)。
CREATE TABLE product_stock (
id BIGINT PRIMARY KEY,
stock INT UNSIGNED NOT NULL COMMENT '庫存,無符號保證不為負'
);
作用: 當執行 UPDATE SET stock = stock - 10 而庫存不足時,由于字段不能為負,數據庫會直接報錯(如“BIGINT UNSIGNED value is out of range”)。這可以作為防止異常數據操作的最后一道防線,但業務層仍需以方案三的條件更新為主邏輯進行友好處理。
方案五:扣減與記錄分離(預扣庫存)
對于更復雜的場景(如購物車待付款),可以引入“可用庫存”和“預扣庫存”的概念。
實現方式:
1. 商品表中有兩個字段:available<em>stock(可用庫存)、locked</em>stock(預扣庫存,如已下單未支付)。
2. 用戶下單時,扣減available<em>stock,同時增加locked</em>stock。
`sql
UPDATE productstock
SET availablestock = availablestock - #{quantity},
lockedstock = lockedstock + #{quantity}
WHERE id = #{productid}
AND available_stock >= #{quantity};
`
- 支付成功時,扣減
locked_stock。 - 支付超時或取消時,將
locked<em>stock加回available</em>stock。
優點: 清晰區分庫存狀態,支持復雜的電商業務流程。
缺點: 業務邏輯和狀態機變得更復雜。
與建議
- 通用首選: 方案三(直接條件更新) 是簡單、高效、可靠的“銀彈”,應作為滿足基礎扣減需求的首選。
- 組合使用: 將 方案三 與 方案四(無符號字段) 結合,實現代碼邏輯與數據庫級別的雙重保障。
- 場景選擇:
- 對性能要求極高,業務邏輯簡單 → 方案三。
- 需要處理中間狀態(如待支付)→ 方案五。
- 遺留系統或特定復雜事務 → 方案二(需謹慎評估性能)。
- 必要補充: 無論采用哪種方案,都應在數據庫表上為庫存字段和商品ID建立合適的索引,以加速更新操作。業務層必須妥善處理更新失敗(返回受影響行數為0)的情況,給用戶明確的反饋。
通過以上純數據庫層面的優化,可以在不引入復雜中間件(如Redis)的情況下,構建出高并發下穩定、準確的商品庫存扣減系統。