目前，京東到家庫存系統經歷兩年多的線上考驗與技術迭代，現服務著萬級商家十萬級店鋪的規模，需求的變更與技術演進，我們是如何做到系統的穩定性與高可用呢，下圖會給你揭曉答案(通過強大的基礎服務平臺讓應用、JVM、Docker、物理機所有健康指標一目了然，7*24小時智能監控告警讓開發無須一直盯著監控，另外數據與業務相輔相成，用數據驗證業務需求，迭代業務需求，讓業務需求都盡可能的收益***化，庫存系統的開發同學只需要關注業務需求，大版本上線前相應的測試同學會跟進幫你壓測，防止上線后潛在的性能瓶頸)。

附1：庫存系統技術架構圖

附2：庫存系統數據流轉圖

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

庫存什么時候進行預占(或者扣減)呢

商家銷售的商品數量是有限的，用戶下單后商品會被扣減，我們可以怎么實現呢?

舉個例子：

一件商品有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件就提示用戶無貨了，給商家造成無形的損失

可能出現重復提交訂單的情況：

• 用戶善意行為)app上用戶單擊“提交訂單”按鈕后由于后端接口沒有返回，用戶以為沒有操作成功會再次單擊“提交訂單”按鈕
• 用戶惡意行為)黑客直接刷提單接口，繞過App端防重提交功能
• 提單系統重試)比如提單系統為了提高系統的可用性，在***次調用庫存系統扣減接口超時后會重試再次提交扣減請求

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

• 用戶善意行為)app側在用戶***次單擊“提交訂單”按鈕后對按鈕進行置灰，禁止再次提交訂單
• 用戶惡意行為)采用令牌機制，用戶每次進入結算頁，提單系統會頒發一個令牌ID(全局唯一)，當用戶點擊“提交訂單”按鈕時發起的網絡請求中會帶上這個令牌ID,這個時候提單系統會優先進行令牌ID驗證，令牌ID存在&令牌ID訪問次數=1的話才會放行處理后續邏輯，否則直接返回
• 提單系統重試)這種情況則需要后端系統(比如庫存系統)來保證接口的冪等性，每次調用庫存系統時均帶上訂單號，庫存系統會基于訂單號增加一個分布式事務鎖，偽代碼如下：

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 "操作失敗，原因：重復提交"; 
} 

庫存數據的回滾機制如何做

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

• 用戶未支付)用戶下單后后悔了
• 用戶支付后取消)用戶下單&支付后后悔了
• 風控取消)風控識別到異常行為，強制取消訂單
• (耦合系統故障)比如提交訂單時提單系統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件商品，如何安全地庫存扣減

現實中同一件商品可能會出現多人同時購買的情況，我們可以如何做到并發安全呢?

偽代碼片段1：

synchronized(this){ 
    long stockNum = getProductStockNum(productId); 
    if(stockNum>requestBuyNum)  { 
      String sql=" update stock_main "+ 
                 " set stockNumstockNum=stockNum-"+requestBuyNum + 
                 " where productId="+productId; 
      int ret=updateSQL(sql); 
        if(ret==1){ 
            return "扣減成功"; 
        }else { 
            return "扣減失敗"; 
        } 
    } 
}    

偽代碼片段1的設計思想是所有的請求過來之后首先加鎖，強制其串行化處理，可見其效率一定不高，

偽代碼片段2：

String sql=" update stock_main "+ 
           " set stockNumstockNum=stockNum-"+requestBuyNum + 
           " where productId="+productId+ 
           " and stockNum>="+requestBuyNum; 
int ret=updateSQL(sql); 
if(ret==1){ 
   return "扣減成功"; 
}else { 
   return "扣減失敗"; 
} 

這段代碼只是在where條件里增加了and stockNum>="+requestBuyNum即可防止超賣的行為，達到了與上述偽代碼1的功能

如果商品是促銷品(比如參與了秒殺的商品)并發扣減的機率會更高，那么數據庫的壓力會更高，這個時候還可以怎么做呢

海量的用戶秒殺請求,本質上是一個排序,先到先得.但是如此之多的請求，注定了有些人是搶不到的，可以在進入上述偽代碼Dao層之前增加一個計數器進行控制，比如有50%的流量將直接告訴其搶購失敗，偽代碼如下：

public class SeckillServiceImpl{ 
    private long count=0; 
     
    public BuyResult buy(User user,int productId,int productNum){ 
        count++; 
        if(count%2=1){ 
            Thread.sleep(1000); 
            return new BuyResult("搶購失敗"); 
        }else{ 
            return doBuy(user,productId,productNum); 
        } 
    } 
} 

另外同一個用戶，不允許多次搶購同一件商品，我們又該如何做呢

public String doBuy(user,productId,productNum){ 
    //用戶除了***次進入值為1，其它時候均大于1 
    int tmp=redis.incr(user.getUid()+productId);  
    if(tmp==1){ 
        //1小時后key自動銷毀 
        redis.expire(user.getUid()+productId,3600);  
        return doBuy1(user,productId,productNum); 
    }else{ 
        return new BuyResult("搶購失敗"); 
    } 
} 

如果同一個用戶擁有不同的帳號，來搶購同一件商品，上面的策略就失效了。

一些公司在發展早期幾乎是沒有限制的，很容易就可以注冊很多個賬號。也即是網絡所謂的“僵尸賬號”，數量龐大，如果我們使用幾萬個“僵尸號”去混進去搶購，這樣就可以大大提升我們中獎的概率，那我們如何應對呢？

public String doBuy1(user,productId,productNum){ 
    String minuteKey=DateTimeUtil.getDateTimeStr("yyyyMMddHHmm"); 
    String minuteIpCount=redis.incr(minuteKey+user.getClientIp()); 
 
    // threshold為允許每分鐘允許單個ip的***訪問次數 
    if(minuteIpCount>threshold){ 
        //識別到這部分潛在風險用戶時，會讓這部分用戶強制跳轉到驗證碼頁面進行校驗 
        //校驗通過后才能繼續搶購商品 
        return getAndSendVerificationCode(user); 
    }else{ 
        return doBuy2(user,productId,productNum); 
    } 
} 

另外將庫存系統的核心表結構設計提供出來供大家參考

庫存主表，命名規則：stock_center_00~99

庫存流水表，命名規則：stock_center_flow_00~99

庫存批量操作日志表，命名規則：batch_upload_log

【本文是51CTO專欄作者張開濤的原創文章，作者微信公眾號：開濤的博客( kaitao-1234567)】

戳這里，看該作者更多好文