這是一個(gè)或許對(duì)你有用的開(kāi)源項(xiàng)目

國(guó)產(chǎn) Star 破 10w+ 的開(kāi)源項(xiàng)目，前端包括管理后臺(tái) + 微信小程序，后端支持單體和微服務(wù)架構(gòu)。

功能涵蓋 RBAC 權(quán)限、SaaS 多租戶(hù)、數(shù)據(jù)權(quán)限、商城、支付、工作流、大屏報(bào)表、微信公眾號(hào)等等功能：

一、業(yè)務(wù)背景

庫(kù)存系統(tǒng)是電商商品管理的核心系統(tǒng)，本文主要介紹vivo商城庫(kù)存中心發(fā)展歷程、架構(gòu)設(shè)計(jì)思路及應(yīng)對(duì)各種業(yè)務(wù)場(chǎng)景的實(shí)踐。

vivo商城原庫(kù)存系統(tǒng)耦合在商品系統(tǒng)，考慮到相關(guān)業(yè)務(wù)邏輯復(fù)雜度越來(lái)越高，庫(kù)存做了服務(wù)拆分，在可售庫(kù)存管理的基礎(chǔ)上新增了實(shí)物庫(kù)存管理、秒殺庫(kù)存、物流時(shí)效 、發(fā)貨限制、分倉(cāng)管理等功能，滿(mǎn)足了商城庫(kù)存相關(guān)業(yè)務(wù)需求。

本文將介紹vivo商城庫(kù)存系統(tǒng)架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)以及一些問(wèn)題的解決方案。

二、系統(tǒng)架構(gòu)設(shè)計(jì)

2.1 vivo大電商庫(kù)存架構(gòu)

根據(jù)vivo大電商的銷(xiāo)售渠道與業(yè)務(wù)場(chǎng)景可以將庫(kù)存業(yè)務(wù)架構(gòu)分為3個(gè)層級(jí)：倉(cāng)庫(kù)層、調(diào)度層以及銷(xiāo)售層。

倉(cāng)庫(kù)層對(duì)應(yīng)實(shí)體倉(cāng)庫(kù)，包括自營(yíng)倉(cāng)庫(kù)、順豐倉(cāng)等第三方倉(cāng)庫(kù)以及WMS系統(tǒng)、ERP系統(tǒng)等；調(diào)度層負(fù)責(zé)庫(kù)存調(diào)度與訂單發(fā)貨管理；銷(xiāo)售層包含多個(gè)服務(wù)終端，vivo官方商城、vivo門(mén)店、第三方電商分銷(xiāo)渠道等。其分層結(jié)構(gòu)如圖所示：

本文探討的vivo官方商城庫(kù)存架構(gòu)設(shè)計(jì)，從整個(gè)vivo大電商庫(kù)存架構(gòu)來(lái)看，vivo官方商城庫(kù)存系統(tǒng)涉及銷(xiāo)售層內(nèi)部架構(gòu)以及銷(xiāo)售層與調(diào)度層的交互。

2.2 商城庫(kù)存系統(tǒng)架構(gòu)演變

早期商城的庫(kù)存冗余在各業(yè)務(wù)系統(tǒng)中，如可售庫(kù)存在商品系統(tǒng)、活動(dòng)庫(kù)存在營(yíng)銷(xiāo)系統(tǒng)等，庫(kù)存流轉(zhuǎn)也只有扣減與釋放，無(wú)法針對(duì)庫(kù)存進(jìn)行整合與業(yè)務(wù)創(chuàng)新，存在諸多限制：

不能進(jìn)行精細(xì)化管理，庫(kù)存未分層，無(wú)法針對(duì)實(shí)物庫(kù)存、分倉(cāng)策略、活動(dòng)庫(kù)存進(jìn)行精細(xì)化管理。

沒(méi)有分倉(cāng)策略，無(wú)法提前獲取商品收發(fā)地址，物流時(shí)效無(wú)法估算。

無(wú)法針對(duì)地區(qū)、商品等進(jìn)行發(fā)貨管控。

實(shí)時(shí)性差，無(wú)法及時(shí)同步實(shí)物庫(kù)存以及分倉(cāng)策略。

性能弱，與其他系統(tǒng)耦合大，不能靈活擴(kuò)展。

基于上述限制與產(chǎn)品期望，21年庫(kù)存系統(tǒng)完成初版架構(gòu)設(shè)計(jì)，此后系統(tǒng)不斷迭代完善，形成當(dāng)前的系統(tǒng)架構(gòu)：

