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

附1：庫存系統(tǒng)技術(shù)架構(gòu)圖

附2：庫存系統(tǒng)數(shù)據(jù)流轉(zhuǎn)圖

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

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

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

舉個例子：

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

• (實(shí)現(xiàn)方案1)如果用戶加入購物車時進(jìn)行庫存預(yù)占，那么將只能有1個用戶將1000個商品加入購物車。
• (實(shí)現(xiàn)方案2)如果用戶提交訂單時進(jìn)行庫存預(yù)占，那么將也只能有1個用戶將1000個商品提單成功，其它的人均提示“庫存不足，提單失敗”。
• (實(shí)現(xiàn)方案3)如果用戶提交訂單&支付成功時進(jìn)行庫存預(yù)占，那么這1000個人都能生成訂單，但是只有1個人可以支付成功，其它的訂單均會被自動取消。

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

• 用戶可能只是暫時加入購物車，并不表示用戶最終會提單并支付。
• 所以在購物車進(jìn)行庫存校驗(yàn)并預(yù)占，會造成其它真正想買的用戶不能加入購物車的情況，但是之前加車的用戶一直不付款，最終損失的是公司。
• 方案3會造成生成1000個訂單，無論是在支付前校驗(yàn)庫存還是在支付成功后再檢驗(yàn)庫存，都會造成用戶準(zhǔn)備好支付條件后卻會出現(xiàn)99.9%的系統(tǒng)取消訂單的概率，也就是說會給99.9%的用戶體驗(yàn)到不爽的感覺。
• 數(shù)據(jù)表明用戶提交訂單不支付的占比是非常小的(相對于加入購物車不購買的行為)，目前京東到家給用戶預(yù)留的最長支付時間是30分鐘，超過30分鐘訂單自動取消，預(yù)占的庫存自動釋放

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

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

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

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

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

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

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

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 "操作失敗，原因：重復(fù)提交"; 
    } 
}else{ 
    return "操作失敗，原因：重復(fù)提交"; 
} 

庫存數(shù)據(jù)的回滾機(jī)制如何做

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

• 用戶未支付)用戶下單后后悔了
• 用戶支付后取消)用戶下單&支付后后悔了
• 風(fēng)控取消)風(fēng)控識別到異常行為，強(qiáng)制取消訂單
• (耦合系統(tǒng)故障)比如提交訂單時提單系統(tǒng)T1同時會調(diào)用積分扣減系統(tǒng)X1、庫存扣減系統(tǒng)X2、優(yōu)惠券系統(tǒng)X3，假如X1,X2成功后，調(diào)用X3失敗，需要回滾用戶積分與商家?guī)齑妗?/li>

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

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

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

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

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

偽代碼片段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的設(shè)計(jì)思想是所有的請求過來之后首先加鎖，強(qiáng)制其串行化處理，可見其效率一定不高，

偽代碼片段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即可防止超賣的行為，達(dá)到了與上述偽代碼1的功能

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

海量的用戶秒殺請求,本質(zhì)上是一個排序,先到先得.但是如此之多的請求，注定了有些人是搶不到的，可以在進(jìn)入上述偽代碼Dao層之前增加一個計(jì)數(shù)器進(jìn)行控制，比如有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); 
        } 
    } 
} 

另外同一個用戶，不允許多次搶購?fù)患唐罚覀冇衷撊绾巫瞿?/strong>

public String doBuy(user,productId,productNum){ 
    //用戶除了***次進(jìn)入值為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的***訪問次數(shù) 
    if(minuteIpCount>threshold){ 
        //識別到這部分潛在風(fēng)險用戶時，會讓這部分用戶強(qiáng)制跳轉(zhuǎn)到驗(yàn)證碼頁面進(jìn)行校驗(yàn) 
        //校驗(yàn)通過后才能繼續(xù)搶購商品 
        return getAndSendVerificationCode(user); 
    }else{ 
        return doBuy2(user,productId,productNum); 
    } 
}