作者：京東物流 尹昊喆

前言

本文總結(jié)庫存平臺穩(wěn)定性建設(shè)中遇到的問題以及解決方案。感謝【金鵬】、【孫靜】、【陳瑞】同學(xué)在本文撰寫中提供的內(nèi)容及幫助！

庫存平臺面臨的穩(wěn)定性挑戰(zhàn)

庫存平臺為貨品流通鏈路提供全面的庫存管理服務(wù)，貫穿其整個訂單生命周期，是電商領(lǐng)域不可或缺的核心模塊。在平臺建設(shè)過程中，我們面臨了諸多穩(wěn)定性方面的挑戰(zhàn)。

?

具體而言，存在以下問題：

1、業(yè)務(wù)流程繁多，不同流程共同訪問同一應(yīng)用，容易相互影響。例如，銷售單庫存預(yù)占功能出現(xiàn)問題時，退供預(yù)占功能亦隨之失效。

?

?

2、業(yè)務(wù)流程復(fù)雜，修改易出錯。銷售單預(yù)占等流程，流程分支多、步驟多，新入職的員工需要至少一周的時間才能理解這些流程。對如此復(fù)雜的流程進行修改極易導(dǎo)致錯誤。

?

3、庫存數(shù)據(jù)的準(zhǔn)確性要求極高。一旦某一貨品的庫存信息出現(xiàn)錯誤，可能導(dǎo)致該貨品后續(xù)的訂單都無法正常下單或無法履約。

?

4、數(shù)據(jù)庫熱點操作帶來的穩(wěn)定性威脅。秒殺活動、直播促銷等業(yè)務(wù)場景，往往會出現(xiàn)短時間內(nèi)多個訂單都去預(yù)占某一個或幾個商品庫存的情況。多個線程并發(fā)對同一個數(shù)據(jù)庫商品數(shù)據(jù)做庫存扣減時，數(shù)據(jù)庫中會加鎖來保障數(shù)據(jù)被正確操作。當(dāng)商品數(shù)據(jù)足夠【熱】時，大量的鎖等待會引發(fā)性能問題，進而導(dǎo)致系統(tǒng)不可用，見下圖：

5、店鋪庫存高頻、大規(guī)模計算帶來的穩(wěn)定性威脅。一個商家的庫存發(fā)生變動后，需要把商家?guī)齑嬷匦路峙浣o商家名下的各個店鋪，這個分配過程計算量極大，容易把CPU打滿，進而影響所有服務(wù)

?

庫存平臺穩(wěn)定性建設(shè)

為了應(yīng)對庫存平臺所面臨的穩(wěn)定性挑戰(zhàn)，除了通用的可用率可視化、限流等治理措施外，我們還結(jié)合庫存業(yè)務(wù)的特點，采取了以下穩(wěn)定性建設(shè)。

流量拆分

我們識別到，庫存流量有以下幾個特點：

1、存在必須要重點保障的核心流量。銷售單庫存預(yù)占能力屬于物流核心流程，其目的是為京東物流倉配業(yè)務(wù)提供出庫單庫存校驗服務(wù)，從而避免訂單量超出庫存容量而錯誤地傳遞到倉庫管理系統(tǒng)（WMS）中，在接單鏈路中若庫存操作失敗則訂單接單失敗，造成公司大量的財產(chǎn)損失

2、存在一些計算量大又不需要實時處理的流量。如WMS出庫以后，需要回傳庫存出庫情況，這部分流量很高，但對處理實時性要求不高

3、存在一些明細(xì)行特別多的庫存批量操作。以銷售單庫存預(yù)占為例，絕大部分庫存操作批量大小在10個以內(nèi)，但是也存在部分批量大小超過6000的情況。不同的批量大小，調(diào)用方需要有不同的超時配置，如批量大小在10個以內(nèi)，超時時間配置為500毫秒；批量大小大于6000時，超時時間需要配置為50秒

?

基于流量的這些特點，我們對庫存流量拆分如下：

?

注：流量拆分使用不同的服務(wù)分組實現(xiàn)

?

灰度鏈路

針對庫存操作流程復(fù)雜且改動容易出錯的情況，我們在過往的上線過程中，通常會使用ducc編寫一個流程開關(guān)，逐步進行灰度放量。

