由于秒殺場景是庫存爭搶非常經典的一個應用場景，接下來我會結合秒殺需求，帶你看看如何實現高并發下的庫存爭搶，相信在這一過程中你會對鎖有更深入的認識。

鎖爭搶的錯誤做法

在開始介紹庫存爭搶的具體方案之前，我們先來了解一個小知識——并發庫存鎖。還記得在我學計算機的時候，老師曾演示過一段代碼：

public class ThreadCounter {
private static int count = 0;


public static void main(String[] args) throws Exception {
        Runnable task = new Runnable() {
public void run() {
for (int i = 0; i < 1000; ++i) {
                    count += 1;
                }
            }
        };


        Thread t1 = new Thread(task);
        t1.start();


        Thread t2 = new Thread(task);
        t2.start();


        t1.join();
        t2.join();


        cout << "count = " << count << endl;
    }
}

從代碼來看，我們運行后結果預期是 2000，但是實際運行后并不是。為什么會這樣呢？當多線程并行對同一個公共變量讀寫時，由于沒有互斥，多線程的 set 會相互覆蓋或讀取時容易讀到其他線程剛寫一半的數據，這就導致變量數據被損壞。反過來說，我們要想保證一個變量在多線程并發情況下的準確性，就需要這個變量在修改期間不會被其他線程更改或讀取。對于這個情況，我們一般都會用到鎖或原子操作來保護庫存變量：如果是簡單 int 類型數據，可以使用原子操作保證數據準確；如果是復雜的數據結構或多步操作，可以加鎖來保證數據完整性。

考慮到我們之前的習慣會有一定慣性，為了讓你更好地理解爭搶，這里我再舉一個我們常會犯錯的例子。因為扣庫存的操作需要注意原子性，我們實踐的時候常常碰到后面這種方式：

redis> get prod_1475_stock_1
15
redis> set prod_1475_stock_1 14
OK

也就是先將變量從緩存中取出，對其做 -1 操作，再放回到緩存當中，這是個錯誤做法。

圖片

如上圖，原因是多個線程一起讀取的時候，多個線程同時讀到的是 5，set 回去時都是 6，實際每個線程都拿到了庫存，但是庫存的實際數值并沒有累計改變，這會導致庫存超賣。如果你需要用這種方式去做，一般建議加一個自旋互斥鎖，互斥其他線程做類似的操作。

原子操作

當大量用戶并發修改某個變量時，使用互斥鎖雖然能保證數據修改的正確性，但性能非常低。假設有一萬個用戶爭搶一個鎖，排隊等待修改服務器中的變量，這樣的設計效率極差。鎖在獲取過程中需要自旋，反復嘗試才能搶到鎖，用戶越多，爭搶越激烈，系統資源的消耗就越大，可能導致系統不穩定。

為了解決這個問題，我會選擇將庫存數據存放在高性能的內存緩存服務（比如 Redis）中集中管理。這樣可以避免用戶爭搶鎖時影響到其他服務，同時也能提高響應速度。Redis 本身支持原子操作，并且通過它可以更好地應對高并發場景。這也是目前互聯網行業普遍采用的庫存保護方案。

相比之下，不建議通過數據庫行鎖來保證庫存的修改。數據庫資源非常寶貴，如果使用行鎖管理庫存，不僅性能會很差，系統也容易變得不穩定。

為了減少鎖爭搶和提升系統效率，我們可以采取降低鎖粒度的方式，或者引入其他優化方案。

圖片

實際上，我們可以通過將熱門商品的庫存進行拆分，存儲到多個 key 中，從而顯著減少鎖的競爭。比如，假設當前商品的庫存為 100 個，可以把庫存分成 10 個 key，每個 key 保存 10 個庫存，并將這些 key 分布在不同的 Redis 實例中。當用戶下單時，可以隨機選擇一個 key 扣減庫存。如果某個 key 中的庫存不足，再記錄該 key 并隨機挑選剩余的 key 進行扣減，直到成功完成一次庫存的扣除。

