vivo全球商城：庫存系統(tǒng)架構(gòu)設(shè)計與實(shí)踐
一、業(yè)務(wù)背景
庫存系統(tǒng)是電商商品管理的核心系統(tǒng)，本文主要介紹vivo商城庫存中心發(fā)展歷程、架構(gòu)設(shè)計思路及應(yīng)對各種業(yè)務(wù)場景的實(shí)踐。
vivo商城原庫存系統(tǒng)耦合在商品系統(tǒng)，考慮到相關(guān)業(yè)務(wù)邏輯復(fù)雜度越來越高，庫存做了服務(wù)拆分，在可售庫存管理的基礎(chǔ)上新增了實(shí)物庫存管理、秒殺庫存、物流時效 、發(fā)貨限制、分倉管理等功能，滿足了商城庫存相關(guān)業(yè)務(wù)需求。
本文將介紹vivo商城庫存系統(tǒng)架構(gòu)設(shè)計經(jīng)驗以及一些問題的解決方案。
二、系統(tǒng)架構(gòu)設(shè)計
2.1 vivo大電商庫存架構(gòu)
根據(jù)vivo大電商的銷售渠道與業(yè)務(wù)場景可以將庫存業(yè)務(wù)架構(gòu)分為3個層級：倉庫層、調(diào)度層以及銷售層。
倉庫層對應(yīng)實(shí)體倉庫，包括自營倉庫、順豐倉等第三方倉庫以及WMS系統(tǒng)、ERP系統(tǒng)等；調(diào)度層負(fù)責(zé)庫存調(diào)度與訂單發(fā)貨管理；銷售層包含多個服務(wù)終端，vivo官方商城、vivo門店、第三方電商分銷渠道等。其分層結(jié)構(gòu)如圖所示：
本文探討的vivo官方商城庫存架構(gòu)設(shè)計，從整個vivo大電商庫存架構(gòu)來看，vivo官方商城庫存系統(tǒng)涉及銷售層內(nèi)部架構(gòu)以及銷售層與調(diào)度層的交互。
2.2 商城庫存系統(tǒng)架構(gòu)演變
早期商城的庫存冗余在各業(yè)務(wù)系統(tǒng)中，如可售庫存在商品系統(tǒng)、活動庫存在營銷系統(tǒng)等，庫存流轉(zhuǎn)也只有扣減與釋放，無法針對庫存進(jìn)行整合與業(yè)務(wù)創(chuàng)新，存在諸多限制：
- 不能進(jìn)行精細(xì)化管理，庫存未分層，無法針對實(shí)物庫存、分倉策略、活動庫存進(jìn)行精細(xì)化管理。
- 沒有分倉策略，無法提前獲取商品收發(fā)地址，物流時效無法估算。
- 無法針對地區(qū)、商品等進(jìn)行發(fā)貨管控。
- 實(shí)時性差，無法及時同步實(shí)物庫存以及分倉策略。
- 性能弱，與其他系統(tǒng)耦合大，不能靈活擴(kuò)展。
基于上述限制與產(chǎn)品期望，21年庫存系統(tǒng)完成初版架構(gòu)設(shè)計，此后系統(tǒng)不斷迭代完善，形成當(dāng)前的系統(tǒng)架構(gòu)：
庫存系統(tǒng)提供兩個核心能力：交易能力和庫存管理。上層業(yè)務(wù)方可以調(diào)用提供的API完成庫存查詢、庫存扣減等操作；管理臺可以按成分倉策略、庫存同步等操作。
三、系統(tǒng)業(yè)務(wù)架構(gòu)
3.1 庫存類型&分倉管理
3.1.1 庫存類型結(jié)構(gòu)
庫存系統(tǒng)一共包含4類庫存：可售庫存、實(shí)物庫存、預(yù)占庫存、活動庫存。
- 可售庫存：運(yùn)營配置的普通商品庫存，商品維度到SKU。
- 實(shí)物庫存：由倉儲系統(tǒng)同步到庫存系統(tǒng)的實(shí)物庫存，細(xì)化到具體倉庫。
- 預(yù)占庫存：用戶下單完成庫存預(yù)占，倉儲系統(tǒng)發(fā)貨后釋放預(yù)占庫存，預(yù)占庫存可以監(jiān)控已下單未發(fā)貨庫存量。
- 活動庫存：用于秒殺、搶購等各類營銷活動的商品庫存。
基于不同類型庫存，可以構(gòu)建一個簡單的庫存分層體系：
3.1.2 分倉管理
庫存中心還維護(hù)了倉庫信息、分倉策略、倉庫實(shí)物庫存信息等等：
- 倉庫信息：倉庫基礎(chǔ)信息，包括倉庫地址、類型、編碼等。
- 分倉策略：倉庫功能信息，倉庫可發(fā)貨區(qū)域、無實(shí)物庫存后的備選倉庫；訂單根據(jù)收貨地址對應(yīng)優(yōu)先發(fā)貨的倉庫，爭取盡快發(fā)貨盡早到貨。
- 倉庫庫存：倉庫實(shí)物庫存，由倉庫調(diào)度系統(tǒng)同步到商城庫存系統(tǒng)。
3.2 商城庫存流轉(zhuǎn)方案
商品庫存流轉(zhuǎn)涉及兩個主要操作：正向庫存扣減、逆向庫存回退，整套庫存變更流程如下：
3.2.1 正向庫存扣減流程
對于庫存扣減，目前常見有兩種庫存扣減方案：
（1）下單時扣庫存。
- 優(yōu)點(diǎn)是：實(shí)時扣庫存，避免付款時因庫存不足而阻斷影響用戶體驗。
- 缺點(diǎn)是：庫存有限的情況下，惡意下單占庫存影響其他正常用戶下單。比如說有100臺手機(jī)，如果沒有限制下單數(shù)量，這100個庫存可能被一個用戶惡意占用，導(dǎo)致其他用戶無法購買。
（2）支付時扣庫存。
- 優(yōu)點(diǎn)是：不受惡意下單影響。
- 缺點(diǎn)是：當(dāng)支付訂單數(shù)大于實(shí)際庫存，會阻斷部分用戶支付，影響購物體驗。比如說只有100臺手機(jī)，但可能下了1000個訂單，但有900個訂單在支付時無法購買。
從用戶體驗考慮，我們采用的是下單時扣庫存 + 回退這種方案。
下單時扣減庫存，但只保留一段時間（比如15分鐘），保留時間段內(nèi)未支付則釋放庫存，避免長時間占用庫存。
3.2.2 逆向庫存回退流程
庫存回退基于庫存變更日志逐個回退。
庫存回退基本流程：訂單出庫前用戶申請退款，回退可售庫存、回退預(yù)占庫存、軟刪除扣減日志、增加回退日志；一旦商品出庫，用戶申請退貨走處理機(jī)流程，可售庫存和實(shí)物庫存均不回退。
3.3 精細(xì)化發(fā)貨管控
庫存系統(tǒng)還提供了一系列定制輔助功能：分倉策略、發(fā)貨限制、物流時效等等。
（1）分倉策略
為了給用戶更快的發(fā)貨，我們采用的是分倉策略，即由最近的倉庫（存在優(yōu)先級）給用戶發(fā)貨；同時存在備選倉庫，當(dāng)所有倉庫無實(shí)物庫存時可走備選倉庫。
3.3.1 發(fā)貨限制
發(fā)貨限制分地區(qū)限制時間限制。
- 地區(qū)限制：根據(jù)收貨地址批量設(shè)置部分區(qū)域無法發(fā)貨等規(guī)則，粒度到省市區(qū)維度。
- 時間限制：倉庫的發(fā)貨時效管理，包括每天的發(fā)貨時段、大促發(fā)貨時段、以及特殊情況下的停發(fā)時段。
3.3.2 物流時效預(yù)估
根據(jù)用戶收貨地址，基于分倉策略確定發(fā)貨地址，再基于發(fā)貨時效確定發(fā)貨時間，提升用戶體驗。
四、系統(tǒng)架構(gòu)技術(shù)要點(diǎn)
4.1 庫存扣減防重
訂單重復(fù)提交會導(dǎo)致庫存重復(fù)扣減，比如用戶誤提交、系統(tǒng)超時重試等，針對此類問題有如下常見解決方案：
- 訂單提交按鈕單擊置灰，避免重復(fù)提交。
注：對于按鈕置灰這種方案，可以減少用戶誤觸重復(fù)提交的可能性，但不能從根本上解決庫存被重復(fù)扣減的問題，比如通過腳本來刷扣減庫存的接口，依舊造成庫存的重復(fù)扣減。 - 保證庫存扣減接口的冪等性。
注：保證接口冪等的方案有很多，比如每次扣減庫存時，帶上唯一的流水號，利用數(shù)據(jù)庫的唯一索引保證冪等等。 - 采用令牌機(jī)制。用戶提交訂單會進(jìn)行令牌校驗，校驗通過才能提交訂單。
注：這種方案保證每次提交的訂單是唯一的，如果用戶多次下單，那么會產(chǎn)生多個訂單。
本系統(tǒng)采用的是保證接口冪等性的方案。
在庫存扣減接口入?yún)⒅性黾佑唵涡蛄刑栕鳛槲ㄒ粯?biāo)識，庫存扣減時增加一條扣減日志。當(dāng)接口重復(fù)請求時，會優(yōu)先校驗是否已經(jīng)存在扣減記錄，如果已存在則直接返回，避免重復(fù)扣減問題，具體流程如下：
4.2 防超賣與高并發(fā)扣減方案
4.2.1 常規(guī)渠道防超賣方案
常規(guī)下單渠道流量小且對超賣風(fēng)險厭惡度極高，常用的防超賣方案有：
方案一：
直接數(shù)據(jù)庫扣減。通過sql判斷剩余庫存是否大于等于待扣庫存，滿足則扣減庫存。該方案利用樂觀鎖原理即update的排他性確保事務(wù)性，避免超賣。
偽代碼sql：
該方案的優(yōu)點(diǎn)是：
- 實(shí)庫實(shí)扣，不會出現(xiàn)超賣；
- 數(shù)據(jù)庫樂觀鎖保證并發(fā)扣減一致性；
- 數(shù)據(jù)庫事務(wù)保證批量扣減正常回滾。
該方案的缺點(diǎn)是：
- 行級鎖的原因存在性能瓶頸，高并發(fā)會出現(xiàn)請求堵塞超時問題；
- 直連數(shù)據(jù)庫，每次扣庫存都是寫操作，接口性能較低。
方案二：
利用分布式鎖，強(qiáng)制串行化扣減同一商品庫存。
該方案的優(yōu)點(diǎn)是：
減輕數(shù)據(jù)庫壓力，同時還能確保不會超賣。
該方案的缺點(diǎn)是：
每次只能有一個請求搶占鎖，不能應(yīng)對高并發(fā)場景。
對于常規(guī)渠道，庫存扣減是后置邏輯，流量不高，我們采用的是直接數(shù)據(jù)庫扣減，且針對弊端做了一些措施：
- 前置校驗嚴(yán)格，同時針對刷單場景會有嚴(yán)格限流，保證最終扣減庫存的流量可控；
- 庫存系統(tǒng)讀寫分離，減少數(shù)據(jù)庫的壓力。
4.2.2 高并發(fā)庫存扣減方案
針對高并發(fā)庫存扣減，比如秒殺，一般采用的是緩存扣減庫存的方式（redis+lua腳本實(shí)現(xiàn)單線程庫存更新）作為前置流程，代替數(shù)據(jù)庫直接更新。
在redis中扣減庫存雖然性能高，可以大大減輕數(shù)據(jù)庫壓力，但需要保證緩存數(shù)據(jù)能完整、正確的入庫，以保證最終一致性。
針對緩存數(shù)據(jù)更新至數(shù)據(jù)庫，目前主流方案有兩種：
方案一：Redis數(shù)據(jù)直接異步更新至數(shù)據(jù)庫。
優(yōu)點(diǎn)：簡單、沒有復(fù)雜的流程。
缺陷：redis宕機(jī)或者故障，可能會造成緩存內(nèi)庫存數(shù)據(jù)的丟失。
方案二：Redis扣減庫存時，同步在業(yè)務(wù)數(shù)據(jù)中insert庫存信息。
這里大家可能會有兩個疑問：
- 有數(shù)據(jù)庫的插入操作，性能怎么保證？
- 有數(shù)據(jù)庫的操作，又有redis的更新，事務(wù)性怎么保證？
- 異步更新業(yè)務(wù)庫存在延遲，庫存逆向回退如何保證？
對于疑問1：由于數(shù)據(jù)庫insert比update性能優(yōu)，insert是在表的末尾直接插入，沒有尋址的過程，可以保證性能比較快。
對于疑問2：方案2不同于緩存直接扣減，而是把緩存扣減放在數(shù)據(jù)庫insert的事務(wù)內(nèi)，通過數(shù)據(jù)庫的事務(wù)保證整體的事務(wù)。
insert的表被稱為庫存任務(wù)表，其中保存了庫存扣減的信息，庫存任務(wù)表結(jié)構(gòu)可以設(shè)計的非常簡單，主鍵 + 庫存信息（json字符串）就可以了。
后續(xù)通過異步任務(wù)，從庫存任務(wù)表表中查詢出庫存更新信息，將其同步到具體的庫存表中，實(shí)現(xiàn)最終一致性，這種方案可以避免數(shù)據(jù)的丟失。
對于疑問3：庫存回退是根據(jù)業(yè)務(wù)庫中扣減記錄進(jìn)行回退的，由于異步更新業(yè)務(wù)庫必定存在延遲（延遲極低，數(shù)秒以內(nèi)），所以極端場景會存在走退款逆向流程時業(yè)務(wù)庫的庫存扣減記錄還未更新。
針對這種情況庫存回退設(shè)置延遲重試機(jī)制，如果再極端點(diǎn)達(dá)到重試閾值依舊沒有扣減記錄，則返回回退成功，不做阻斷。
目前我們針對秒殺庫存扣減，采用的是方案2。但畢竟涉及數(shù)據(jù)庫的更新，為了避免風(fēng)險，在前置流量校驗上做了限制，保證流量的可控：
4.2.3 庫存熱點(diǎn)問題
什么是熱點(diǎn)問題？熱點(diǎn)問題就是因熱點(diǎn)商品導(dǎo)致的redis、數(shù)據(jù)庫等性能瓶頸。在庫存系統(tǒng)中，熱點(diǎn)問題主要存在：
- 采用直接扣減庫存數(shù)據(jù)庫的方式，存在數(shù)據(jù)庫的行鎖問題。常規(guī)渠道的庫存扣減，我們采用的就是的就是這種方式。
- 采用緩存扣減庫存的方式，大流量的情況下，熱點(diǎn)商品扣減庫存操作會打向redis單片，造成單片性能抖動，從而出現(xiàn)redis性能瓶頸。
對于第1種熱點(diǎn)問題，在vivo商城常見的場景是：新發(fā)的爆品手機(jī)，在準(zhǔn)點(diǎn)售賣時會有搶購效應(yīng)，容易造成庫存數(shù)據(jù)庫單行的瓶頸問題。針對這種熱點(diǎn)問題，我們的解決方案是“分而治之”：
對于潛在的熱點(diǎn)爆款手機(jī)，我們會將庫存平均分為多行（比如M行），扣減庫存時，隨機(jī)在M行中選取一行庫存數(shù)據(jù)進(jìn)行扣減。該方案突破了數(shù)據(jù)庫單行鎖的瓶頸限制，解決了爆款商品的熱點(diǎn)問題。
對于第2種redis單片熱點(diǎn)問題，解決方案也是分而治之。將數(shù)據(jù)庫中的庫存數(shù)據(jù)同步到redis時，把key值打散，分散在多個redis單片中。注：我們目前線上的流量峰值還達(dá)不到會造成redis單片瓶頸的問題，為避免過度設(shè)計，只做了前置限流，沒有進(jìn)行key值的打散。
4.3 庫存同步方案
庫存系統(tǒng)存在一些庫存同步場景：
- 對接倉儲系統(tǒng)，完成實(shí)物庫存同步。
- 兼容歷史架構(gòu)，商品系統(tǒng)庫存的可售庫存同步等。
（1）實(shí)物庫存同步：
實(shí)物庫存同步，對接的是倉儲系統(tǒng)，通過接口來獲取商品的實(shí)際庫存。實(shí)物庫存同步分成兩種：定時全量同步、指定單品更新。
- 定時全量同步：每天定時全量拉取庫存調(diào)度平臺的實(shí)物庫存進(jìn)行全量同步。
- 制定單品：運(yùn)營也可以手動觸發(fā)單個sku的商品即時同步實(shí)物庫存。
（2）商品系統(tǒng)庫存同步：
由于庫存系統(tǒng)多個場景涉及庫存變更，運(yùn)營手動編輯、用戶下單退款導(dǎo)致庫存扣減回退，還有商品系統(tǒng)內(nèi)編輯庫存數(shù)據(jù)也會導(dǎo)致庫存變更（以前庫存系統(tǒng)未獨(dú)立，庫存數(shù)據(jù)維護(hù)在商品系統(tǒng)）。同時很多業(yè)務(wù)在查詢庫存時，參考的依舊是商品系統(tǒng)的庫存數(shù)據(jù)。
這里有一個問題：庫存系統(tǒng)已經(jīng)獨(dú)立出來，為什么還會依賴商品系統(tǒng)的庫存數(shù)據(jù)？
這有兩點(diǎn)原因：
- 商城多個業(yè)務(wù)的后臺有商品篩選的需要，商品篩選會有庫存數(shù)量的篩選項。商品數(shù)量很多，篩選是分頁的，如果將庫存數(shù)據(jù)全部替換成庫存系統(tǒng)的，那么存在跨系統(tǒng)分頁問題，分頁篩選會存在問題；
- 歷史遺留問題，很多業(yè)務(wù)方依賴的是商品系統(tǒng)的庫存數(shù)據(jù)（包括依賴商品庫存離線表的業(yè)務(wù)方），全部切換到庫存系統(tǒng)，成本和影響范圍大。
因此，我們需要保證商品系統(tǒng)和庫存系統(tǒng)兩邊庫存數(shù)據(jù)的一致。
庫存變更場景多，為了降低業(yè)務(wù)復(fù)雜度、采用簡單的方式實(shí)現(xiàn)庫存同步，我們利用了團(tuán)隊自研的CDC系統(tǒng)（魯班平臺），整體流程如下：
庫存數(shù)據(jù)庫發(fā)生變更后，魯班平臺通過binlog采集獲取庫存變更日志，再通過自定義規(guī)則篩選，然后發(fā)送mq變更消息，最后商品系統(tǒng)消費(fèi)消息完成庫存同步變更。
五、總結(jié)及展望
最后對庫存系統(tǒng)進(jìn)行一個總結(jié)：
庫存系統(tǒng)完成服務(wù)拆分，在單一的可售庫存扣減功能基礎(chǔ)上拓展了很多功能，賦能業(yè)務(wù)的發(fā)展。
完成庫存架構(gòu)分層，抽象多個庫存類型，更靈活地滿足當(dāng)前業(yè)務(wù)需求。
針對庫存扣減防重、高并發(fā)場景下的庫存扣減、庫存熱點(diǎn)問題、庫存同步等技術(shù)問題，我們根據(jù)業(yè)務(wù)實(shí)際情況設(shè)計合理方案。
展望
目前vivo商城庫存系統(tǒng)平臺化能力不足，部分能力分散在其他系統(tǒng)中，未來我們希望能為vivo新零售提供一體化的庫存管理方案。
