<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                企業??AI智能體構建引擎,智能編排和調試,一鍵部署,支持知識庫和私有化部署方案 廣告
                ## 京東到家庫存系統架構設計 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:庫存系統技術架構圖 [![附1:庫存系統技術架構圖](http://img.blog.csdn.net/20170821141229602)](http://img.blog.csdn.net/20170821141229602) 附2:庫存系統數據流轉圖 [![附2:庫存系統數據流轉圖](http://img.blog.csdn.net/20170821140525407)](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&gt;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` 這里做樂觀鎖條件更好,不一定要用版本號,因為本次只關心有庫存就行,不需要關系數據版本有沒有被人更新。(哪怕再簡單的細節,也有可以優化和琢磨的地方)
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看