作者：京東物流 尹昊喆

前言

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

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

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

?

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

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

?

?

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

?

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

?

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

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

?

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

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

流量拆分

我們識(shí)別到，庫存流量有以下幾個(gè)特點(diǎn)：

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

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

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

?

基于流量的這些特點(diǎn)，我們對(duì)庫存流量拆分如下：

?

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

?

灰度鏈路

針對(duì)庫存操作流程復(fù)雜且改動(dòng)容易出錯(cuò)的情況，我們?cè)谶^往的上線過程中，通常會(huì)使用ducc編寫一個(gè)流程開關(guān)，逐步進(jìn)行灰度放量。

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

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

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

?

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

?

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

?

操作數(shù)量校驗(yàn)

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

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

?

?

數(shù)據(jù)庫熱點(diǎn)操作應(yīng)對(duì)

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

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

使用redis緩存解決熱點(diǎn)

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

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

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

?

?

?

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

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

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

?

解決數(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ù)一致性校驗(yàn)

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

?

增加緩存流水

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

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

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

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

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

異步限流

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

?

熱點(diǎn)檢測(cè)、限流

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

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

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

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

?

熱點(diǎn)限流告警示例：

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

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

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

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

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

?

前置動(dòng)作

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

2、從以上場(chǎng)景中又梳理出“殺傷力”最大的兩個(gè)計(jì)算場(chǎng)景分別是

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

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

優(yōu)化方案

CPU使用率治理

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

?

效果：

JSF服務(wù)治理

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

?

效果

優(yōu)化前：

優(yōu)化后

虛擬組套治理

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

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

計(jì)算示例：

?

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

優(yōu)化前：

優(yōu)化后：

?

未來規(guī)劃

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

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

?

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

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

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

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

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

審核編輯 黃宇