## 京東到家庫存系統架構設計
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` 這里做樂觀鎖條件更好,不一定要用版本號,因為本次只關心有庫存就行,不需要關系數據版本有沒有被人更新。(哪怕再簡單的細節,也有可以優化和琢磨的地方)
- 開始
- 公益
- 更好的使用看云
- 推薦書單
- 優秀資源整理
- 技術文章寫作規范
- SublimeText - 編碼利器
- PSR-0/PSR-4命名標準
- php的多進程實驗分析
- 高級PHP
- 進程
- 信號
- 事件
- IO模型
- 同步、異步
- socket
- Swoole
- PHP擴展
- Composer
- easyswoole
- php多線程
- 守護程序
- 文件鎖
- s-socket
- aphp
- 隊列&并發
- 隊列
- 講個故事
- 如何最大效率的問題
- 訪問式的web服務(一)
- 訪問式的web服務(二)
- 請求
- 瀏覽器訪問阻塞問題
- Swoole
- 你必須理解的計算機核心概念 - 碼農翻身
- CPU阿甘 - 碼農翻身
- 異步通知,那我要怎么通知你啊?
- 實時操作系統
- 深入實時 Linux
- Redis 實現隊列
- redis與隊列
- 定時-時鐘-阻塞
- 計算機的生命
- 多進程/多線程
- 進程通信
- 拜占庭將軍問題深入探討
- JAVA CAS原理深度分析
- 隊列的思考
- 走進并發的世界
- 鎖
- 事務筆記
- 并發問題帶來的后果
- 為什么說樂觀鎖是安全的
- 內存鎖與內存事務 - 劉小兵2014
- 加鎖還是不加鎖,這是一個問題 - 碼農翻身
- 編程世界的那把鎖 - 碼農翻身
- 如何保證萬無一失
- 傳統事務與柔性事務
- 大白話搞懂什么是同步/異步/阻塞/非阻塞
- redis實現鎖
- 淺談mysql事務
- PHP異常
- php錯誤
- 文件加載
- 路由與偽靜態
- URL模式之分析
- 字符串處理
- 正則表達式
- 數組合并與+
- 文件上傳
- 常用驗證與過濾
- 記錄
- 趣圖
- foreach需要注意的問題
- Discuz!筆記
- 程序設計思維
- 抽象與具體
- 配置
- 關于如何學習的思考
- 編程思維
- 談編程
- 如何安全的修改對象
- 臨時
- 臨時筆記
- 透過問題看本質
- 程序后門
- 邊界檢查
- session
- 安全
- 王垠
- 第三方數據接口
- 驗證碼問題
- 還是少不了虛擬機
- 程序員如何談戀愛
- 程序員為什么要一直改BUG,為什么不能一次性把代碼寫好?
- 碎碎念
- 算法
- 實用代碼
- 相對私密與絕對私密
- 學習目標
- 隨記
- 編程小知識
- foo
- 落盤
- URL編碼的思考
- 字符編碼
- Elasticsearch
- TCP-IP協議
- 碎碎念2
- Grafana
- EFK、ELK
- RPC
- 依賴注入
- 科目一
- 開發筆記
- 經緯度格式轉換
- php時區問題
- 解決本地開發時調用遠程AIP跨域問題
- 后期靜態綁定
- 談tp的跳轉提示頁面
- 無限分類問題
- 生成微縮圖
- MVC名詞
- MVC架構
- 也許模塊不是唯一的答案
- 哈希算法
- 開發后臺
- 軟件設計架構
- mysql表字段設計
- 上傳表如何設計
- 二開心得
- awesomes-tables
- 安全的代碼部署
- 微信開發筆記
- 賬戶授權相關
- 小程序獲取是否關注其公眾號
- 支付相關
- 提交訂單
- 微信支付筆記
- 支付接口筆記
- 支付中心開發
- 下單與支付
- 支付流程設計
- 訂單與支付設計
- 敏感操作驗證
- 排序設計
- 代碼的運行環境
- 搜索關鍵字的顯示處理
- 接口異步更新ip信息
- 圖片處理
- 項目搭建
- 閱讀文檔的新方式
- mysql_insert_id并發問題思考
- 行鎖注意事項
- 細節注意
- 如何處理用戶的輸入
- 不可見的字符
- 抽獎
- 時間處理
- 應用開發實戰
- python 學習記錄
- Scrapy 教程
- Playwright 教程
- stealth.min.js
- Selenium 教程
- requests 教程
- pyautogui 教程
- Flask 教程
- PyInstaller 教程
- 蜘蛛
- python 文檔相似度驗證
- thinkphp5.0數據庫與模型的研究
- workerman進程管理
- workerman網絡分析
- java學習記錄
- docker
- 筆記
- kubernetes
- Kubernetes
- PaddlePaddle
- composer
- oneinstack
- 人工智能 AI
- 京東
- pc_detailpage_wareBusiness
- doc
- 電商網站設計
- iwebshop
- 商品規格分析
- 商品屬性分析
- tpshop
- 商品規格分析
- 商品屬性分析
- 電商表設計
- 設計記錄
- 優惠券
- 生成唯一訂單號
- 購物車技術
- 分類與類型
- 微信登錄與綁定
- 京東到家庫存系統架構設計
- crmeb
- 命名規范
- Nginx https配置
- 關于人工智能
- 從人的思考方式到二叉樹
- 架構
- 今日有感
- 文章保存
- 安全背后: 瀏覽器是如何校驗證書的
- 避不開的分布式事務
- devops自動化運維、部署、測試的最后一公里 —— ApiFox 云時代的接口管理工具
- 找到自己今生要做的事
- 自動化生活
- 開源與漿果
- Apifox: API 接口自動化測試指南