然而，這種做法存在兩個主要問題：

1、維護成本較高。需求經(jīng)過驗證后，仍需再次上線以移除不再使用的開關(guān)，但往往因疏忽而未能及時下線，導(dǎo)致代碼中充斥著冗余的開關(guān)，邏輯變得混亂。

2、容易引發(fā)線上問題。大型需求的改動點通常較多，需要在多個地方添加開關(guān)，稍有不慎便可能遺漏，從而導(dǎo)致線上問題頻發(fā)。

?

我們識別到，庫存業(yè)務(wù)通常在一個商家范圍內(nèi)進行。因此，庫存操作的核心接口均包含以商家為單位的參數(shù)。在進行灰度驗證時，可以按商家單位進行灰度切量?；谶@一特性，庫存系統(tǒng)構(gòu)建了以商家為基礎(chǔ)的灰度鏈路。

?

相較于以往的灰度方法，灰度鏈路無需在每次需求變更時增加流程控制代碼，從而降低了線上出現(xiàn)問題的概率。

?

操作數(shù)量校驗

對于某一貨品的庫存操作，將變更一條或多條庫存記錄。例如，在依據(jù)渠道優(yōu)先級進行出庫操作時，將優(yōu)先扣減京東渠道的庫存，再扣減共享渠道的庫存。當(dāng)某一貨品的操作涉及多條庫存記錄時，需為每條庫存記錄分配相應(yīng)的操作數(shù)量。操作完成后，應(yīng)為每條記錄生成變更記錄流水。

針對這個業(yè)務(wù)現(xiàn)狀，我們進行了庫存流水加和校驗：

?

?

數(shù)據(jù)庫熱點操作應(yīng)對

當(dāng)商家出售爆款商品時，會頻繁扣減特定庫存記錄。在操作數(shù)據(jù)庫的過程中，數(shù)據(jù)庫會對庫存記錄進行加鎖，并按順序執(zhí)行這些扣減操作。這導(dǎo)致容器中積累了大量等待的線程和數(shù)據(jù)庫連接，一方面可能導(dǎo)致服務(wù)請求超時，另一方面，大量占用容器資源可能引發(fā)容器宕機，進而影響其他商品的庫存操作。

倘若采取粗暴的限流措施，將導(dǎo)致大量庫存扣減失敗，并且連非熱門商品也會受到波及，造成不良影響。

使用redis緩存解決熱點

我們的初版的解決方案是在緩存中添加庫存數(shù)據(jù)，利用緩存的高效性能來應(yīng)對熱點問題。我們按商家的粒度逐步在灰度鏈路中進行流量切換，具體如下圖所示。：

通過此項優(yōu)化，成功將熱點商品預(yù)占TPS從50提升到1200，提升了24倍。TP99降低到130ms，降低至原時長的4.3%（從3000ms到130ms）。

橙色部分為優(yōu)化后的結(jié)果：

?

?

?

在切量過程中，我們發(fā)現(xiàn)了兩個問題：

1、數(shù)據(jù)庫與Redis數(shù)據(jù)存在不一致的情況。由于某些業(yè)務(wù)場景考慮不周全，導(dǎo)致數(shù)據(jù)庫與Redis數(shù)據(jù)出現(xiàn)不一致，而這些問題往往需要通過商家或下游的反饋才能被發(fā)現(xiàn)并修復(fù)。

2、部分關(guān)鍵客戶商家難以進行灰度切量。一些大型關(guān)鍵客戶商家在處理庫存時，存在定制化的特殊處理邏輯，使用緩存來支撐這些邏輯的成本較高且容易出錯。

?

解決數(shù)據(jù)庫與Redis數(shù)據(jù)不一致問題方案

從操作流程上保障數(shù)據(jù)庫與redis一致

操作流程上面臨的主要技術(shù)問題如下圖：

?初始化流程方案。使用 鎖定db庫存+redis事務(wù)來保障數(shù)據(jù)一致性。見下圖：

?數(shù)據(jù)同步流程。使用mq重試+任務(wù)系統(tǒng)兜底來保障同步能完成

數(shù)據(jù)庫、redis數(shù)據(jù)一致性校驗