庫(kù)存系統(tǒng)提供兩個(gè)核心能力：交易能力和庫(kù)存管理。上層業(yè)務(wù)方可以調(diào)用提供的API完成庫(kù)存查詢(xún)、庫(kù)存扣減等操作；管理臺(tái)可以按成分倉(cāng)策略、庫(kù)存同步等操作。

三、系統(tǒng)業(yè)務(wù)架構(gòu)

3.1 庫(kù)存類(lèi)型&分倉(cāng)管理

3.1.1 庫(kù)存類(lèi)型結(jié)構(gòu)

庫(kù)存系統(tǒng)一共包含4類(lèi)庫(kù)存：可售庫(kù)存、實(shí)物庫(kù)存、預(yù)占庫(kù)存、活動(dòng)庫(kù)存。

可售庫(kù)存： 運(yùn)營(yíng)配置的普通商品庫(kù)存，商品維度到SKU。

實(shí)物庫(kù)存： 由倉(cāng)儲(chǔ)系統(tǒng)同步到庫(kù)存系統(tǒng)的實(shí)物庫(kù)存，細(xì)化到具體倉(cāng)庫(kù)。

預(yù)占庫(kù)存： 用戶(hù)下單完成庫(kù)存預(yù)占，倉(cāng)儲(chǔ)系統(tǒng)發(fā)貨后釋放預(yù)占庫(kù)存，預(yù)占庫(kù)存可以監(jiān)控已下單未發(fā)貨庫(kù)存量。

活動(dòng)庫(kù)存： 用于秒殺、搶購(gòu)等各類(lèi)營(yíng)銷(xiāo)活動(dòng)的商品庫(kù)存。

基于不同類(lèi)型庫(kù)存，可以構(gòu)建一個(gè)簡(jiǎn)單的庫(kù)存分層體系：

3.1.2 分倉(cāng)管理

庫(kù)存中心還維護(hù)了倉(cāng)庫(kù)信息、分倉(cāng)策略、倉(cāng)庫(kù)實(shí)物庫(kù)存信息等等：

倉(cāng)庫(kù)信息： 倉(cāng)庫(kù)基礎(chǔ)信息，包括倉(cāng)庫(kù)地址、類(lèi)型、編碼等。

分倉(cāng)策略： 倉(cāng)庫(kù)功能信息，倉(cāng)庫(kù)可發(fā)貨區(qū)域、無(wú)實(shí)物庫(kù)存后的備選倉(cāng)庫(kù)；訂單根據(jù)收貨地址對(duì)應(yīng)優(yōu)先發(fā)貨的倉(cāng)庫(kù)，爭(zhēng)取盡快發(fā)貨盡早到貨。

倉(cāng)庫(kù)庫(kù)存： 倉(cāng)庫(kù)實(shí)物庫(kù)存，由倉(cāng)庫(kù)調(diào)度系統(tǒng)同步到商城庫(kù)存系統(tǒng)。

3.2 商城庫(kù)存流轉(zhuǎn)方案

商品庫(kù)存流轉(zhuǎn)涉及兩個(gè)主要操作：正向庫(kù)存扣減、逆向庫(kù)存回退，整套庫(kù)存變更流程如下：

3.2.1 正向庫(kù)存扣減流程

對(duì)于庫(kù)存扣減，目前常見(jiàn)有兩種庫(kù)存扣減方案：

（1）下單時(shí)扣庫(kù)存。

優(yōu)點(diǎn)是： 實(shí)時(shí)扣庫(kù)存，避免付款時(shí)因庫(kù)存不足而阻斷影響用戶(hù)體驗(yàn)。

缺點(diǎn)是： 庫(kù)存有限的情況下，惡意下單占庫(kù)存影響其他正常用戶(hù)下單。比如說(shuō)有100臺(tái)手機(jī)，如果沒(méi)有限制下單數(shù)量，這100個(gè)庫(kù)存可能被一個(gè)用戶(hù)惡意占用，導(dǎo)致其他用戶(hù)無(wú)法購(gòu)買(mǎi)。

（2）支付時(shí)扣庫(kù)存。

優(yōu)點(diǎn)是： 不受惡意下單影響。

缺點(diǎn)是： 當(dāng)支付訂單數(shù)大于實(shí)際庫(kù)存，會(huì)阻斷部分用戶(hù)支付，影響購(gòu)物體驗(yàn)。比如說(shuō)只有100臺(tái)手機(jī)，但可能下了1000個(gè)訂單，但有900個(gè)訂單在支付時(shí)無(wú)法購(gòu)買(mǎi)。

