庫存系統的架構很有意思，從上圖來看功能上其實並不復雜，但是他面臨的技術復雜度卻是相當高的，比如秒殺品在高並發的情況下如何防止超賣，另外庫存系統還不是一個純技術的系統，需要結合用戶的行為特點來考慮，比如下文中提到什么時間進行庫存的扣減最合適，我們先拋出幾個問題和大家一起探討下，如有有妥不處，歡迎大家拍磚。
庫存什么時候進行預占(或者扣減)呢
商家銷售的商品數量是有限的，用戶下單后商品會被扣減，我們可以怎么實現呢？
舉個例子：一件商品有1000個庫存，現在有1000個用戶，每個用戶計划同時購買1000個。
-
（實現方案1）如果用戶加入購物車時進行庫存預占，那么將只能有1個用戶將1000個商品加入購物車。
-
（實現方案2）如果用戶提交訂單時進行庫存預占，那么將也只能有1個用戶將1000個商品提單成功，其它的人均提示“庫存不足，提單失敗”。
-
（實現方案3）如果用戶提交訂單&支付成功時進行庫存預占，那么這1000個人都能生成訂單，但是只有1個人可以支付成功，其它的訂單均會被自動取消。
京東到家目前采用的是方案2，理由：
-
用戶可能只是暫時加入購物車，並不表示用戶最終會提單並支付。
-
所以在購物車進行庫存校驗並預占，會造成其它真正想買的用戶不能加入購物車的情況，但是之前加車的用戶一直不付款，最終損失的是公司。
-
方案3會造成生成1000個訂單，無論是在支付前校驗庫存還是在支付成功后再檢驗庫存，都會造成用戶准備好支付條件后卻會出現99.9%的系統取消訂單的概率，也就是說會給99.9%的用戶體驗到不爽的感覺。
-
數據表明用戶提交訂單不支付的占比是非常小的（相對於加入購物車不購買的行為），目前京東到家給用戶預留的最長支付時間是30分鍾，超過30分鍾訂單自動取消，預占的庫存自動釋放
綜上所述，方案2也可能由於用戶下單預占庫存但最終未支付，造成庫存30分鍾后才能被其它用戶使用的情況，但是相較於方案1，方案3無疑是折中的最好方案。
重復提交訂單的問題？
重復提交訂單造成的庫存重復扣減的后果是比較嚴重的。比如商家設置有1000件商品，而實際情況可能賣了900件就提示用戶無貨了，給商家造成無形的損失
可能出現重復提交訂單的情況：
-
（1、用戶善意行為）app上用戶單擊“提交訂單”按鈕后由於后端接口沒有返回，用戶以為沒有操作成功會再次單擊“提交訂單”按鈕
-
（2、用戶惡意行為）黑客直接刷提單接口，繞過App端防重提交功能
-
（3、提單系統重試）比如提單系統為了提高系統的可用性，在第一次調用庫存系統扣減接口超時后會重試再次提交扣減請求
好了，既然問題根源縷清楚了，我們一一對症下葯
-
（1、用戶善意行為）app側在用戶第一次單擊“提交訂單”按鈕后對按鈕進行置灰，禁止再次提交訂單
-
（2、用戶惡意行為）采用令牌機制，用戶每次進入結算頁，提單系統會頒發一個令牌ID（全局唯一），當用戶點擊“提交訂單”按鈕時發起的網絡請求中會帶上這個令牌ID,這個時候提單系統會優先進行令牌ID驗證，令牌ID存在&令牌ID訪問次數=1的話才會放行處理后續邏輯，否則直接返回
-
（3、提單系統重試）這種情況則需要后端系統（比如庫存系統）來保證接口的冪等性，每次調用庫存系統時均帶上訂單號，庫存系統會基於訂單號增加一個分布式事務鎖
需要庫存回滾的場景也是比較多的，比如：
-
（1、用戶未支付）用戶下單后后悔了
-
（2、用戶支付后取消）用戶下單&支付后后悔了
-
（3、風控取消）風控識別到異常行為，強制取消訂單
-
（4、耦合系統故障）比如提交訂單時提單系統T1同時會調用積分扣減系統X1、庫存扣減系統X2、優惠券系統X3，假如X1,X2成功后，調用X3失敗，需要回滾用戶積分與商家庫存。
其中場景1，2，3比較類似，都會造成訂單取消，訂單中心取消后會發送mq出來，各個系統保證自己能夠正確消費訂單取消MQ即可。而場景4訂單其實尚未生成，相對來說要復雜些，如上面提到的，提單系統T1需要主動發起庫存系統X2、優惠券系統X3的回滾請求（入參必須帶上訂單號），X2、X3回滾接口需要支持冪等性。
其實針對場景4，還存在一種極端情況，如果提單系統T1准備回滾時自身也宕機了，那么庫存系統X2、優惠券系統X3就必須依靠自己為完成回滾操作了，也就是說具備自我數據健康檢查的能力，具體來說怎么實現呢？
可以利用當前訂單號所屬的訂單尚未生成的特點，可以通過worker機制，每次撈取40分鍾（這里的40一定要大於容忍用戶的支付時間）前的訂單，調用訂單中心查詢訂單的狀態，確保不是已取消的，否則進行自我數據的回滾。
多人同時購買1件商品，如何安全地庫存扣減
現實中同一件商品可能會出現多人同時購買的情況，我們可以如何做到並發安全呢？
如果商品是促銷品（比如參與了秒殺的商品）並發扣減的機率會更高，那么數據庫的壓力會更高，這個時候還可以怎么做呢 海量的用戶秒殺請求,本質上是一個排序,先到先得.但是如此之多的請求，注定了有些人是搶不到的，可以在進入上述偽代碼Dao層之前增加一個計數器進行控制，比如有50%的流量將直接告訴其搶購失敗