相信大家從網(wǎng)上學習項目大部分人第一個項目都是電商，生活中時時刻刻也會用到電商APP，例如淘寶，京東等。做技術(shù)的人都知道，電商的業(yè)務邏輯簡單，但是大部分電商都會涉及到高并發(fā)高可用，對并發(fā)和對數(shù)據(jù)的處理要求是很高的。這里我今天就講一下高并發(fā)情況下是如何扣減庫存的？

我們對扣減庫存所需要關(guān)注的技術(shù)點如下：

• 當前剩余的數(shù)量大于等于當前需要扣減的數(shù)量，不允許超賣
• 對于同一個數(shù)據(jù)的數(shù)量存在用戶并發(fā)扣減，需要保證并發(fā)的一致性
• 需要保證可用性和性能，性能至少是秒級
• 一次的扣減包含多個目標數(shù)量
• 當次扣減有多個數(shù)量時，其中一個扣減不成功即不成功，需要回滾
• 必須有扣減才能有歸還
• 返還的數(shù)量必須要加回，不能丟失
• 一次扣減可以有多次返還
• 返還需要保證冪等性

第一種方案：純MySQL扣減實現(xiàn)

顧名思義，就是扣減業(yè)務完全依賴MySQL等數(shù)據(jù)庫來完成。而不依賴一些其他的中間件或者緩存。純數(shù)據(jù)庫實現(xiàn)的好處就是邏輯簡單，開發(fā)以及部署成本低。（適用于中小型電商）。

純數(shù)據(jù)庫的實現(xiàn)之所以能夠滿足扣減業(yè)務的各項功能要求，主要依賴兩點：

• 基于數(shù)據(jù)庫的樂觀鎖方式保證并發(fā)扣減的強一致性
• 基于數(shù)據(jù)庫的事務實現(xiàn)批量扣減失敗進行回滾

基于上述方案，它包含一個扣減服務和一個數(shù)量數(shù)據(jù)庫

如果數(shù)據(jù)量單庫壓力很大，也可以做主從和分庫分表，服務可以做集群等。

一次完整的流程就是先進行數(shù)據(jù)校驗，在其中做一些參數(shù)格式校驗，這里做接口開發(fā)的時候，要保持一個原則就是不信任原則，一切數(shù)據(jù)都不要相信，都需要做校驗判斷。其次，還可以進行庫存扣減的前置校驗。比如當前庫存中的庫存只有8個，而用戶要購買10個，此時的數(shù)據(jù)校驗中即可前置攔截，減少對于數(shù)據(jù)庫的寫操作。純讀不會加鎖，性能較高，可以采用此種方式提升并發(fā)量。

update xxx set leavedAmount=leavedAmount-currentAmount where skuid='xxx' and leavedAmount>=currentAmount

此SQL采用了類似樂觀鎖的方式實現(xiàn)了原子性。在where后面判斷剩余數(shù)量大于等于需要的數(shù)量，才能成功，否則失敗。

扣減完成之后，需要記錄流水數(shù)據(jù)。每一次扣減的時候，都需要外部用戶傳入一個uuid作為流水編號，此編號是全局唯一的。用戶在扣減時傳入唯一的編號有兩個作用：

• 當用戶歸還數(shù)量時，需要帶回此編碼，用來標識此次返還屬于歷史上的哪次扣減。
• 進行冪等性控制。當用戶調(diào)用扣減接口出現(xiàn)超時時，因為用戶不知道是否成功，用戶可以采用此編號進行重試或反查。在重試時，使用此編號進行標識防重

當用戶只購買某個商品一個的時候，如果校驗時剩余庫存有8個，此時校驗通過。但在后續(xù)的實際扣減時，因為其他用戶也在并發(fā)的扣減，可能會出現(xiàn)幻讀，此時用戶實際去扣減時不足一個，導致失敗。這種場景會導致多一次數(shù)據(jù)庫查詢，降低整體的扣減性能。這時候可以對MySQL架構(gòu)進行升級

MySQL架構(gòu)升級

