庫存系統(tǒng)的架構(gòu)很有意思，從上圖來看功能上其實并不復(fù)雜，但是他面臨的技術(shù)復(fù)雜度卻是相當(dāng)高的，比如秒殺品在高并發(fā)的情況下如何防止超賣，另外庫存系統(tǒng)還不是一個純技術(shù)的系統(tǒng)，需要結(jié)合用戶的行為特點來考慮，比如下文中提到什么時間進(jìn)行庫存的扣減最合適，我們先拋出幾個問題和大家一起探討下，如有有妥不處，歡迎大家拍磚。

庫存什么時候進(jìn)行預(yù)占(或者扣減)呢

商家銷售的商品數(shù)量是有限的，用戶下單后商品會被扣減，我們可以怎么實現(xiàn)呢？

舉個例子：一件商品有1000個庫存，現(xiàn)在有1000個用戶，每個用戶計劃同時購買1000個。

（實現(xiàn)方案1）如果用戶加入購物車時進(jìn)行庫存預(yù)占，那么將只能有1個用戶將1000個商品加入購物車。

（實現(xiàn)方案2）如果用戶提交訂單時進(jìn)行庫存預(yù)占，那么將也只能有1個用戶將1000個商品提單成功，其它的人均提示“庫存不足，提單失敗”。

（實現(xiàn)方案3）如果用戶提交訂單&支付成功時進(jìn)行庫存預(yù)占，那么這1000個人都能生成訂單，但是只有1個人可以支付成功，其它的訂單均會被自動取消。

京東到家目前采用的是方案2，理由：

用戶可能只是暫時加入購物車，并不表示用戶最終會提單并支付。

所以在購物車進(jìn)行庫存校驗并預(yù)占，會造成其它真正想買的用戶不能加入購物車的情況，但是之前加車的用戶一直不付款，最終損失的是公司。

方案3會造成生成1000個訂單，無論是在支付前校驗庫存還是在支付成功后再檢驗庫存，都會造成用戶準(zhǔn)備好支付條件后卻會出現(xiàn)99.9%的系統(tǒng)取消訂單的概率，也就是說會給99.9%的用戶體驗到不爽的感覺。

數(shù)據(jù)表明用戶提交訂單不支付的占比是非常小的（相對于加入購物車不購買的行為），目前京東到家給用戶預(yù)留的最長支付時間是30分鐘，超過30分鐘訂單自動取消，預(yù)占的庫存自動釋放

綜上所述，方案2也可能由于用戶下單預(yù)占庫存但最終未支付，造成庫存30分鐘后才能被其它用戶使用的情況，但是相較于方案1，方案3無疑是折中的最好方案。

重復(fù)提交訂單的問題？

重復(fù)提交訂單造成的庫存重復(fù)扣減的后果是比較嚴(yán)重的。比如商家設(shè)置有1000件商品，而實際情況可能賣了900件就提示用戶無貨了，給商家造成無形的損失

可能出現(xiàn)重復(fù)提交訂單的情況：

（1、用戶善意行為）app上用戶單擊“提交訂單”按鈕后由于后端接口沒有返回，用戶以為沒有操作成功會再次單擊“提交訂單”按鈕

（2、用戶惡意行為）黑客直接刷提單接口，繞過App端防重提交功能

（3、提單系統(tǒng)重試）比如提單系統(tǒng)為了提高系統(tǒng)的可用性，在第一次調(diào)用庫存系統(tǒng)扣減接口超時后會重試再次提交扣減請求

好了，既然問題根源縷清楚了，我們一一對癥下藥

（1、用戶善意行為）app側(cè)在用戶第一次單擊“提交訂單”按鈕后對按鈕進(jìn)行置灰，禁止再次提交訂單

（2、用戶惡意行為）采用令牌機(jī)制，用戶每次進(jìn)入結(jié)算頁，提單系統(tǒng)會頒發(fā)一個令牌ID（全局唯一），當(dāng)用戶點擊“提交訂單”按鈕時發(fā)起的網(wǎng)絡(luò)請求中會帶上這個令牌ID,這個時候提單系統(tǒng)會優(yōu)先進(jìn)行令牌ID驗證，令牌ID存在&令牌ID訪問次數(shù)=1的話才會放行處理后續(xù)邏輯，否則直接返回

（3、提單系統(tǒng)重試）這種情況則需要后端系統(tǒng)（比如庫存系統(tǒng)）來保證接口的冪等性，每次調(diào)用庫存系統(tǒng)時均帶上訂單號，庫存系統(tǒng)會基于訂單號增加一個分布式事務(wù)鎖

需要庫存回滾的場景也是比較多的，比如：

（1、用戶未支付）用戶下單后后悔了

（2、用戶支付后取消）用戶下單&支付后后悔了

（3、風(fēng)控取消）風(fēng)控識別到異常行為，強(qiáng)制取消訂單

（4、耦合系統(tǒng)故障）比如提交訂單時提單系統(tǒng)T1同時會調(diào)用積分扣減系統(tǒng)X1、庫存扣減系統(tǒng)X2、優(yōu)惠券系統(tǒng)X3，假如X1,X2成功后，調(diào)用X3失敗，需要回滾用戶積分與商家?guī)齑妗?/p>

其中場景1，2，3比較類似，都會造成訂單取消，訂單中心取消后會發(fā)送mq出來，各個系統(tǒng)保證自己能夠正確消費訂單取消MQ即可。而場景4訂單其實尚未生成，相對來說要復(fù)雜些，如上面提到的，提單系統(tǒng)T1需要主動發(fā)起庫存系統(tǒng)X2、優(yōu)惠券系統(tǒng)X3的回滾請求（入?yún)⒈仨殠嫌唵翁枺?，X2、X3回滾接口需要支持冪等性。

其實針對場景4，還存在一種極端情況，如果提單系統(tǒng)T1準(zhǔn)備回滾時自身也宕機(jī)了，那么庫存系統(tǒng)X2、優(yōu)惠券系統(tǒng)X3就必須依靠自己為完成回滾操作了，也就是說具備自我數(shù)據(jù)健康檢查的能力，具體來說怎么實現(xiàn)呢？

可以利用當(dāng)前訂單號所屬的訂單尚未生成的特點，可以通過worker機(jī)制，每次撈取40分鐘（這里的40一定要大于容忍用戶的支付時間）前的訂單，調(diào)用訂單中心查詢訂單的狀態(tài)，確保不是已取消的，否則進(jìn)行自我數(shù)據(jù)的回滾。

多人同時購買1件商品，如何安全地庫存扣減

現(xiàn)實中同一件商品可能會出現(xiàn)多人同時購買的情況，我們可以如何做到并發(fā)安全呢？

如果商品是促銷品（比如參與了秒殺的商品）并發(fā)扣減的機(jī)率會更高，那么數(shù)據(jù)庫的壓力會更高，這個時候還可以怎么做呢 海量的用戶秒殺請求,本質(zhì)上是一個排序,先到先得.但是如此之多的請求，注定了有些人是搶不到的，可以在進(jìn)入上述偽代碼Dao層之前增加一個計數(shù)器進(jìn)行控制，比如有50%的流量將直接告訴其搶購失敗

總結(jié)

以上是生活随笔為你收集整理的库存系统架构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。