在電商這片紅海，秒殺活動無疑是屢試不爽的流量密碼、銷量利器。然而，在應(yīng)對其并發(fā)請求時，其中的設(shè)計門道暗藏玄機。并發(fā)量小，數(shù)據(jù)庫單表便能一夫當(dāng)關(guān)，穩(wěn)?；顒訜o虞；一旦碰上爆款引爆流量，并發(fā)呈井噴式增長，單表瞬間獨木難支，此時，一套高并發(fā) “抗壓” 組合拳必不可少。接下來，咱們就一起深挖業(yè)界那些屢建奇功的妙招，直擊高并發(fā)痛點，重點解析其中兩大 “硬核” 方案，助你輕松拿捏秒殺場景的技術(shù)難點。

1 業(yè)界通用做法

1.1 壓力分?jǐn)?/span>

在應(yīng)對并發(fā)的挑戰(zhàn)時，利用分桶策略壓力分?jǐn)?/code>，往往受到很多人的青睞。具體而言，面對單品庫存，巧妙地拆分為多組，大大緩解搶購高峰的壓力。但這背后藏著諸多棘手難題，如何精準(zhǔn)地將庫存均勻分配至各桶，杜絕分配不均；怎樣有效處理拆分產(chǎn)生的庫存碎片，避免少賣；分桶間的調(diào)度規(guī)則如何制定，確保協(xié)同高效；還有，業(yè)務(wù)量起伏不定，又該如何實現(xiàn)分桶動態(tài)擴容以靈活適配。這些問題也需要我們進行考慮設(shè)計。

1.2 Redis+MySQL

在秒殺系統(tǒng)的架構(gòu)設(shè)計藍(lán)圖中，Redis 與 MQ 的組合堪稱一對 “黃金搭檔”。Redis 憑借其卓越的高性能讀寫特性以及原子操作能力可以直面秒殺活動帶來的洶涌并發(fā)流量，筑起防止超賣的堅固防線。而 MQ 通過流量削峰策略，將瞬間爆發(fā)的海量數(shù)據(jù)請求進行緩沖與分流，有效減緩后端數(shù)據(jù)存儲環(huán)節(jié)的壓力，確保整個系統(tǒng)節(jié)奏平穩(wěn)。

不過，不少人心中會泛起疑惑：既然 Redis 如此強大，為何不索性全程在 Redis 中完成操作，待秒殺塵埃落定，再一次性將數(shù)據(jù)同步至數(shù)據(jù)庫呢？理論上看似可行，但若置于真實復(fù)雜的業(yè)務(wù)場景之中，便會破綻百出。要知道，用戶成功搶購后，絕非萬事大吉，后續(xù)一系列連貫操作隨即而來，諸如急切地查看搶購結(jié)果，或是迅速進入支付流程等，這些都需要實時、精準(zhǔn)的數(shù)據(jù)交互與支持。

當(dāng)然，采用 Redis + MQ 這套方案并非一勞永逸，其中數(shù)據(jù)一致性問題猶如潛藏暗處的礁石，不容小覷。不過別擔(dān)心，接下來我們就將針對這一方案進行詳細(xì)的介紹。

1.3 Inventory Hint

大家普遍知曉高并發(fā)場景下需精心構(gòu)建復(fù)雜架構(gòu)應(yīng)對挑戰(zhàn)。然而，有一些公司卻看似 “劍走偏鋒”，即便面臨著不容小覷的并發(fā)壓力，依舊選擇直接對數(shù)據(jù)庫進行操作，并未引入那些令人眼花繚亂的高并發(fā)設(shè)計體系，這難免讓人滿腹狐疑。

實則不然，這些公司背后有著強大的技術(shù)支撐 —— 他們選用的是阿里的 RDS 云數(shù)據(jù)庫。這款數(shù)據(jù)庫絕非等閑之輩，它依托阿里的強大技術(shù)底蘊，內(nèi)置了先進的 Inventory Hint 技術(shù)。憑借該技術(shù)對數(shù)據(jù)庫的精準(zhǔn)優(yōu)化，使得這些公司即便在高并發(fā)的槍林彈雨中，也能讓數(shù)據(jù)庫穩(wěn)健運行，輕松應(yīng)對海量數(shù)據(jù)的讀寫請求。下面，咱們也會深入其中，著重揭開這項神奇技術(shù)的神秘面紗，探尋它究竟是如何賦能數(shù)據(jù)庫、化解高并發(fā)難題的。

1.4 壓力分?jǐn)?Redis+MQ