不過，除了這種方法之外，我更推薦使用 Redis 的原子操作來處理庫存問題。原子操作的粒度更小，并且 Redis 本質上是單線程運行，能夠提供全局唯一的決策。很多原子操作的底層實現甚至是通過硬件實現的，性能非常優異，且不會產生鎖競爭問題。

以 Redis 的 INCR 和 DECR 操作為例，它們可以在不加鎖的情況下實現對庫存的精確修改，這樣能同時保證高性能和數據的一致性。

redis> decr prod_1475_stock_1
14

incr、decr 這類操作就是原子的，我們可以根據返回值是否大于 0 來判斷是否扣庫存成功。但是這里你要注意，如果當前值已經為負數，我們需要考慮一下是否將之前扣除的補償回來。并且為了減少修改操作，我們可以在扣減之前做一次值檢測，整體操作如下：

//讀取當前庫存，確認是否大于零
//如大于零則繼續操作，小于等于拒絕后續
redis> get prod_1475_stock_1
1


//開始扣減庫存、如返回值大于或等于0那么代表扣減成功，小于0代表當前已經沒有庫存
//可以看到返回-2，這可以理解成同時兩個線程都在操作扣庫存，并且都沒拿到庫存
redis> decr prod_1475_stock_1
-2


//扣減失敗、補償多扣的庫存
//這里返回0是因為同時兩個線程都在做補償，最終恢復0庫存
redis> incr prod_1475_stock
0

這個庫存保護方案確實很有價值，但也有其局限性。庫存的準確性依賴于業務是否能成功“返還”之前扣減的庫存。如果在服務運行過程中“返還”操作被中斷，人工修復將變得非常困難，因為無法確定當前還有多少庫存正在處理中。通常，我們需要等到活動結束后再查看最終庫存。

為了完全保證庫存不丟失，通常會依賴事務和回滾機制，但 Redis 作為外置的庫存服務，并不屬于數據庫的緩存范疇。這就要求我們在每個可能出現故障的業務環節中都能夠妥善處理庫存問題。因此，許多秒殺系統在出現故障時往往選擇不返還庫存，并不是因為不想，而是因為很多意外場景無法做到。

至于使用 SETNX 指令或數據庫的 CAS（比較并交換）機制來實現互斥鎖，盡管這能解決庫存問題，但這種鎖機制會引入自旋等待。在并發高的情況下，用戶服務需要反復嘗試才能獲取鎖，這樣會浪費系統資源，并對數據服務造成較大壓力。因此，這種方法并不推薦使用。

令牌庫存

除了這種用數值記錄庫存的方式外，還有一種比較科學的方式就是“發令牌”方式，通過這個方式可以避免出現之前因為搶庫存而讓庫存出現負數的情況。

圖片

具體是使用 Redis 中的 list 保存多張令牌來代表庫存，一張令牌就是一個庫存，用戶搶庫存時拿到令牌的用戶可以繼續支付：

//放入三個庫存
redis> lpush prod_1475_stock_queue_1 stock_1
redis> lpush prod_1475_stock_queue_1 stock_2
redis> lpush prod_1475_stock_queue_1 stock_3


//取出一個，超過0.5秒沒有返回，那么搶庫存失敗
redis> brpop prod_1475_stock_queue_1 0.5

在庫存搶購失敗時，用戶只會收到 nil，這種實現方式確實能避免失敗后還要補償庫存的問題。不過，即便如此，如果我們的業務代碼在異常處理上不夠完善，依然可能發生庫存丟失的情況。同時，如果需要從隊列中取出令牌，使用 brpop 可以阻塞等待，而使用 rpop 則在壓測場景下性能表現更好，因為不需要等待。

然而，當庫存數量非常龐大時，令牌方式可能并不適用。比如，如果有1萬個庫存，就需要插入1萬個令牌到 Redis 的 list 中；如果庫存有10萬，就得連續插入10萬個字符串，這會導致 Redis 在入庫期間發生大量卡頓。

到這里，庫存設計似乎已經比較完善了，但如果產品團隊提出“一個商品可以一次搶多個庫存”的需求（比如一次秒殺兩袋大米），這個方案可能就無法滿足了。因為我們依賴于多個鎖來降低競爭，而一次性扣減多個庫存會讓這個設計變得復雜，鎖爭搶問題依舊存在。

