目前，京東到家?guī)齑嫦到y(tǒng)經(jīng)歷兩年多的線上考驗(yàn)與技術(shù)迭代，現(xiàn)服務(wù)著萬級(jí)商家十萬級(jí)店鋪的規(guī)模，需求的變更與技術(shù)演進(jìn)，我們是如何做到系統(tǒng)的穩(wěn)定性與高可用呢，下圖會(huì)給你揭曉答案(通過強(qiáng)大的基礎(chǔ)服務(wù)平臺(tái)讓應(yīng)用、JVM、Docker、物理機(jī)所有健康指標(biāo)一目了然，7*24小時(shí)智能監(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é)會(huì)跟進(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)還不是一個(gè)純技術(shù)的系統(tǒng)，需要結(jié)合用戶的行為特點(diǎn)來考慮，比如下文中提到什么時(shí)間進(jìn)行庫存的扣減最合適，我們先拋出幾個(gè)問題和大家一起探討下，如有有妥不處，歡迎大家拍磚。

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

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

舉個(gè)例子：

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

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

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

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

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

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

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

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

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

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

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

int ret=redis.incr(orderId); 
redis.expire(orderId,5,TimeUnit.MINUTES); 
if(ret==1){ 
    //添加成功，說明之前沒有處理過這個(gè)訂單號(hào)或者5分鐘之前處理過了 
    boolean alreadySuccess=alreadySuccessDoOrder(orderProductRequest); 
    if(!alreadySuccess){ 
        doOrder(orderProductRequest); 
    }else{ 
        return "操作失敗，原因：重復(fù)提交"; 
    } 
}else{ 
    return "操作失敗，原因：重復(fù)提交"; 
} 

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

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

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

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

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

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

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

現(xiàn)實(shí)中同一件商品可能會(huì)出現(xiàn)多人同時(shí)購買的情況，我們可以如何做到并發(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ì)思想是所有的請(qǐng)求過來之后首先加鎖，強(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ī)率會(huì)更高，那么數(shù)據(jù)庫的壓力會(huì)更高，這個(gè)時(shí)候還可以怎么做呢

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

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

public String doBuy(user,productId,productNum){ 
    //用戶除了***次進(jìn)入值為1，其它時(shí)候均大于1 
    int tmp=redis.incr(user.getUid()+productId);  
    if(tmp==1){ 
        //1小時(shí)后key自動(dòng)銷毀 
        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為允許每分鐘允許單個(gè)ip的***訪問次數(shù) 
    if(minuteIpCount>threshold){ 
        //識(shí)別到這部分潛在風(fēng)險(xiǎn)用戶時(shí)，會(huì)讓這部分用戶強(qiáng)制跳轉(zhuǎn)到驗(yàn)證碼頁面進(jìn)行校驗(yàn) 
        //校驗(yàn)通過后才能繼續(xù)搶購商品 
        return getAndSendVerificationCode(user); 
    }else{ 
        return doBuy2(user,productId,productNum); 
    } 
}