面對數(shù)百萬 QPS 的高壓沖擊，多種技術(shù)方案強強聯(lián)手，才能站穩(wěn)腳跟。SQL 合并執(zhí)行批量處理請求，削減數(shù)據(jù)庫負(fù)荷。緩存陣營更是齊發(fā)力，分布式緩存廣納熱點，本地緩存就近響應(yīng)，近端緩存將分布式緩存與服務(wù)器 “聯(lián)姻”，實現(xiàn)超高速讀取。分桶策略巧妙分流，開辟流量 “綠色通道”。各方案各司其職，分擔(dān)并發(fā)壓力，聚合為強大力量，確保大促活動平穩(wěn)運行。

2 Redis + MQ 解決高并發(fā)下的秒殺場景

2.1 Redis庫存預(yù)扣減

上面我們方案二已經(jīng)介紹過該方案的整體技術(shù)架構(gòu)，接下來我們進行詳細(xì)的剖析。該方案我們主要是通過Redis的Lua腳本進行庫存的扣減，這樣可以保證扣減過程中的原子性和高效性。示例代碼如下：

/*
  * KEYS[1] --商品id
  * KEYS[2] --用戶id uid
  * ARGV[1] --扣減數(shù)量
  * ARGV[2] --用戶提交的  token
  */
String luaScript = "redis.replicate_commands()\n" +
        //防止用戶是否重復(fù)提交，利用 token實現(xiàn)的，每次提交前會生成一個token，token更新前才可繼續(xù)提交
        "if redis.call('hexists', KEYS[2], ARGV[2]) == 1 then\n" +
            //拋出用戶重復(fù)提交的異常
            "return redis.error_reply('repeat submit')\n" +
        "end \n" +
        //商品id
        "local product_id = KEYS[1] \n" +
        //獲取商品id對應(yīng)的庫存
        "local stock = redis.call('get', KEYS[1]) \n" +
        //判斷庫存是否充足
        "if tonumber(stock) < tonumber(ARGV[1]) then \n" +
            //購買的數(shù)量
            "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" +
        //獲取但當(dāng)前系統(tǒng)的時間 返回一個數(shù)組，包含2個元素 第一個元素是當(dāng)前的秒數(shù)，第2個是當(dāng)前這一秒已經(jīng)流逝過的微秒數(shù)
        "local time = redis.call('time') \n" +
        //當(dāng)前時間戳 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腳本執(zhí)行流程：

涉及到的Redis數(shù)據(jù)結(jié)構(gòu)以及對應(yīng)存儲內(nèi)容：

Hash 數(shù)據(jù)結(jié)構(gòu)

String 數(shù)據(jù)結(jié)構(gòu)

2.1.2 Lua腳本主要做了幾件事：

1）防重提交

在秒殺活動中用戶為了能夠搶到想要的商品，會進行瘋狂的點擊，為了防止用戶重復(fù)點擊提交，往往需要做一些冪等性的判斷。用戶在每次點擊提交按鈕前后端會新生成一個token，提交時攜帶上，后端針對token判斷是否已經(jīng)存在，避免重復(fù)下單。

2）庫存扣減

判斷購買的數(shù)據(jù)是否大于庫存，如果是的話，直接返回庫存。如果不是，進行庫存扣減，更新Redis庫存。

3）記錄交易流水

很多人想不明白為啥要進行交易流水的記錄，其實是為了一致性考慮的。可以依據(jù)這條流水記錄去訂單表中去進行查詢，如果查詢不到，說明訂單表中未能成功生成訂單，可能需要人工介入進行處理。

2.2 MySQL庫存扣減

在進行數(shù)據(jù)庫進行庫存扣減的時候，我們是通過RocketMQ的事務(wù)消息實現(xiàn)的，這樣做的目的是為了保證數(shù)據(jù)庫庫存可以扣減成功，如果數(shù)據(jù)庫庫存扣減失敗的話，也會帶來少賣問題。具體分為以下幾步：

1）發(fā)送RocketMQ半消息，此時消息并不能直接消費，需要檢查本地事務(wù)的執(zhí)行結(jié)果。

2） 檢查本地事務(wù)我們是判斷Redis的Lua腳本是否執(zhí)行成功，如果執(zhí)行成功，則返回COMMIT給RocketMQ，如果失敗，則ROLL_BACK消息。

3）RocketMQ為了防止收不到對應(yīng)的本地事務(wù)執(zhí)行結(jié)果會有消息回查機制，我們在消息回查中主要判斷是否有對應(yīng)的流水，如果存在的話，說明可以提交。

4）消費消息，進行數(shù)據(jù)庫庫存的扣減，同時記錄對應(yīng)操作流水。消費時為了保證一致性我們借助的是RocketMQ的消息重試機制，所以此處我們給MQ返回消費ACK時一定要保證我們的數(shù)據(jù)已經(jīng)成功落庫，否則不能隨意返回。

