庫存管理看似只是“增減數字”的簡單操作，實則是銜接訂單、支付、物流的關鍵樞紐。哪怕是0.1%的庫存數據偏差，都可能引發超賣、漏發等直接影響用戶體驗與平臺信譽的事故。我們團隊在為某生鮮電商搭建季節性商品庫存系統時，就曾遭遇一場因“分布式事務未閉環”導致的大規模超賣—當平臺推出“限時秒殺”活動，上萬用戶同時下單時，庫存數據在多服務交互中出現“幽靈扣減”，最終導致實際發貨量超出庫存近300單。這場事故不僅讓平臺承擔了高額的賠償成本，更暴露了庫存系統在高并發場景下的設計。此次復盤，我們將從問題爆發到體系重構的全過程拆解，為電商領域的庫存防護提供可落地的技術方案。

該生鮮電商的庫存系統，核心需求是支撐“多倉發貨+預售+限時秒殺”三大業務場景。系統架構采用“微服務拆分”模式，庫存服務獨立于訂單、支付服務，負責實時更新商品庫存、校驗庫存可用性；訂單服務在用戶下單時調用庫存服務的“預扣減”接口鎖定庫存，待用戶支付完成后，再調用“確認扣減”接口正式減少庫存；若用戶超時未支付，則觸發“庫存釋放”邏輯。為應對生鮮商品“短保質期、高周轉”的特性，系統還需支持“臨期庫存預警”“跨倉調撥實時同步”功能，確保庫存數據與實際倉儲情況一致。技術選型上，庫存核心數據存儲于MySQL，采用“商品ID+倉庫ID”雙主鍵設計，并通過Redis緩存熱門商品的實時庫存，減少數據庫訪問壓力。上線前的壓測中，我們模擬了5000用戶/秒的下單場景，庫存扣減響應時間穩定在50ms內，未出現任何數據異常，所有人都認為這套方案足以應對秒殺活動的壓力。

然而在首場“草莓秒殺”活動中，問題卻在活動開始后10分鐘集中爆發。客服后臺突然涌入大量“下單成功卻被通知無貨”的投訴，部分用戶甚至曬出了訂單截圖與客服的“缺貨致歉”消息，在社交平臺引發討論。技術團隊緊急核查庫存數據，發現后臺顯示某規格草莓的庫存為“-287”，而實際倉庫中的該規格草莓早已售罄。更詭異的是，訂單系統顯示有321單已支付訂單關聯該規格草莓，但庫存系統的“確認扣減”記錄僅298條，存在23條“支付完成卻未扣減庫存”的異常數據。同時，部分用戶反饋“下單時顯示有庫存，點擊支付后卻提示庫存不足”，但訂單卻被強制生成，陷入“待支付卻無法支付”的僵局。這場超賣不僅讓平臺不得不向287位用戶支付“缺貨賠償券”，更因“庫存顯示混亂”導致后續1小時內該商品的下單轉化率驟降40%，直接損失超10萬元。更棘手的是，初期排查時，我們反復回放活動日志，卻發現庫存服務的“預扣減”“確認扣減”接口均返回“成功”，沒有任何報錯信息，數據異常仿佛憑空出現。

為找到根因，我們成立專項小組，從“接口調用鏈路”“數據交互時序”“事務完整性”三個維度展開深度排查。第一輪排查聚焦接口調用日志，我們將訂單服務、庫存服務、支付服務在活動期間的日志按時間戳拼接，發現部分訂單存在“支付完成后，庫存確認扣減接口被重復調用”的情況—某用戶的同一筆訂單，支付服務在100ms內連續向庫存服務發送了2次“確認扣減”請求，而庫存服務均返回“扣減成功”，導致該訂單對應的庫存被重復扣除。進一步分析發現，這是因支付服務的“異步回調重試機制”設計不合理：當支付平臺回調通知超時，支付服務會立即發起重試，且未設置“冪等校驗”，導致重復回調觸發多次庫存扣減。第二輪排查針對“庫存預扣減超時”場景，我們發現當用戶下單后超時未支付，庫存服務的“釋放庫存”接口偶爾會執行失敗—日志顯示“釋放庫存時，數據庫行鎖等待超時”。原來在高并發下，大量“預扣減”操作占用了數據庫行鎖，導致“釋放庫存”的SQL因等待鎖超時被中斷，而代碼中未對“釋放失敗”場景做重試處理，造成部分被鎖定的庫存無法及時釋放，形成“庫存幽靈鎖定”，實際可用庫存被虛減，間接導致后續下單時的庫存判斷失真。第三輪排查則鎖定了“Redis緩存與數據庫數據不一致”的問題：庫存服務在更新數據庫庫存后，會異步更新Redis緩存，但在活動高峰時，部分“數據庫更新成功、Redis更新失敗”的情況未被捕獲—因Redis連接池耗盡，緩存更新請求被丟棄，而代碼中未設置“緩存更新失敗重試”或“緩存與數據庫一致性校驗”邏輯，導致Redis中顯示的庫存高于實際數據庫庫存，用戶看到“有庫存”下單，實際卻因數據庫庫存不足導致超賣。