從用戶(hù)體驗(yàn)考慮，我們采用的是下單時(shí)扣庫(kù)存 + 回退這種方案。

下單時(shí)扣減庫(kù)存，但只保留一段時(shí)間（比如15分鐘），保留時(shí)間段內(nèi)未支付則釋放庫(kù)存，避免長(zhǎng)時(shí)間占用庫(kù)存。

3.2.2 逆向庫(kù)存回退流程

庫(kù)存回退基于庫(kù)存變更日志逐個(gè)回退。

庫(kù)存回退基本流程：訂單出庫(kù)前用戶(hù)申請(qǐng)退款，回退可售庫(kù)存、回退預(yù)占庫(kù)存、軟刪除扣減日志、增加回退日志；一旦商品出庫(kù)，用戶(hù)申請(qǐng)退貨走處理機(jī)流程，可售庫(kù)存和實(shí)物庫(kù)存均不回退。

3.3 精細(xì)化發(fā)貨管控

庫(kù)存系統(tǒng)還提供了一系列定制輔助功能：分倉(cāng)策略、發(fā)貨限制、物流時(shí)效等等。

（1）分倉(cāng)策略

為了給用戶(hù)更快的發(fā)貨，我們采用的是分倉(cāng)策略，即由最近的倉(cāng)庫(kù)（存在優(yōu)先級(jí)）給用戶(hù)發(fā)貨；同時(shí)存在備選倉(cāng)庫(kù)，當(dāng)所有倉(cāng)庫(kù)無(wú)實(shí)物庫(kù)存時(shí)可走備選倉(cāng)庫(kù)。

3.3.1 發(fā)貨限制

發(fā)貨限制分地區(qū)限制時(shí)間限制。

地區(qū)限制： 根據(jù)收貨地址批量設(shè)置部分區(qū)域無(wú)法發(fā)貨等規(guī)則，粒度到省市區(qū)維度。

時(shí)間限制： 倉(cāng)庫(kù)的發(fā)貨時(shí)效管理，包括每天的發(fā)貨時(shí)段、大促發(fā)貨時(shí)段、以及特殊情況下的停發(fā)時(shí)段。

3.3.2 物流時(shí)效預(yù)估

根據(jù)用戶(hù)收貨地址，基于分倉(cāng)策略確定發(fā)貨地址，再基于發(fā)貨時(shí)效確定發(fā)貨時(shí)間，提升用戶(hù)體驗(yàn)。

四、系統(tǒng)架構(gòu)技術(shù)要點(diǎn)

4.1 庫(kù)存扣減防重

訂單重復(fù)提交會(huì)導(dǎo)致庫(kù)存重復(fù)扣減，比如用戶(hù)誤提交、系統(tǒng)超時(shí)重試等，針對(duì)此類(lèi)問(wèn)題有如下常見(jiàn)解決方案：

訂單提交按鈕單擊置灰，避免重復(fù)提交。

注：對(duì)于按鈕置灰這種方案，可以減少用戶(hù)誤觸重復(fù)提交的可能性，但不能從根本上解決庫(kù)存被重復(fù)扣減的問(wèn)題，比如通過(guò)腳本來(lái)刷扣減庫(kù)存的接口，依舊造成庫(kù)存的重復(fù)扣減。

保證庫(kù)存扣減接口的冪等性。

注：保證接口冪等的方案有很多，比如每次扣減庫(kù)存時(shí)，帶上唯一的流水號(hào)，利用數(shù)據(jù)庫(kù)的唯一索引保證冪等等。

采用令牌機(jī)制。用戶(hù)提交訂單會(huì)進(jìn)行令牌校驗(yàn)，校驗(yàn)通過(guò)才能提交訂單。

注：這種方案保證每次提交的訂單是唯一的，如果用戶(hù)多次下單，那么會(huì)產(chǎn)生多個(gè)訂單。

本系統(tǒng)采用的是保證接口冪等性的方案。

在庫(kù)存扣減接口入?yún)⒅性黾佑唵涡蛄刑?hào)作為唯一標(biāo)識(shí)，庫(kù)存扣減時(shí)增加一條扣減日志。當(dāng)接口重復(fù)請(qǐng)求時(shí)，會(huì)優(yōu)先校驗(yàn)是否已經(jīng)存在扣減記錄，如果已存在則直接返回，避免重復(fù)扣減問(wèn)題，具體流程如下：

4.2 防超賣(mài)與高并發(fā)扣減方案

