高并發下秒殺系統的設計
在電商這片紅海，秒殺活動無疑是屢試不爽的流量密碼、銷量利器。然而，在應對其并發請求時，其中的設計門道暗藏玄機。并發量小，數據庫單表便能一夫當關，穩保活動無虞；一旦碰上爆款引爆流量，并發呈井噴式增長，單表瞬間獨木難支，此時，一套高并發 “抗壓” 組合拳必不可少。接下來，咱們就一起深挖業界那些屢建奇功的妙招，直擊高并發痛點，重點解析其中兩大 “硬核” 方案，助你輕松拿捏秒殺場景的技術難點。
1 業界通用做法
1.1 壓力分攤
在應對并發的挑戰時，利用分桶策略壓力分攤，往往受到很多人的青睞。具體而言，面對單品庫存，巧妙地拆分為多組，大大緩解搶購高峰的壓力。但這背后藏著諸多棘手難題，如何精準地將庫存均勻分配至各桶，杜絕分配不均；怎樣有效處理拆分產生的庫存碎片，避免少賣；分桶間的調度規則如何制定，確保協同高效；還有，業務量起伏不定，又該如何實現分桶動態擴容以靈活適配。這些問題也需要我們進行考慮設計。
1.2 Redis+MySQL
在秒殺系統的架構設計藍圖中，Redis 與 MQ 的組合堪稱一對 “黃金搭檔”。Redis 憑借其卓越的高性能讀寫特性以及原子操作能力可以直面秒殺活動帶來的洶涌并發流量，筑起防止超賣的堅固防線。而 MQ 通過流量削峰策略，將瞬間爆發的海量數據請求進行緩沖與分流，有效減緩后端數據存儲環節的壓力，確保整個系統節奏平穩。
不過，不少人心中會泛起疑惑：既然 Redis 如此強大，為何不索性全程在 Redis 中完成操作，待秒殺塵埃落定，再一次性將數據同步至數據庫呢？理論上看似可行，但若置于真實復雜的業務場景之中，便會破綻百出。要知道，用戶成功搶購后，絕非萬事大吉，后續一系列連貫操作隨即而來，諸如急切地查看搶購結果，或是迅速進入支付流程等，這些都需要實時、精準的數據交互與支持。
當然，采用 Redis + MQ 這套方案并非一勞永逸，其中數據一致性問題猶如潛藏暗處的礁石，不容小覷。不過別擔心，接下來我們就將針對這一方案進行詳細的介紹。
1.3 Inventory Hint
大家普遍知曉高并發場景下需精心構建復雜架構應對挑戰。然而，有一些公司卻看似 “劍走偏鋒”，即便面臨著不容小覷的并發壓力，依舊選擇直接對數據庫進行操作，并未引入那些令人眼花繚亂的高并發設計體系，這難免讓人滿腹狐疑。
實則不然，這些公司背后有著強大的技術支撐 —— 他們選用的是阿里的 RDS 云數據庫。這款數據庫絕非等閑之輩，它依托阿里的強大技術底蘊，內置了先進的 Inventory Hint 技術。憑借該技術對數據庫的精準優化，使得這些公司即便在高并發的槍林彈雨中，也能讓數據庫穩健運行，輕松應對海量數據的讀寫請求。下面，咱們也會深入其中，著重揭開這項神奇技術的神秘面紗，探尋它究竟是如何賦能數據庫、化解高并發難題的。
1.4 壓力分攤+Redis+MQ
面對數百萬 QPS 的高壓沖擊，多種技術方案強強聯手，才能站穩腳跟。SQL 合并執行批量處理請求，削減數據庫負荷。緩存陣營更是齊發力，分布式緩存廣納熱點，本地緩存就近響應，近端緩存將分布式緩存與服務器 “聯姻”，實現超高速讀取。分桶策略巧妙分流，開辟流量 “綠色通道”。各方案各司其職，分擔并發壓力，聚合為強大力量，確保大促活動平穩運行。
2 Redis + MQ 解決高并發下的秒殺場景
2.1 Redis庫存預扣減
上面我們方案二已經介紹過該方案的整體技術架構，接下來我們進行詳細的剖析。該方案我們主要是通過Redis的Lua腳本進行庫存的扣減，這樣可以保證扣減過程中的原子性和高效性。示例代碼如下：
/*
* KEYS[1] --商品id
* KEYS[2] --用戶id uid
* ARGV[1] --扣減數量
* ARGV[2] --用戶提交的 token
*/
String luaScript = "redis.replicate_commands()\n" +
//防止用戶是否重復提交，利用 token實現的，每次提交前會生成一個token，token更新前才可繼續提交
"if redis.call('hexists', KEYS[2], ARGV[2]) == 1 then\n" +
//拋出用戶重復提交的異常
"return redis.error_reply('repeat submit')\n" +
"end \n" +
//商品id
"local product_id = KEYS[1] \n" +
//獲取商品id對應的庫存
"local stock = redis.call('get', KEYS[1]) \n" +
//判斷庫存是否充足
"if tonumber(stock) < tonumber(ARGV[1]) then \n" +
//購買的數量
"return redis.error_reply('stock is not enough') \n" +
"end \n" +
"local remaining_stock = tonumber(stock) - tonumber(ARGV[1]) \n" +
//更新庫存
"redis.call('set', KEYS[1], tostring(remaining_stock)) \n" +
//獲取但當前系統的時間 返回一個數組，包含2個元素 第一個元素是當前的秒數，第2個是當前這一秒已經流逝過的微秒數
"local time = redis.call('time') \n" +
//當前時間戳 ms
"local currentTimeMillis = (time[1] * 1000) + math.floor(time[2] / 1000) \n" +
//存如一條流水 {"change":"1","action":"扣減庫存","from":"100","token":"token","timestamp":1735293810009,"to":99,"product":"product_id_01"}
"redis.call('hset', KEYS[2], ARGV[2], \n" +
"cjson.encode({action = '扣減庫存', product=product_id ,from = stock, to = remaining_stock, change = ARGV[1], token = ARGV[2], timestamp = currentTimeMillis})\n" +
") \n" +
"return remaining_stock";2.1.1 lua腳本執行流程：
涉及到的Redis數據結構以及對應存儲內容：
Hash 數據結構
外層key | 內層key | value |
KEYS[2] | ARGV[2] | json數據格式 |
uid | token | 流水記錄 |
String 數據結構
key | value |
KEYS[1] | stock |
商品id | 庫存 |
2.1.2 Lua腳本主要做了幾件事：
1）防重提交
在秒殺活動中用戶為了能夠搶到想要的商品，會進行瘋狂的點擊，為了防止用戶重復點擊提交，往往需要做一些冪等性的判斷。用戶在每次點擊提交按鈕前后端會新生成一個token，提交時攜帶上，后端針對token判斷是否已經存在，避免重復下單。
2）庫存扣減
判斷購買的數據是否大于庫存，如果是的話，直接返回庫存。如果不是，進行庫存扣減，更新Redis庫存。
3）記錄交易流水
很多人想不明白為啥要進行交易流水的記錄，其實是為了一致性考慮的。可以依據這條流水記錄去訂單表中去進行查詢，如果查詢不到，說明訂單表中未能成功生成訂單，可能需要人工介入進行處理。
2.2 MySQL庫存扣減
在進行數據庫進行庫存扣減的時候，我們是通過RocketMQ的事務消息實現的，這樣做的目的是為了保證數據庫庫存可以扣減成功，如果數據庫庫存扣減失敗的話，也會帶來少賣問題。具體分為以下幾步：
1）發送RocketMQ半消息，此時消息并不能直接消費，需要檢查本地事務的執行結果。
2） 檢查本地事務我們是判斷Redis的Lua腳本是否執行成功，如果執行成功，則返回COMMIT給RocketMQ，如果失敗，則ROLL_BACK消息。
3）RocketMQ為了防止收不到對應的本地事務執行結果會有消息回查機制，我們在消息回查中主要判斷是否有對應的流水，如果存在的話，說明可以提交。
4）消費消息，進行數據庫庫存的扣減，同時記錄對應操作流水。消費時為了保證一致性我們借助的是RocketMQ的消息重試機制，所以此處我們給MQ返回消費ACK時一定要保證我們的數據已經成功落庫，否則不能隨意返回。
2.3 記錄操作流水的原因
我們在進行完庫存扣減動作之后，對應的是下單操作，為了保證下單和庫存的一致性，我們可以用定時對賬機制來核對庫存流水和訂單表中數據是否一致。當然也有其他一致性保證方案，比如Seata、TCC等，可以根據具體的業務場景選擇。
3 Inventory Hint 數據庫扣減
很多公司直接利用阿里云的數據庫就完成了秒殺的功能，也就是我們上面介紹的方案三。上文已經提到過其底層是依賴Inventory Hint技術實現的，接下來我們介紹下Inventory Hint技術的使用以及實現原理。
3.1 使用
Inventory Hint的使用比較簡單，只需要在對應的語句上加上特殊的hint語句就行了。具體可以參考阿里云文檔
3.2 原理介紹
其實高并發下庫存的扣減動作最后瓶頸落在了數據庫單行的熱更新上，Inventory Hint技術就是對熱更新做了相應的優化。
當用Inventory Hint技術的hint語句標記一個SQL后，就相當于告訴MySQL內核這可能是一行熱更新記錄。于是，MySQL內核層就會自動識別帶此類標記的更新操作，在一定的時間間隔內，將收集到的更新操作按照主鍵或者唯一鍵進行分組，這樣更新相同行的操作就會被分到同一組中。
為了進一步提升性能，在實現上，使用兩個執行單元。當第一個執行單元收集完畢準備提交時，第二個執行單元立即開始收集更新操作；當第二個執行單元收集完畢準備提交時，第一個執行單元已經提交完畢并開始收集新批的更新操作，兩個單元不斷切換，并行執行。
3.2.1 關鍵優化點：
1）減少行級鎖的申請等待
同組更新同一記錄時依 SQL 提交順序排隊，Leader 率先嘗試拿目標行鎖，成功即操作，Follower 拿鎖前先確認，若 Leader 已得鎖，Follower 可直接獲取，大幅削減行級鎖申請的阻塞時長。
2）減少B+樹的索引遍歷操作
MySQL 依 B + 索引管數據，查詢常需遍歷索引尋目標行，表大層級多則耗時。對熱點行更新分組后，首條 SQL 定位數據存 Row Cache 并修改，后續操作直取緩存改，速減索引遍歷耗時。
3）減少事務提交次數
常規多條 update 語句對應多條事務，各需單獨提交。分組、排隊結合組提交后，一組并發操作完，一次組提交搞定，大大精簡提交次數。
4 總結
在電商秒殺的舞臺上，技術方案需因 “量” 制宜。
若并發量輕柔、數據量微小，數據庫單表輔以加鎖策略即可，確保業務有序運轉，成本低且易維護。
當業務進階，數據量攀升、并發趨高，Redis 與 MQ 攜手登場。Redis 防止超賣；MQ 緩沖請求，削峰填谷，平衡系統負載，二者聯動保障高效穩定。一旦數據海量、并發如潮，Redis + MQ 稍顯吃力，壓力分攤策略必須就位，如同給系統裝上多重緩沖，分散高流量沖擊。
數據量達巔峰時，Redis + MQ + 壓力分攤還需 Inventory Hint 技術助力，深挖數據庫潛能。
總之，業務多樣，技術無萬全之策，唯有貼合場景精挑細選、巧妙組合，才能在秒殺中穩操勝券。
關于作者
趙培龍 采貨俠JAVA開發工程師