找到三大核心問題后，我們沒有停留在“補丁式修復”，而是從“事務閉環”“冪等防護”“數據一致性”三個維度構建完整的庫存防護體系。首先，針對“重復扣減”問題，我們為所有庫存操作接口添加“冪等校驗”機制：在調用“確認扣減”“釋放庫存”接口時，必須傳入唯一的“業務流水號”（如訂單號、支付流水號），庫存服務將流水號與操作類型（扣減/釋放）作為聯合唯一鍵存儲在MySQL，若檢測到重復的流水號請求，直接返回“操作成功”，不執行實際庫存變更。同時，優化支付服務的回調重試策略，將“立即重試”改為“指數退避重試”（間隔1秒、3秒、5秒），并在重試前先查詢庫存服務的操作結果，避免無效重試。其次，針對“庫存釋放失敗”問題，我們重構了庫存事務邏輯：將“預扣減庫存”“釋放庫存”操作封裝為數據庫事務，并引入“分布式事務框架”（Seata）確保跨服務操作的原子性；同時，為“釋放庫存”操作添加“定時補償任務”—每5分鐘掃描一次“預扣減超過30分鐘未確認”的庫存記錄，自動執行釋放邏輯，并記錄補償日志，由運維人員定期核查。對于數據庫行鎖問題，我們優化了庫存表的索引設計，將“商品ID+倉庫ID”的聯合主鍵索引，改為“商品ID+倉庫ID+庫存狀態”的復合索引，減少鎖競爭范圍，同時將庫存扣減SQL改為“樂觀鎖”實現（通過版本號控制），避免長時間占用行鎖。最后，針對“緩存與數據庫不一致”問題，我們設計了“緩存更新雙保障”機制：一是采用“先更新數據庫，再刪除緩存，最后異步重建緩存”的策略，避免更新緩存時的并發問題；二是新增“緩存一致性校驗任務”，每10分鐘抽取10%的熱門商品，對比Redis緩存與數據庫庫存數據，若偏差超過1%，立即觸發全量緩存重建，并發送告警信息。同時，優化Redis連接池配置，設置“連接超時重試”與“隊列緩沖”，避免高并發下連接池耗盡導致的緩存更新失敗。

這場超賣事故的復盤，讓我們深刻意識到：電商庫存系統的“穩定性”，本質是“數據一致性”與“事務完整性”的雙重保障。在高并發場景下，任何一個未閉環的事務、未校驗的請求、未同步的數據，都可能成為引發事故的“蝴蝶效應”起點。基于此次經驗，我們提煉出三條電商庫存系統設計的核心原則。其一，“所有接口必做冪等”—在分布式環境中，網絡延遲、服務重試、回調重復等情況無法完全避免，必須通過唯一標識、狀態校驗等方式，確保重復請求不會引發數據異常，這是防護的“第一道防線”。其二，“事務必須閉環”—庫存的“預扣減-確認-釋放”是完整的事務鏈路，任何一個環節的失敗都需有對應的補償機制，不能依賴“默認成功”的樂觀假設，通過定時任務、分布式事務等手段，確保事務最終一致性。其三，“緩存不能替代數據庫”—Redis緩存的核心價值是“性能加速”，而非“數據存儲”，必須設計緩存與數據庫的一致性校驗、失敗重試機制，避免因緩存數據失真導致業務決策錯誤。