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

1 業(yè)界通用做法

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

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

1.2 Redis+MySQL

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

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

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

1.3 Inventory Hint

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

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

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

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

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

2.1 Redis庫(kù)存預(yù)扣減

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

/*
  * KEYS[1] --商品id
  * KEYS[2] --用戶id uid
  * ARGV[1] --扣減數(shù)量
  * ARGV[2] --用戶提交的  token
  */
String luaScript = "redis.replicate_commands()\n" +
        //防止用戶是否重復(fù)提交，利用 token實(shí)現(xiàn)的，每次提交前會(huì)生成一個(gè)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對(duì)應(yīng)的庫(kù)存
        "local stock = redis.call('get', KEYS[1]) \n" +
        //判斷庫(kù)存是否充足
        "if tonumber(stock) < tonumber(ARGV[1]) then \n" +
            //購(gòu)買的數(shù)量
            "return redis.error_reply('stock is not enough') \n" +
        "end \n" +
        "local remaining_stock = tonumber(stock) - tonumber(ARGV[1]) \n" +
        //更新庫(kù)存
        "redis.call('set', KEYS[1], tostring(remaining_stock)) \n" +
        //獲取但當(dāng)前系統(tǒng)的時(shí)間 返回一個(gè)數(shù)組，包含2個(gè)元素 第一個(gè)元素是當(dāng)前的秒數(shù)，第2個(gè)是當(dāng)前這一秒已經(jīng)流逝過的微秒數(shù)
        "local time = redis.call('time') \n" +
        //當(dāng)前時(shí)間戳 ms
        "local currentTimeMillis = (time[1] * 1000) + math.floor(time[2] / 1000) \n" +
        //存如一條流水 {"change":"1","action":"扣減庫(kù)存","from":"100","token":"token","timestamp":1735293810009,"to":99,"product":"product_id_01"}
        "redis.call('hset', KEYS[2], ARGV[2], \n" +
        "cjson.encode({action = '扣減庫(kù)存', 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)以及對(duì)應(yīng)存儲(chǔ)內(nèi)容：

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

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

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

1）防重提交

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

2）庫(kù)存扣減

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

3）記錄交易流水

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

2.2 MySQL庫(kù)存扣減

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

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

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

3）RocketMQ為了防止收不到對(duì)應(yīng)的本地事務(wù)執(zhí)行結(jié)果會(huì)有消息回查機(jī)制，我們?cè)谙⒒夭橹兄饕袛嗍欠裼袑?duì)應(yīng)的流水，如果存在的話，說明可以提交。

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

2.3 記錄操作流水的原因

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

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

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

3.1 使用

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

3.2 原理介紹

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

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

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

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

1）減少行級(jí)鎖的申請(qǐng)等待

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

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

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

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

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

4 總結(jié)

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

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

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

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

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




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