1. Lua腳本 + Redis（業界首選，綜合最優）

核心邏輯：將“檢查庫存→扣減庫存→返回結果”的完整邏輯用Lua腳本編寫，通過Redis的 EVAL 命令執行，利用Redis對Lua腳本的原子性支持（整個腳本作為單個命令執行，不被其他請求打斷）。
優勢：

• 原子性最強：天然避免并發沖突，從根本上解決超賣問題；
• 靈活性高：支持復雜邏輯（如庫存閾值校驗、階梯扣減、關聯優惠券判斷等）；
• 性能最優：一次網絡請求完成所有操作，減少IO開銷；
• 兼容性好：不依賴特定語言或客戶端，所有Redis客戶端都支持。
  適用場景：幾乎所有庫存扣減場景，尤其是高并發秒殺、促銷活動（如淘寶雙11、京東618的核心庫存邏輯）。
  業界案例：阿里云秒殺系統、京東商品庫存核心模塊、微信支付庫存校驗。

2. Redis原子命令（DECRBY + 結果校驗）

核心邏輯：直接使用Redis的 DECRBY 命令扣減庫存，通過返回結果判斷是否成功（若結果≥0則成功，否則回滾）。
優勢：實現最簡單，單命令性能極致，適合超高并發場景；
缺點：邏輯逆向（先扣減再判斷），可能出現短暫負庫存（需立即回滾），不支持扣減前的復雜校驗。
適用場景：超高并發且邏輯極簡的場景（如秒殺活動的第一道庫存攔截）。
業界案例：部分秒殺系統的前置過濾層、簡單商品的快速庫存扣減。

3. Redis事務（MULTI/EXEC）

核心邏輯：通過 MULTI 標記事務，將“查庫存→扣庫存”命令放入隊列，EXEC 一次性執行。
優勢：原生支持，無需額外依賴，適合中小并發場景；
缺點：需在客戶端二次判斷庫存（樂觀鎖機制），不支持復雜邏輯，執行失敗時需手動回滾。
適用場景：并發量不高、邏輯簡單的普通商品下單（如日均訂單量10萬級以下的電商）。

4. 分布式鎖（基于Redis實現）

核心邏輯：用 SET key value NX PX 獲取分布式鎖，確保同一時間只有一個線程操作庫存，執行“查庫存→扣庫存”后釋放鎖。
優勢：支持復雜業務邏輯（如結合用戶權限、訂單狀態校驗）；
缺點：實現復雜（需處理鎖超時、重入、誤釋放等問題），性能損耗較高（加鎖/釋放鎖開銷）。
適用場景：需要結合復雜業務規則的庫存扣減（如VIP用戶優先扣減、關聯訂單狀態的庫存調整）。
業界案例：部分電商的訂單確認環節（需關聯物流、優惠券等多維度校驗）。

5. Redisson客戶端封裝（Java生態首選）

核心邏輯：通過Redisson提供的 RSemaphore（信號量）或 RLock（分布式鎖），底層自動實現原子性操作（內部基于Lua腳本或Redis命令）。
優勢：封裝完善，簡化分布式鎖、原子操作的開發（如自動續期、重入鎖）；
缺點：僅限Java生態，靈活性略低（依賴客戶端實現）。
適用場景：Java技術棧項目，希望減少手動處理分布式問題的場景。

6. 數據庫事務 + Redis雙寫

核心邏輯：以MySQL等數據庫為權威數據源，通過數據庫事務保證庫存扣減原子性，同步更新Redis緩存（最終一致性）。
優勢：強一致性（數據庫事務保證），適合對數據可靠性要求極高的場景；
缺點：性能差（數據庫成為瓶頸），Redis與數據庫可能存在短暫不一致。
適用場景：并發量低、高價值商品（如奢侈品、珠寶）的庫存管理。

業界主流：

• 絕對主流：Lua+Redis 是高并發庫存扣減的事實標準，幾乎所有大型電商、秒殺系統的核心庫存邏輯都采用此方案（兼顧原子性、性能、靈活性）。
• 補充方案：原子命令（DECRBY）用于極致性能場景，分布式鎖用于復雜業務場景，數據庫事務僅用于低并發、高價值商品場景。

簡單說：Lua+Redis = 庫存扣減的“最優解”，是業界處理高并發庫存問題的首選技術方案。