4.2.1 常規(guī)渠道防超賣(mài)方案

常規(guī)下單渠道流量小且對(duì)超賣(mài)風(fēng)險(xiǎn)厭惡度極高，常用的防超賣(mài)方案有：

方案一：

直接數(shù)據(jù)庫(kù)扣減。通過(guò)sql判斷剩余庫(kù)存是否大于等于待扣庫(kù)存，滿(mǎn)足則扣減庫(kù)存。該方案利用樂(lè)觀鎖原理即update的排他性確保事務(wù)性，避免超賣(mài)。

偽代碼sql：

sql：update store set store = store -?#{deductStore } where (store-#{deductStore })?>=?0

該方案的優(yōu)點(diǎn) 是：

實(shí)庫(kù)實(shí)扣，不會(huì)出現(xiàn)超賣(mài)；

數(shù)據(jù)庫(kù)樂(lè)觀鎖保證并發(fā)扣減一致性；

數(shù)據(jù)庫(kù)事務(wù)保證批量扣減正常回滾。

該方案的缺點(diǎn) 是：

行級(jí)鎖的原因存在性能瓶頸，高并發(fā)會(huì)出現(xiàn)請(qǐng)求堵塞超時(shí)問(wèn)題；

直連數(shù)據(jù)庫(kù)，每次扣庫(kù)存都是寫(xiě)操作，接口性能較低。

方案二：

利用分布式鎖，強(qiáng)制串行化扣減同一商品庫(kù)存。

該方案的優(yōu)點(diǎn) 是：

減輕數(shù)據(jù)庫(kù)壓力，同時(shí)還能確保不會(huì)超賣(mài)。

該方案的缺點(diǎn) 是：

每次只能有一個(gè)請(qǐng)求搶占鎖，不能應(yīng)對(duì)高并發(fā)場(chǎng)景。

對(duì)于常規(guī)渠道，庫(kù)存扣減是后置邏輯，流量不高，我們采用的是直接數(shù)據(jù)庫(kù)扣減，且針對(duì)弊端做了一些措施 ：

前置校驗(yàn)嚴(yán)格，同時(shí)針對(duì)刷單場(chǎng)景會(huì)有嚴(yán)格限流，保證最終扣減庫(kù)存的流量可控；

庫(kù)存系統(tǒng)讀寫(xiě)分離，減少數(shù)據(jù)庫(kù)的壓力。

4.2.2 高并發(fā)庫(kù)存扣減方案

針對(duì)高并發(fā)庫(kù)存扣減，比如秒殺，一般采用的是緩存扣減庫(kù)存的方式（redis+lua腳本實(shí)現(xiàn)單線(xiàn)程庫(kù)存更新）作為前置流程，代替數(shù)據(jù)庫(kù)直接更新。

在redis中扣減庫(kù)存雖然性能高，可以大大減輕數(shù)據(jù)庫(kù)壓力，但需要保證緩存數(shù)據(jù)能完整、正確的入庫(kù)，以保證最終一致性。

針對(duì)緩存數(shù)據(jù)更新至數(shù)據(jù)庫(kù)，目前主流方案有兩種：

方案一：Redis數(shù)據(jù)直接異步更新至數(shù)據(jù)庫(kù)。

優(yōu)點(diǎn) ：簡(jiǎn)單、沒(méi)有復(fù)雜的流程。

缺陷： redis宕機(jī)或者故障，可能會(huì)造成緩存內(nèi)庫(kù)存數(shù)據(jù)的丟失。

方案二：Redis扣減庫(kù)存時(shí)，同步在業(yè)務(wù)數(shù)據(jù)中insert庫(kù)存信息。

這里大家可能會(huì)有兩個(gè)疑問(wèn)：

有數(shù)據(jù)庫(kù)的插入操作，性能怎么保證？

有數(shù)據(jù)庫(kù)的操作，又有redis的更新，事務(wù)性怎么保證？

異步更新業(yè)務(wù)庫(kù)存在延遲，庫(kù)存逆向回退如何保證？

對(duì)于疑問(wèn)1： 由于數(shù)據(jù)庫(kù)insert比update性能優(yōu)，insert是在表的末尾直接插入，沒(méi)有尋址的過(guò)程，可以保證性能比較快。

對(duì)于疑問(wèn)2： 方案2不同于緩存直接扣減，而是把緩存扣減放在數(shù)據(jù)庫(kù)insert的事務(wù)內(nèi)，通過(guò)數(shù)據(jù)庫(kù)的事務(wù)保證整體的事務(wù)。