2.3 記錄操作流水的原因

我們在進行完庫存扣減動作之后，對應(yīng)的是下單操作，為了保證下單和庫存的一致性，我們可以用定時對賬機制來核對庫存流水和訂單表中數(shù)據(jù)是否一致。當(dāng)然也有其他一致性保證方案，比如Seata、TCC等，可以根據(jù)具體的業(yè)務(wù)場景選擇。

3 Inventory Hint 數(shù)據(jù)庫扣減

很多公司直接利用阿里云的數(shù)據(jù)庫就完成了秒殺的功能，也就是我們上面介紹的方案三。上文已經(jīng)提到過其底層是依賴Inventory Hint技術(shù)實現(xiàn)的，接下來我們介紹下Inventory Hint技術(shù)的使用以及實現(xiàn)原理。

3.1 使用

Inventory Hint的使用比較簡單，只需要在對應(yīng)的語句上加上特殊的hint語句就行了。具體可以參考阿里云文檔

3.2 原理介紹

其實高并發(fā)下庫存的扣減動作最后瓶頸落在了數(shù)據(jù)庫單行的熱更新上，Inventory Hint技術(shù)就是對熱更新做了相應(yīng)的優(yōu)化。

當(dāng)用Inventory Hint技術(shù)的hint語句標(biāo)記一個SQL后，就相當(dāng)于告訴MySQL內(nèi)核這可能是一行熱更新記錄。于是，MySQL內(nèi)核層就會自動識別帶此類標(biāo)記的更新操作，在一定的時間間隔內(nèi)，將收集到的更新操作按照主鍵或者唯一鍵進行分組，這樣更新相同行的操作就會被分到同一組中。

為了進一步提升性能，在實現(xiàn)上，使用兩個執(zhí)行單元。當(dāng)?shù)谝粋€執(zhí)行單元收集完畢準(zhǔn)備提交時，第二個執(zhí)行單元立即開始收集更新操作；當(dāng)?shù)诙€執(zhí)行單元收集完畢準(zhǔn)備提交時，第一個執(zhí)行單元已經(jīng)提交完畢并開始收集新批的更新操作，兩個單元不斷切換，并行執(zhí)行。

3.2.1 關(guān)鍵優(yōu)化點：

1）減少行級鎖的申請等待

同組更新同一記錄時依 SQL 提交順序排隊，Leader 率先嘗試拿目標(biāo)行鎖，成功即操作，F(xiàn)ollower 拿鎖前先確認(rèn)，若 Leader 已得鎖，F(xiàn)ollower 可直接獲取，大幅削減行級鎖申請的阻塞時長。

2）減少B+樹的索引遍歷操作

MySQL 依 B + 索引管數(shù)據(jù)，查詢常需遍歷索引尋目標(biāo)行，表大層級多則耗時。對熱點行更新分組后，首條 SQL 定位數(shù)據(jù)存 Row Cache 并修改，后續(xù)操作直取緩存改，速減索引遍歷耗時。

3）減少事務(wù)提交次數(shù)

常規(guī)多條 update 語句對應(yīng)多條事務(wù)，各需單獨提交。分組、排隊結(jié)合組提交后，一組并發(fā)操作完，一次組提交搞定，大大精簡提交次數(shù)。

4 總結(jié)

在電商秒殺的舞臺上，技術(shù)方案需因 “量” 制宜。

若并發(fā)量輕柔、數(shù)據(jù)量微小，數(shù)據(jù)庫單表輔以加鎖策略即可，確保業(yè)務(wù)有序運轉(zhuǎn)，成本低且易維護。

當(dāng)業(yè)務(wù)進階，數(shù)據(jù)量攀升、并發(fā)趨高，Redis 與 MQ 攜手登場。Redis 防止超賣；MQ 緩沖請求，削峰填谷，平衡系統(tǒng)負(fù)載，二者聯(lián)動保障高效穩(wěn)定。一旦數(shù)據(jù)海量、并發(fā)如潮，Redis + MQ 稍顯吃力，壓力分?jǐn)偛呗员仨毦臀?，如同給系統(tǒng)裝上多重緩沖，分散高流量沖擊。

數(shù)據(jù)量達(dá)巔峰時，Redis + MQ + 壓力分?jǐn)傔€需 Inventory Hint 技術(shù)助力，深挖數(shù)據(jù)庫潛能。

總之，業(yè)務(wù)多樣，技術(shù)無萬全之策，唯有貼合場景精挑細(xì)選、巧妙組合，才能在秒殺中穩(wěn)操勝券。




關(guān)于作者
趙培龍 采貨俠JAVA開發(fā)工程師