## 京東到家庫存系統架構設計 https://tech.imdada.cn/2017/08/23/daojia-inventory-system/ 發表于2017-08-23? | ? 分類于[京東到家](https://tech.imdada.cn/categories/%E4%BA%AC%E4%B8%9C%E5%88%B0%E5%AE%B6/)，[架構](https://tech.imdada.cn/categories/%E4%BA%AC%E4%B8%9C%E5%88%B0%E5%AE%B6/%E6%9E%B6%E6%9E%84/) # [](https://tech.imdada.cn/2017/08/23/daojia-inventory-system/#u4EAC_u4E1C_u5230_u5BB6_u5E93_u5B58_u7CFB_u7EDF_u67B6_u6784_u8BBE_u8BA1 "京東到家庫存系統架構設計")京東到家庫存系統架構設計 > 目前，京東到家庫存系統經歷兩年多的線上考驗與技術迭代，現服務著萬級商家十萬級店鋪的規模，需求的變更與技術演進，我們是如何做到系統的穩定性與高可用呢，下圖會給你揭曉答案（通過強大的基礎服務平臺讓應用、JVM、Docker、物理機所有健康指標一目了然，7\*24小時智能監控告警讓開發無須一直盯著監控，另外數據與業務相輔相成，用數據驗證業務需求，迭代業務需求，讓業務需求都盡可能的收益最大化，庫存系統的開發同學只需要關注業務需求，大版本上線前相應的測試同學會跟進幫你壓測，防止上線后潛在的性能瓶頸）。 附1：庫存系統技術架構圖 [](http://img.blog.csdn.net/20170821141229602) 附2：庫存系統數據流轉圖 [](http://img.blog.csdn.net/20170821140525407) > 庫存系統的架構很有意思，從上圖來看功能上其實并不復雜，但是他面臨的技術復雜度卻是相當高的，比如秒殺品在高并發的情況下如何防止超賣，另外庫存系統還不是一個純技術的系統，需要結合用戶的行為特點來考慮，比如下文中提到什么時間進行庫存的扣減最合適，我們先拋出幾個問題和大家一起探討下，如有有妥不處，歡迎大家拍磚。 ## [](https://tech.imdada.cn/2017/08/23/daojia-inventory-system/#u5E93_u5B58_u4EC0_u4E48_u65F6_u5019_u8FDB_u884C_u9884_u5360_28_u6216_u8005_u6263_u51CF_29_u5462 "庫存什么時候進行預占(或者扣減)呢")庫存什么時候進行預占(或者扣減)呢 > 商家銷售的商品數量是有限的，用戶下單后商品會被扣減，我們可以怎么實現呢？ **舉個例子：** **一件商品有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無疑是折中的最好方案。 ## [](https://tech.imdada.cn/2017/08/23/daojia-inventory-system/#u91CD_u590D_u63D0_u4EA4_u8BA2_u5355_u7684_u95EE_u9898_uFF1F "重復提交訂單的問題？")重復提交訂單的問題？ > 重復提交訂單造成的庫存重復扣減的后果是比較嚴重的。比如商家設置有1000件商品，而實際情況可能賣了900件就提示用戶無貨了，給商家造成無形的損失 **可能出現重復提交訂單的情況：** * （1、用戶善意行為）app上用戶單擊“提交訂單”按鈕后由于后端接口沒有返回，用戶以為沒有操作成功會再次單擊“提交訂單”按鈕 * （2、用戶惡意行為）黑客直接刷提單接口，繞過App端防重提交功能 * （3、提單系統重試）比如提單系統為了提高系統的可用性，在第一次調用庫存系統扣減接口超時后會重試再次提交扣減請求 **好了，既然問題根源縷清楚了，我們一一對癥下藥** * （1、用戶善意行為）app側在用戶第一次單擊“提交訂單”按鈕后對按鈕進行置灰，禁止再次提交訂單 * （2、用戶惡意行為）采用令牌機制，用戶每次進入結算頁，提單系統會頒發一個令牌ID（全局唯一），當用戶點擊“提交訂單”按鈕時發起的網絡請求中會帶上這個令牌ID,這個時候提單系統會優先進行令牌ID驗證，令牌ID存在&令牌ID訪問次數=1的話才會放行處理后續邏輯，否則直接返回 * （3、提單系統重試）這種情況則需要后端系統（比如庫存系統）來保證接口的冪等性，每次調用庫存系統時均帶上訂單號，庫存系統會基于訂單號增加一個分布式事務鎖，偽代碼如下： ```java int ret=redis.incr(orderId); redis.expire(orderId,5,TimeUnit.MINUTES); if(ret==1){//添加成功，說明之前沒有處理過這個訂單號或者5分鐘之前處理過了 boolean alreadySuccess=alreadySuccessDoOrder(orderProductRequest); if(!alreadySuccess){ doOrder(orderProductRequest); }else{ return "操作失敗，原因：重復提交"; } }else{ return "操作失敗，原因：重復提交"; } ``` ## [](https://tech.imdada.cn/2017/08/23/daojia-inventory-system/#u5E93_u5B58_u6570_u636E_u7684_u56DE_u6EDA_u673A_u5236_u5982_u4F55_u505A "庫存數據的回滾機制如何做")庫存數據的回滾機制如何做 **需要庫存回滾的場景也是比較多的，比如：** * （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一定要大于容忍用戶的支付時間）前的訂單，調用訂單中心查詢訂單的狀態，確保不是已取消的，否則進行自我數據的回滾。 ## [](https://tech.imdada.cn/2017/08/23/daojia-inventory-system/#u591A_u4EBA_u540C_u65F6_u8D2D_u4E701_u4EF6_u5546_u54C1_uFF0C_u5982_u4F55_u5B89_u5168_u5730_u5E93_u5B58_u6263_u51CF "多人同時購買1件商品，如何安全地庫存扣減")多人同時購買1件商品，如何安全地庫存扣減 > 現實中同一件商品可能會出現多人同時購買的情況，我們可以如何做到并發安全呢？ 偽代碼片段1： ```java synchronized(this){ long stockNum = getProductStockNum(productId); if(stockNum>requestBuyNum) { int ret=updateSQL("update stock_main set stockNum=stockNum-"+requestBuyNum +" where productId="+productId); if(ret==1){ return "扣減成功"; }else { return "扣減失敗"; } } } ``` 偽代碼片段1的設計思想是所有的請求過來之后首先加鎖，強制其串行化處理，可見其效率一定不高， 偽代碼片段2： ```java int ret=updateSQL("update stock_main set stockNum=stockNum-"+requestBuyNum +" where productId="+productId+" and stockNum>="+requestBuyNum ); if(ret==1){ return "扣減成功"; }else { return "扣減失敗"; } ``` 這段代碼只是在where條件里增加了and stockNum>=”+requestBuyNum即可防止超賣的行為，達到了與上述偽代碼1的功能 如果商品是促銷品（比如參與了秒殺的商品）并發扣減的機率會更高，那么數據庫的壓力會更高，這個時候還可以怎么做呢 海量的用戶秒殺請求,本質上是一個排序,先到先得.但是如此之多的請求，注定了有些人是搶不到的，可以在進入上述偽代碼Dao層之前增加一個計數器進行控制，比如有50%的流量將直接告訴其搶購失敗，偽代碼如下： ```java public class SeckillServiceImpl{ private long count=0; public String buy(User user,int productId,int productNum){ count++; if(count%2=1){ Thread.sleep(1000); return "搶購失敗"; }else{ return doBuy(user,productId,productNum); } } } ``` 另外同一個用戶，不允許多次搶購同一件商品，我們又該如何做呢 ```java public String doBuy(user,productId,productNum){ //用戶除了第一次進入值為1，其它時候均大于1 int tmp=redis.incr(user.getUid()+productId); if(tmp==1){ redis.expire(user.getUid()+productId,3600); //1小時后key自動銷毀 doBuy1(user,productId,productNum); }else{ return "搶購失敗"; } } ``` > 怎么樣，看了上述的介紹是不是覺得庫存系統很有意思，而且總會有你意想不到的高并發問題等你來日挑戰，當然了，也非常歡迎你加入我們（目前北京、上海均在招Java高級工程師，可以加微信【北京的同學加***lzc\_java***，上海的同學加***25252937***】進一步了解職位詳情，等你來約） ------------- ~~~ updateSQL("update stock_main set stockNum=stockNum-"+requestBuyNum +" where productId="+productId+" and stockNum>="+requestBuyNum ); ~~~ `stockNum>="+requestBuyNum` 這里做樂觀鎖條件更好，不一定要用版本號，因為本次只關心有庫存就行，不需要關系數據版本有沒有被人更新。（哪怕再簡單的細節，也有可以優化和琢磨的地方）