insert的表被稱(chēng)為庫(kù)存任務(wù)表，其中保存了庫(kù)存扣減的信息，庫(kù)存任務(wù)表結(jié)構(gòu)可以設(shè)計(jì)的非常簡(jiǎn)單，主鍵 + 庫(kù)存信息（json字符串）就可以了。

后續(xù)通過(guò)異步任務(wù)，從庫(kù)存任務(wù)表表中查詢(xún)出庫(kù)存更新信息，將其同步到具體的庫(kù)存表中，實(shí)現(xiàn)最終一致性，這種方案可以避免數(shù)據(jù)的丟失。

對(duì)于疑問(wèn)3： 庫(kù)存回退是根據(jù)業(yè)務(wù)庫(kù)中扣減記錄進(jìn)行回退的，由于異步更新業(yè)務(wù)庫(kù)必定存在延遲（延遲極低，數(shù)秒以?xún)?nèi)），所以極端場(chǎng)景會(huì)存在走退款逆向流程時(shí)業(yè)務(wù)庫(kù)的庫(kù)存扣減記錄還未更新。

針對(duì)這種情況庫(kù)存回退設(shè)置延遲重試機(jī)制，如果再極端點(diǎn)達(dá)到重試閾值依舊沒(méi)有扣減記錄，則返回回退成功，不做阻斷。

目前我們針對(duì)秒殺庫(kù)存扣減，采用的是方案2。但畢竟涉及數(shù)據(jù)庫(kù)的更新，為了避免風(fēng)險(xiǎn)，在前置流量校驗(yàn)上做了限制，保證流量的可控：

4.2.3 庫(kù)存熱點(diǎn)問(wèn)題

什么是熱點(diǎn)問(wèn)題？熱點(diǎn)問(wèn)題就是因熱點(diǎn)商品導(dǎo)致的redis、數(shù)據(jù)庫(kù)等性能瓶頸。在庫(kù)存系統(tǒng)中，熱點(diǎn)問(wèn)題主要存在 ：

采用直接扣減庫(kù)存數(shù)據(jù)庫(kù) 的方式，存在數(shù)據(jù)庫(kù)的行鎖問(wèn)題。常規(guī)渠道的庫(kù)存扣減，我們采用的就是的就是這種方式。

采用緩存扣減庫(kù)存 的方式，大流量的情況下，熱點(diǎn)商品扣減庫(kù)存操作會(huì)打向redis單片，造成單片性能抖動(dòng)，從而出現(xiàn)redis性能瓶頸。

對(duì)于第1種熱點(diǎn)問(wèn)題，在vivo商城常見(jiàn)的場(chǎng)景是：新發(fā)的爆品手機(jī)，在準(zhǔn)點(diǎn)售賣(mài)時(shí)會(huì)有搶購(gòu)效應(yīng)，容易造成庫(kù)存數(shù)據(jù)庫(kù)單行的瓶頸問(wèn)題。針對(duì)這種熱點(diǎn)問(wèn)題，我們的解決方案是“分而治之”：

對(duì)于潛在的熱點(diǎn)爆款手機(jī)，我們會(huì)將庫(kù)存平均分為多行（比如M行），扣減庫(kù)存時(shí)，隨機(jī)在M行中選取一行庫(kù)存數(shù)據(jù)進(jìn)行扣減。該方案突破了數(shù)據(jù)庫(kù)單行鎖的瓶頸限制，解決了爆款商品的熱點(diǎn)問(wèn)題。

對(duì)于第2種redis單片熱點(diǎn)問(wèn)題，解決方案也是分而治之。將數(shù)據(jù)庫(kù)中的庫(kù)存數(shù)據(jù)同步到redis時(shí)，把key值打散，分散在多個(gè)redis單片中。注：我們目前線(xiàn)上的流量峰值還達(dá)不到會(huì)造成redis單片瓶頸的問(wèn)題，為避免過(guò)度設(shè)計(jì)，只做了前置限流，沒(méi)有進(jìn)行key值的打散。

4.3 庫(kù)存同步方案

庫(kù)存系統(tǒng)存在一些庫(kù)存同步場(chǎng)景：

對(duì)接倉(cāng)儲(chǔ)系統(tǒng)，完成實(shí)物庫(kù)存同步。

兼容歷史架構(gòu)，商品系統(tǒng)庫(kù)存的可售庫(kù)存同步等。

（1）實(shí)物庫(kù)存同步：