庫存平臺每日執(zhí)行數(shù)百萬次庫存操作，如何在不影響系統(tǒng)性能的同時及時發(fā)現(xiàn)數(shù)據(jù)不一致的情況，是一個需要仔細(xì)權(quán)衡的問題。我們采取了以下解決方案：

?

增加緩存流水

當(dāng)發(fā)現(xiàn)有數(shù)據(jù)庫-redis數(shù)據(jù)不一致時，我們需要有數(shù)據(jù)來協(xié)助我們定位不一致問題發(fā)生的原因，所以在es中增加了redis緩存操作的流水記錄，如下圖：

數(shù)據(jù)庫、redis數(shù)據(jù)查詢、操作管理能力

我們開發(fā)了管理頁面，支持以商家、貨品、單據(jù)等維度來查詢并操作數(shù)據(jù)庫、redis數(shù)據(jù)，界面如下圖：

解決關(guān)鍵客戶商家難以使用redis緩存問題

一些大型關(guān)鍵客戶商家在處理庫存時，存在大量定制化的邏輯，在緩存中實現(xiàn)一次不僅成本高，還容易出現(xiàn)錯漏。針對這部分商家，我們采用了以下治理思路。

異步限流

設(shè)計思路：讓熱點不那么熱。通過減緩預(yù)占操作速度，從而降低熱點熱度，緩解庫存系統(tǒng)的性能壓力。見下圖：

?

熱點檢測、限流

設(shè)計思路：及時識別熱點庫存，對熱點庫存實施流量控制，從而確保系統(tǒng)的穩(wěn)定性。

流量控制采用滑動窗口算法。實現(xiàn)原理：每當(dāng)經(jīng)過一個時間點，時間窗口即向前推進一個單位，計算該窗口內(nèi)的請求數(shù)量。若請求數(shù)量超出預(yù)設(shè)限制，則拒絕處理請求；反之，則予以處理。

具體實現(xiàn)使用AOP切面編程，流程如下圖：

注：限流流程在try-catch中執(zhí)行，中間除了【被限流異?！浚瑒e的異常都捕獲吞掉，防止影響正常邏輯

?

熱點限流告警示例：

店鋪庫存穩(wěn)定性建設(shè)

商家通過入駐京倉來管理其線上與線下銷售渠道的庫存。京倉是一個綜合性的倉儲管理系統(tǒng)，它幫助商家有效地整合和管理其庫存資源。商家可以在京東POP店、京東自營VMI、唯品會、淘天、抖音、快手等線上平臺以及線下門店進行銷售。這種多渠道銷售模式不僅擴大了商家的市場覆蓋面，還提高了銷售效率。

為了防止超賣現(xiàn)象，商家需要確保線上與線下庫存的共享。這意味著商家必須實時更新庫存數(shù)據(jù)，確保所有銷售渠道都能看到最新的庫存信息。通過這種方式，商家可以避免因庫存信息不同步而導(dǎo)致的超賣問題，從而提升客戶滿意度和信任度。例如，如果一個商品在線上被售出，系統(tǒng)會立即更新庫存信息，確保線下門店不會再次銷售同一商品。

目前，已有75,821家商家入駐京倉，店鋪數(shù)量達到162,306家，實物1,785萬件，明細(xì)行數(shù)為9,309萬條。這些數(shù)據(jù)表明，京倉已經(jīng)成為眾多商家管理庫存的重要平臺。

隨著商家接入量、計算場景的增加，系統(tǒng)計算量也隨之增大，常常使得容器CPU和數(shù)據(jù)庫CPU的負(fù)載過高，進而影響整個系統(tǒng)的穩(wěn)定性且都是后知后覺，無法提前控量。當(dāng)容器CPU的負(fù)載過高時，會導(dǎo)致對外提供的JSF服務(wù)的可用率降低。這不僅影響了用戶體驗，還可能導(dǎo)致商家的業(yè)務(wù)受到影響，為了保持系統(tǒng)的穩(wěn)定性和性能，需要對系統(tǒng)進行優(yōu)化和升級，同時加強監(jiān)控和維護，確保系統(tǒng)能夠高效地運行。

?

前置動作

1、梳理出所有觸發(fā)計算的場景共25個觸發(fā)點庫存變化、低于安全水位、調(diào)整商品比例、調(diào)整店鋪維度比例、虛擬組套修改、固定值設(shè)置等。