多庫存秒殺

其實這種情況經常出現，這讓我們對之前的優化有了更多的想法。對于一次秒殺多個庫存，我們的設計需要做一些調整。

圖片

之前，我們為了減少鎖競爭，將庫存拆分成了 10 個不同的 key 并隨機獲取。但如果到了庫存只剩下最后幾個商品的極端情況，用戶一次秒殺三件商品（如上例所示），可能需要嘗試所有的庫存 key。最終，在嘗試了 10 個 key 后，可能只成功扣減了兩個庫存。這個時候，我們就面臨選擇：是拒絕用戶的訂單，還是返還庫存？

這就取決于產品的設計思路了。同時，我們還需要增加一個檢測機制：如果庫存已經售罄，就不要再去嘗試獲取 10 個庫存 key 了。畢竟，在沒庫存的情況下，每次請求都會刷 10 次 Redis，而這會對 Redis 服務帶來較大壓力。雖然 Redis 的 O(1) 操作理論上可以達到每秒 10 萬次操作（OPS），但一次請求刷 10 次，理想情況下搶購庫存的接口性能大約為每秒 1 萬次請求（QPS）。實際壓測后，建議按照實測性能的 70% 來進行漏斗式限流。

你應該注意到了，在“一個商品可以搶多個庫存”的場景下，庫存拆分方案并沒有減少鎖的爭搶次數，反而增加了維護的復雜性。當庫存越來越少時，系統性能會顯著下降，這樣的設計已經不符合我們最初的目的（這種由業務需求引發的設計不適配問題在實際項目中非常常見，需要我們在設計之初更深入地理解產品需求）。

那么，應該怎么優化呢？我們可以考慮將原來拆分的 10 個 key 合并為 1 個，然后使用 rpop 來實現多個庫存的扣減操作。對于庫存不足的情況（例如，用戶想買 3 件但只剩 2 件庫存），需要產品側給出明確的建議，看是否繼續處理交易。同時，在每次操作開始時，可以使用 LLEN（O(1) 操作）檢查 list 中是否有足夠的庫存支持 rpop。

//取之前看一眼庫存是否空了，空了不繼續了(llen O(1))
redis> llen prod_1475_stock_queue
3


//取出庫存3個，實際搶到倆
redis> rpop prod_1475_stock_queue 3
"stock_1"
"stock_2"


//產品說數量不夠，不允許繼續交易，將庫存返還  
redis> lpush prod_1475_stock_queue stock_1
redis> lpush prod_1475_stock_queue stock_2

通過這個設計，我們已經大大降低了下單系統鎖爭搶壓力。要知道，Redis 是一個性能很好的緩存服務，其 O(1) 類復雜度的指令在使用長鏈接的情況下多線程壓測，5.0 版本的 Redis 就能夠跑到 10w OPS，而 6.0 版本的網絡性能會更好。這種利用 Redis 原子操作減少鎖沖突的方式，對各個語言來說是通用且簡單的。不過你要注意，不要把 Redis 服務和復雜業務邏輯混用，否則會影響我們的庫存接口效率。

自旋互斥超時鎖

如果我們在庫存爭搶時需要操作多個決策 key 才能夠完成爭搶，那么原子這種方式是不適合的。因為原子操作的粒度過小，無法做到事務性地維持多個數據的 ACID。這種多步操作，適合用自旋互斥鎖的方式去實現，但流量大的時候不推薦這個方式，因為它的核心在于如果我們要保證用戶的體驗，我們需要邏輯代碼多次循環搶鎖，直到拿到鎖為止，如下：

//業務邏輯需要循環搶鎖，如循環10次，每次sleep 10ms，10次失敗后返回失敗給用戶
//獲取鎖后設置超時時間，防止進程崩潰后沒有釋放鎖導致問題
//如果獲取鎖失敗會返回nil
redis> set prod_1475_stock_lock EX 60 NX
OK


//搶鎖成功，扣減庫存
redis> rpop prod_1475_stock_queue 1
"stock_1"


//扣減數字庫存，用于展示
redis> decr prod_1475_stock_1
3