多一次查詢，就會增加數(shù)據(jù)庫的壓力，同時對整體性能也有一定的影響。此外，對外提供的查詢庫存數(shù)量的接口也會對數(shù)據(jù)庫產(chǎn)生壓力，同時讀的請求要遠大于寫。

根據(jù)業(yè)務場景分析，讀庫存的請求一般是顧客瀏覽商品時產(chǎn)生，而調(diào)用扣減庫存的請求基本上是用戶購買時才觸發(fā)。用戶購買請求的業(yè)務價值比讀請求會更大，因此對于寫需要重點保障。針對上述的問題，可以對MySQL整體架構(gòu)進行升級

整體的升級策略采用讀寫分離的方式，另外主從復制直接使用MySQL等數(shù)據(jù)庫已有的功能，改動上非常小，只要在扣減服務里配置兩個數(shù)據(jù)源。當客戶查詢剩余庫存，扣減服務中的前置校驗時，讀取從數(shù)據(jù)庫即可。而真正的數(shù)據(jù)扣減還是使用主數(shù)據(jù)庫。

讀寫分離之后，根據(jù)二八原則，80% 的均為讀流量，主庫的壓力降低了 80%。但采用了讀寫分離也會導致讀取的數(shù)據(jù)不準確的問題，不過庫存數(shù)量本身就在實時變化，短暫的差異業(yè)務上是可以容忍的，最終的實際扣減會保證數(shù)據(jù)的準確性。

在上面基礎(chǔ)上，還可以升級，增加緩存

純數(shù)據(jù)庫的方案雖然可以避免超賣和少賣的情況，但是并發(fā)量實在很低，性能不是很樂觀。所以這里再進行升級

第二種方案：緩存實現(xiàn)扣減

這和前面的扣減庫存其實是一樣的。但是此時扣減服務依賴的是Redis而不是數(shù)據(jù)庫了。

這里針對Redis的hash結(jié)構(gòu)不支持多個key的批量操作問題，我們可以采用Redis+lua腳本來實現(xiàn)批量扣減單線程請求。

升級成純Redis實現(xiàn)扣減也會有問題

• Redis掛了，如果還沒有執(zhí)行到扣減Redis里面庫存的操作掛了，只需要返回給客戶端失敗即可。如果已經(jīng)執(zhí)行到Redis扣減庫存之后掛了。那這時候就需要有一個對賬程序。通過對比Redis與數(shù)據(jù)庫中的數(shù)據(jù)是否一致，并結(jié)合扣減服務的日志。當發(fā)現(xiàn)數(shù)據(jù)不一致同時日志記錄扣減失敗時，可以將數(shù)據(jù)庫比Redis多的庫存數(shù)據(jù)在Redis進行加回。
• Redis扣減完成，異步刷新數(shù)據(jù)庫失敗了。此時Redis里面的數(shù)據(jù)是準的，數(shù)據(jù)庫的庫存是多的。在結(jié)合扣減服務的日志確定是Redis扣減成功到但異步記錄數(shù)據(jù)失敗后，可以將數(shù)據(jù)庫比Redis多的庫存數(shù)據(jù)在數(shù)據(jù)庫中進行扣減。

雖然使用純Redis方案可以提高并發(fā)量，但是因為Redis不具備事務特性，極端情況下會存在Redis的數(shù)據(jù)無法回滾，導致出現(xiàn)少賣的情況。也可能發(fā)生異步寫庫失敗，導致多扣的數(shù)據(jù)再也無法找回的情況。

第三種方案：數(shù)據(jù)庫+緩存 順序?qū)懙男阅芨?/h2>

在向磁盤進行數(shù)據(jù)操作時，向文件末尾不斷追加寫入的性能要遠大于隨機修改的性能。因為對于傳統(tǒng)的機械硬盤來說，每一次的隨機更新都需要機械鍵盤的磁頭在硬盤的盤面上進行尋址，再去更新目標數(shù)據(jù)，這種方式十分消耗性能。而向文件末尾追加寫入，每一次的寫入只需要磁頭一次尋址，將磁頭定位到文件末尾即可，后續(xù)的順序?qū)懭氩粩嘧芳蛹纯伞?/p>

