亚洲中文字幕无码日韩精品,亚洲一区制服无码中字,亚洲精品第一国产综合精品99 ,一本大道中文日本香蕉

  高并發(fā)扣減庫存方案（秒殺扣減庫存）

發(fā)布日期：2022/9/7 10:37:15      瀏覽量：

背景

我們在做電商的時候，經常遇到下單之后需要扣減庫存的業(yè)務，那這個業(yè)務我們怎么來實現呢？

傳統(tǒng)的做法是：

1. 用戶下單，執(zhí)行下單服務；
2. 同時，扣減庫存；

如果是并發(fā)較高的場景，為了保證可用和性能，那么采用二階段事務的方式，或者消息隊列的方式，都可以實現。

但是，多個線程同時執(zhí)行下單服務，庫存服務，這樣，會出現什么問題呢？

由于扣減服務中的邏輯并不是原子操作，必然會出現數據不一致的情況，比如，當前庫存數量為 1，此時多個線程同時校驗庫存符合預期，但結果庫存為 1 滿足了多個線程，顯然是不符合預期的，這樣，就會導致庫存不足的情況。

我們對扣減庫存所需要關注的技術點如下：

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

基于 MySQL 進行扣減

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

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

1. 基于數據庫的樂觀鎖方式保證并發(fā)扣減的強一致性；
2. 基于數據庫的事務實現批量扣減失敗進行回滾。

流程圖如下：

有一句話說的非常好：一次完整的流程就是先進行數據校驗，在其中做一些參數格式校驗，這里做接口開發(fā)的時候，要保持一個原則就是不信任原則，一切數據都不要相信，都需要做校驗判斷。

1

update xxx set leavedAmount=leavedAmount-currentAmount where skuid=’xxx’ and leavedAmount>=currentAmount;

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

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

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

庫存校驗這一步涉及到了讀請求，那么必然增加了數據庫的壓力，所以需要做一些優(yōu)化。

1. 讀寫分離；

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

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

1. 增加緩存；

在上面基礎上，還可以升級，增加緩存：

緩存實現扣減

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

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

但，升級成純 Redis 實現扣減也會有問題：

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

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

數據庫+緩存

在此之前，先闡述一下順序寫的性能較好。

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

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

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

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

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

1
2
3
4

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

任務表里存儲的內容格式可以為 JSON、XML 等結構化的數據。以 JSON 為例，數據內容大致可以如下：

{
"扣減號":uuid,
"skuid1":"數量",
"skuid2":"數量",
"xxxx":"xxxx"
}

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

扣減流程：

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

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

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

商品的實時數據匯總表，結構如下：

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

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