// 釋放鎖
redis> del prod_1475_stock_lock

圖片

這種方式的缺點在于，在搶鎖階段如果排隊搶的線程越多，等待時間就越長，并且由于多線程一起循環 check 的緣故，在高并發期間 Redis 的壓力會非常大，如果有 100 人下單，那么有 100 個線程每隔 10ms 就會 check 一次，此時 Redis 的操作次數就是：

100線程×（1000ms÷10ms）次=10000ops

CAS 樂觀鎖：鎖操作后置

另外一個推薦的方式是使用 CAS（Compare and Swap）樂觀鎖。與自旋互斥鎖相比，在并發搶庫存的線程較少時，CAS 樂觀鎖效率更高。傳統的鎖機制是通過先獲取鎖，再對數據進行操作，這個過程中搶鎖本身會消耗性能，哪怕沒有其他線程參與爭搶，搶鎖的開銷依然存在。

而 CAS 樂觀鎖 的核心在于記錄或監控當前的庫存信息或版本號，在此基礎上進行預操作。當線程準備修改數據時，系統會先檢查當前的庫存版本號是否和預期的一致。如果一致，則修改成功；否則，重新讀取最新的數據并重試。這種方式可以避免鎖競爭帶來的性能損耗，在并發較低的場景下更具優勢。

圖片

如上圖，在操作期間如果發現監控的數值有變化，那么就回滾之前操作；如果期間沒有變化，就提交事務的完成操作，操作期間的所有動作都是事務的。

//開啟事務
redis> multi
OK


// watch 修改值
// 在exec期間如果出現其他線程修改，那么會自動失敗回滾執行discard
redis> watch prod_1475_stock_queue prod_1475_stock_1


//事務內對數據進行操作
redis> rpop prod_1475_stock_queue 1
QUEUED


//操作步驟2
redis> decr prod_1475_stock_1
QUEUED


//執行之前所有操作步驟
//multi 期間 watch有數值有變化則會回滾
redis> exec
3

以看到，通過這個方式我們可以批量地快速實現庫存扣減，并且能大幅減少鎖爭搶時間。它的好處我們剛才說過，就是爭搶線程少時效率特別好，但爭搶線程多時會需要大量重試，不過即便如此，CAS 樂觀鎖也會比用自旋鎖實現的性能要好。當采用這個方式的時候，我建議內部的操作步驟盡量少一些。同時要注意，如果 Redis 是 Cluster 模式，使用 multi 時必須在一個 slot 內才能保證原子性。

Redis Lua 方式實現 Redis 鎖

與“事務 + 樂觀鎖”類似的另一種實現方式是使用 Redis 的 Lua 腳本 來進行多步驟的庫存操作。由于 Lua 腳本在 Redis 內部的執行是連續且原子的，因此所有操作不會被其他操作打斷，避免了鎖爭搶的問題。

此外，Lua 腳本可以根據不同情況靈活處理不同的操作，業務只需調用指定的 Lua 腳本并傳遞相關參數，就可以實現高性能的庫存扣減。這樣做不僅提高了操作的原子性，也顯著減少了由于多次請求等待所帶來的 RTT（往返時間），提升了整體系統的響應速度和并發處理能力。

為了方便演示怎么執行 Lua 腳本，我使用了 PHP 實現：

<?php
$script = <<<EOF
// 獲取當前庫存個數
local stock=tonumber(redis.call('GET',KEYS[1])); 
//沒找到返回-1
if stock==nil 
then
return -1; 
end 
//找到了扣減庫存個數
local result=stock-ARGV[1]; 
//如扣減后少于指定個數，那么返回0
if result<0 
then
return 0; 
else
    //如果扣減后仍舊大于0，那么將結果放回Redis內，并返回1
    redis.call('SET',KEYS[1],result); 
return 1; 
end
EOF;


$redis = new \Redis();
$redis->connect('127.0.0.1', 6379);
$result = $redis->eval($script, array("prod_stock", 3), 1);
echo $result;

通過這個方式，我們可以遠程注入各種連貫帶邏輯的操作，并且可以實現一些補庫存的操作。

總結

圖片