對于固態(tài)硬盤來說，雖然避免了磁頭移動，但依然存在一定的尋址過程。此外，對文件內(nèi)容的隨機更新和數(shù)據(jù)庫的表更新比較類似，都存在加鎖帶來的性能消耗。

數(shù)據(jù)庫同樣是插入要比更新的性能好。對于數(shù)據(jù)庫的更新，為了保證對同一條數(shù)據(jù)并發(fā)更新的一致性，會在更新時增加鎖，但加鎖是十分消耗性能的。此外，對于沒有索引的更新條件，要想找到需要更新的那條數(shù)據(jù)，需要遍歷整張表，時間復雜度為 O(N)。而插入只在末尾進行追加，性能非常好。

順序?qū)懙募軜?gòu)

通過上面的理論就可以得出一個兼具性能和高可靠的扣減架構(gòu)

上述的架構(gòu)和純緩存的架構(gòu)區(qū)別在于，寫入數(shù)據(jù)庫不是異步寫入，而是在扣減的時候同步寫入。同步寫入數(shù)據(jù)庫使用的是insert操作，就是順序?qū)?，而不是update做數(shù)據(jù)庫數(shù)量的修改，所以，性能會更好。

insert 的數(shù)據(jù)庫稱為任務庫，它只存儲每次扣減的原始數(shù)據(jù)，而不做真實扣減（即不進行 update）。它的表結(jié)構(gòu)大致如下：

create table task{
  id bigint not null comment "任務順序編號",
  task_id bigint not null 
}

任務表里存儲的內(nèi)容格式可以為 JSON、XML 等結(jié)構(gòu)化的數(shù)據(jù)。以 JSON 為例，數(shù)據(jù)內(nèi)容大致可以如下：

{
  "扣減號":uuid,
  "skuid1":"數(shù)量",
  "skuid2":"數(shù)量",
  "xxxx":"xxxx"
}

這里我們肯定是還有一個記錄業(yè)務數(shù)據(jù)的庫，這里存儲的是真正的扣減名企和SKU的匯總數(shù)據(jù)。對于另一個庫里面的數(shù)據(jù)，只需要通過這個表進行異步同步就好了。

扣減流程

這里和純緩存的區(qū)別在于增加了事務開啟與回滾的步驟，以及同步的數(shù)據(jù)庫寫入流程

任務庫里存儲的是純文本的 JSON 數(shù)據(jù)，無法被直接使用。需要將其中的數(shù)據(jù)轉(zhuǎn)儲至實際的業(yè)務庫里。業(yè)務庫里會存儲兩類數(shù)據(jù)，一類是每次扣減的流水數(shù)據(jù)，它與任務表里的數(shù)據(jù)區(qū)別在于它是結(jié)構(gòu)化，而不是 JSON 文本的大字段內(nèi)容。另外一類是匯總數(shù)據(jù)，即每一個 SKU 當前總共有多少量，當前還剩余多少量（即從任務庫同步時需要進行扣減的），表結(jié)構(gòu)大致如下：

create table 流水表{
  id bigint not null,
  uuid bigint not null comment '扣減編號',
  sku_id bigint not null comment '商品編號',
  num int not null comment '當次扣減的數(shù)量' 
}comment '扣減流水表'

商品的實時數(shù)據(jù)匯總表，結(jié)構(gòu)如下：

create table 匯總表{
  id bitint not null,
  sku_id unsigned bigint not null comment '商品編號',
  total_num unsigned int not null comment '總數(shù)量',
  leaved_num unsigned int not null comment '當前剩余的商品數(shù)量'
}comment '記錄表'

在整體的流程上，還是復用了上一講純緩存的架構(gòu)流程。當新加入一個商品，或者對已有商品進行補貨時，對應的新增商品數(shù)量都會通過 Binlog 同步至緩存里。在扣減時，依然以緩存中的數(shù)量為準

到此這篇關(guān)于Redis高并發(fā)情況下并發(fā)扣減庫存項目實戰(zhàn)的文章就介紹到這了,更多相關(guān)Redis 并發(fā)扣減庫存內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論