實(shí)物庫(kù)存同步，對(duì)接的是倉(cāng)儲(chǔ)系統(tǒng)，通過(guò)接口來(lái)獲取商品的實(shí)際庫(kù)存。實(shí)物庫(kù)存同步分成兩種：定時(shí)全量同步、指定單品更新。

定時(shí)全量同步： 每天定時(shí)全量拉取庫(kù)存調(diào)度平臺(tái)的實(shí)物庫(kù)存進(jìn)行全量同步。

制定單品： 運(yùn)營(yíng)也可以手動(dòng)觸發(fā)單個(gè)sku的商品即時(shí)同步實(shí)物庫(kù)存。

（2）商品系統(tǒng)庫(kù)存同步：

由于庫(kù)存系統(tǒng)多個(gè)場(chǎng)景涉及庫(kù)存變更，運(yùn)營(yíng)手動(dòng)編輯、用戶(hù)下單退款導(dǎo)致庫(kù)存扣減回退，還有商品系統(tǒng)內(nèi)編輯庫(kù)存數(shù)據(jù)也會(huì)導(dǎo)致庫(kù)存變更（以前庫(kù)存系統(tǒng)未獨(dú)立，庫(kù)存數(shù)據(jù)維護(hù)在商品系統(tǒng)）。同時(shí)很多業(yè)務(wù)在查詢(xún)庫(kù)存時(shí)，參考的依舊是商品系統(tǒng)的庫(kù)存數(shù)據(jù)。

這里有一個(gè)問(wèn)題：庫(kù)存系統(tǒng)已經(jīng)獨(dú)立出來(lái)，為什么還會(huì)依賴(lài)商品系統(tǒng)的庫(kù)存數(shù)據(jù)？

這有兩點(diǎn)原因 ：

商城多個(gè)業(yè)務(wù)的后臺(tái)有商品篩選的需要，商品篩選會(huì)有庫(kù)存數(shù)量的篩選項(xiàng)。商品數(shù)量很多，篩選是分頁(yè)的，如果將庫(kù)存數(shù)據(jù)全部替換成庫(kù)存系統(tǒng)的，那么存在跨系統(tǒng)分頁(yè)問(wèn)題，分頁(yè)篩選會(huì)存在問(wèn)題；

歷史遺留問(wèn)題，很多業(yè)務(wù)方依賴(lài)的是商品系統(tǒng)的庫(kù)存數(shù)據(jù)（包括依賴(lài)商品庫(kù)存離線(xiàn)表的業(yè)務(wù)方），全部切換到庫(kù)存系統(tǒng)，成本和影響范圍大。

因此，我們需要保證商品系統(tǒng)和庫(kù)存系統(tǒng)兩邊庫(kù)存數(shù)據(jù)的一致。

庫(kù)存變更場(chǎng)景多，為了降低業(yè)務(wù)復(fù)雜度、采用簡(jiǎn)單的方式實(shí)現(xiàn)庫(kù)存同步，我們利用了團(tuán)隊(duì)自研的CDC系統(tǒng)（魯班平臺(tái)），整體流程如下：

庫(kù)存數(shù)據(jù)庫(kù)發(fā)生變更后，魯班平臺(tái)通過(guò)binlog采集獲取庫(kù)存變更日志，再通過(guò)自定義規(guī)則篩選，然后發(fā)送mq變更消息，最后商品系統(tǒng)消費(fèi)消息完成庫(kù)存同步變更。

五、總結(jié)及展望

最后對(duì)庫(kù)存系統(tǒng)進(jìn)行一個(gè)總結(jié) ：

庫(kù)存系統(tǒng)完成服務(wù)拆分，在單一的可售庫(kù)存扣減功能基礎(chǔ)上拓展了很多功能，賦能業(yè)務(wù)的發(fā)展。

完成庫(kù)存架構(gòu)分層，抽象多個(gè)庫(kù)存類(lèi)型，更靈活地滿(mǎn)足當(dāng)前業(yè)務(wù)需求。

針對(duì)庫(kù)存扣減防重、高并發(fā)場(chǎng)景下的庫(kù)存扣減、庫(kù)存熱點(diǎn)問(wèn)題、庫(kù)存同步等技術(shù)問(wèn)題，我們根據(jù)業(yè)務(wù)實(shí)際情況設(shè)計(jì)合理方案。

展望

目前vivo商城庫(kù)存系統(tǒng)平臺(tái)化能力不足，部分能力分散在其他系統(tǒng)中，未來(lái)我們希望能為vivo新零售提供一體化的庫(kù)存管理方案。

編輯：黃飛

?