2、從以上場景中又梳理出“殺傷力”最大的兩個計算場景分別是

店鋪比例調(diào)整：整個事業(yè)部下的所有SKU全量計算。

虛擬組套計算：由于虛擬組套規(guī)則的特殊性，單次計算會生成1.5W+條計算流水。

優(yōu)化方案

CPU使用率治理

我們對店鋪維度比例調(diào)整場景，進行了提前發(fā)現(xiàn)并對該事業(yè)部進行提前限流，有效的解決了流量一下全打到應(yīng)用服務(wù)器，導(dǎo)致CPU飆升的場景

?

效果：

JSF服務(wù)治理

通過日常OPS Review發(fā)現(xiàn)，當(dāng)計算任務(wù)量激增時，整個系統(tǒng)的資源會被大量占用，導(dǎo)致對外服務(wù)響應(yīng)時間變長，甚至出現(xiàn)服務(wù)中斷的情況。為了改善這一狀況，我們決定將計算功能和JSF功能進行分組隔離。這樣，計算任務(wù)和用戶界面操作可以分別在獨立的資源池中運行，互不影響。

?

效果

優(yōu)化前：

優(yōu)化后

虛擬組套治理

虛擬組套專為京倉來源的訂單設(shè)計，通過在ECLP中配置虛擬組套關(guān)系，實現(xiàn)JD商城下單時為一個套裝SKU，而ECLP接單及WMS出庫時則按原料SKU出庫的功能,給商家?guī)砹烁`活的銷售策略。

例如，組套SKU=1*原料1(20%)+2*原料2(20%)+1*原料3(20%)。通過組套關(guān)系可以看出，組套SKU的庫存量來源于原料。在進行組套計算時，需先根據(jù)店鋪維度比例或EMG分配比例計算出原料庫存，再依據(jù)組套規(guī)則分配給組套SKU，需進行二次計算。實際應(yīng)用中，每個原料可以共享給多個組套，整個綁定關(guān)系呈現(xiàn)網(wǎng)狀結(jié)構(gòu)，單次計算量會成倍增加(1W+)，占用更多計算資源，從而影響其他非組套商家的計算。

計算示例：

?

通過以上計算MQ拆分，并通過JMQ4進行限流，可以做到平滑計算，不會再出現(xiàn)重算量激增導(dǎo)致CPU一下打滿情況。

優(yōu)化前：

優(yōu)化后：

?

未來規(guī)劃

補充業(yè)務(wù)監(jiān)控告警

當(dāng)前庫存平臺的監(jiān)控告警主要集中在接口層面，然而，接口的成功返回并不完全意味著業(yè)務(wù)處理已正常完成并落庫。因此，我們計劃引入更為全面的數(shù)據(jù)維度監(jiān)控告警機制，以確保業(yè)務(wù)處理的完整性和準(zhǔn)確性。

?

監(jiān)控策略：以小時數(shù)據(jù)為單位進行對比，例如將2月28日9:00至10:00期間的預(yù)占成功與回傳成功數(shù)量，與2月21日同一時間段的數(shù)據(jù)進行對比。當(dāng)差異比例超過預(yù)設(shè)閾值時，觸發(fā)告警。

告警觸發(fā)條件：定時觸發(fā)，每小時的第五分鐘執(zhí)行一次，例如在10:05觸發(fā)，對比9:00至10:00的數(shù)據(jù)。

數(shù)據(jù)來源：通過查詢ES或大數(shù)據(jù)平臺進行對比，以避免對線上核心業(yè)務(wù)造成影響。

數(shù)據(jù)庫-redis不一致比對工具

當(dāng)前接收到數(shù)據(jù)庫與Redis不一致的告警后，我們采取人工查詢數(shù)據(jù)庫流水及Redis流水并進行比對的方式，以查找不一致的原因。由于一個貨品在特定時間段內(nèi)的流水記錄可能極為繁多，這一比對過程耗時且費力。為此，我們計劃開發(fā)一款不一致比對工具，實現(xiàn)自動化分析不一致的原因，并輸出導(dǎo)致不一致的具體單據(jù)。

審核編輯 黃宇