背景

大家好，這篇文章給大家介紹一個(gè)非常經(jīng)典的去大廠面試經(jīng)常被問的一個(gè)問題，就是瞬時(shí)高并發(fā)搶購問題。

通常來說，大廠開發(fā)的系統(tǒng)經(jīng)常會(huì)遇到一些類似電商秒殺搶購、景點(diǎn)門票高并發(fā)搶購、特殊商品(比如口罩)高并發(fā)搶購、類似 12306 的高并發(fā)搶票類的系統(tǒng)。

所以經(jīng)常會(huì)問這一類高并發(fā)搶購類的問題，這個(gè)時(shí)候，小伙伴們?nèi)绻荒苡欣碛袚?jù)的給出一整套高并發(fā)場(chǎng)景下系統(tǒng)可能遇到的各種問題，以及你對(duì)應(yīng)的架構(gòu)設(shè)計(jì)和解決方案，那基本面試可能就會(huì)涼掉。

所以今天就手把手帶著大家來分析一下，假設(shè)在特殊物品庫存緊缺的場(chǎng)景下，1 分鐘內(nèi)要搶購 10w 個(gè)口罩這類特殊物品，此時(shí)可能有數(shù)十萬人這個(gè)量級(jí)瞬時(shí)涌入來進(jìn)行搶購，這個(gè)時(shí)候系統(tǒng)可能會(huì)遇到哪些問題，我們應(yīng)該如何來設(shè)計(jì)架構(gòu)解決這類問題呢?

業(yè)務(wù)架構(gòu)設(shè)計(jì)

首先在分析這一類問題的時(shí)候，我們先不要考慮這個(gè)瞬時(shí)高并發(fā)到底有多高，先得把實(shí)現(xiàn)購買這類特殊商品的一個(gè)基礎(chǔ)業(yè)務(wù)架構(gòu)圖畫出來，同時(shí)把業(yè)務(wù)流程分析清楚。

大家看下圖，如果你要搞一個(gè)商品搶購的系統(tǒng)，肯定得有一個(gè)搶購系統(tǒng)，這個(gè)搶購系統(tǒng)你得依賴商品系統(tǒng)吧，畢竟搶購過程中需要對(duì)商品數(shù)據(jù)進(jìn)行讀寫，你還得依賴庫存系統(tǒng)進(jìn)行庫存扣減，同時(shí)你還得依賴價(jià)格系統(tǒng)來計(jì)算當(dāng)前商品的購買價(jià)格，還得依賴營銷系統(tǒng)來驗(yàn)證商品購買的優(yōu)惠。

最后還得依賴鑒權(quán)認(rèn)證、風(fēng)控?cái)r截類的基礎(chǔ)系統(tǒng)來確定本次搶購是否可以執(zhí)行，所以說，一次搶購涉及到的各種系統(tǒng)其實(shí)是很多的，完整的基礎(chǔ)高并發(fā)搶購系統(tǒng)基礎(chǔ)業(yè)務(wù)架構(gòu)圖。

如下圖 1 所示：

圖 1：高并發(fā)搶購系統(tǒng)業(yè)務(wù)架構(gòu)設(shè)計(jì)

網(wǎng)絡(luò)拓?fù)浼軜?gòu)設(shè)計(jì)

另外的話，大家還得對(duì)你的搶購請(qǐng)求是如何一步一步到達(dá)你的搶購系統(tǒng)的，這個(gè)事情流程大家也是要畫出來的。

一般來說，我們的 APP 移動(dòng)端對(duì)后端訪問都是通過一個(gè)域名來發(fā)起請(qǐng)求的，這個(gè)域名會(huì)經(jīng)過 DNS 進(jìn)行解析得到我們的 SLB 負(fù)載均衡系統(tǒng)的 ip 地址。

然后請(qǐng)求會(huì)發(fā)送到我們的 SLB 負(fù)載均衡系統(tǒng)上去，接著 SLB 負(fù)載均衡系統(tǒng)會(huì)把請(qǐng)求均勻分發(fā)給我們后端的 API 網(wǎng)關(guān)系統(tǒng)，然后 API 網(wǎng)關(guān)系統(tǒng)再把流量分發(fā)給我們的搶購系統(tǒng)。

所以大致如下圖 2 所示：

圖 2：高并發(fā)搶購網(wǎng)絡(luò)拓?fù)浼軜?gòu)設(shè)計(jì)

好的，當(dāng)大家能當(dāng)著面試官的面，麻溜兒的把上面那套業(yè)務(wù)架構(gòu)圖和生產(chǎn)部署網(wǎng)絡(luò)拓?fù)鋱D大致畫出來以后，我們可以跟大家保證，雖然這個(gè)時(shí)候面試官看起來面無表情，但是心里的真實(shí)反映應(yīng)該是這樣的：小兄弟可以啊，一般人聽到這個(gè)問題就直接懵逼了，這小子居然知道先從業(yè)務(wù)架構(gòu)和網(wǎng)絡(luò)拓?fù)浼軜?gòu)入手進(jìn)行分析。

但是大家別高興的太早，距離你圓滿的完成這個(gè)問題的分析，大致是才剛剛走完了西游記十萬八千里中的八千里而已，剩下的十萬還要繼續(xù)走呢!這一路上大家馬上要遇到各種妖魔鬼怪了!打起精神，接著一起來往下看。

秒殺業(yè)務(wù)流量洪峰

往往到這里，我們下一步應(yīng)該分析的，就是日常流量和搶購流量的區(qū)別了，什么意思呢?

先來說說日常流量，這個(gè)意思就是說，平時(shí)沒有搶購的時(shí)候，就是別人正常來買各種商品，系統(tǒng)的大致流量應(yīng)該是每秒會(huì)有多少請(qǐng)求。

這個(gè)問題的話，不大好說，因?yàn)椴煌墓酒鋵?shí)是不太一樣的，但是我們可以取一個(gè)較為中間的值，整個(gè)系統(tǒng)日常的話每秒也就 1000 次請(qǐng)求，這個(gè)是比較中肯的一個(gè)值，不高也不低。

如下圖 3 所示：

圖 3：日常并發(fā)搶購系統(tǒng)業(yè)務(wù)流量情況

一般來說，但凡你的搶購系統(tǒng)以及他依賴的每個(gè)系統(tǒng)部署在 2 臺(tái)機(jī)器以上，每秒 1000 次請(qǐng)求這種常規(guī)流量，各個(gè)系統(tǒng)兄弟們同心協(xié)力，一起扛一抗，還是沒太大問題的。

但是如果說搞這么一個(gè)活動(dòng)，某個(gè)特殊商品，限量 10w 份，大家又特別需要他，然后呢，限定就是每天上午 10:00 開搶，每次都有幾十萬人眼睛放出紅光盯著手機(jī)屏幕準(zhǔn)備搶他，志在必得，這個(gè)時(shí)候，流量會(huì)搞成什么樣子呢?

注意，重頭戲來了，大體上來說，根據(jù)一般的搶購經(jīng)驗(yàn)，往往你的 10w 件商品會(huì)在 1 分鐘內(nèi)搶光，而且根據(jù)二八法則，80% 的商品會(huì)在 20% 的時(shí)間內(nèi)被搶光。

也就是說 8w 件商品可能會(huì)在 10s 內(nèi)被搶購，而且參與搶購這 8w 件商品的流量達(dá)到了 80% 的人群數(shù)量，假設(shè)一共有 50w 人參與搶購，就是有 40w 人在 10s 內(nèi)發(fā)起搶購請(qǐng)求，搶光了 8w 件商品。

這個(gè)時(shí)候，每秒的請(qǐng)求數(shù)量應(yīng)該是 40w/10s = 4w/s 的 QPS，大家看下圖 4：

圖 4：高并發(fā)搶購系統(tǒng)業(yè)務(wù)流量情況

不知道大家看到上圖是何感想?腦子別發(fā)蒙啊，面試官聽得津津有味，咱們趕緊繼續(xù)往下講啊，不然你這時(shí)候停下來，你們會(huì)大眼瞪小眼的!那這個(gè)時(shí)候如果對(duì)你的搶購系統(tǒng)發(fā)起的請(qǐng)求量達(dá)到了每秒 4w，大家覺得會(huì)如何呢?

很簡(jiǎn)單，系統(tǒng)絕對(duì)會(huì)被打死，網(wǎng)絡(luò)帶寬打滿、CPU 使用率達(dá)到 90% 多、數(shù)據(jù)庫負(fù)載過高、下游依賴頻繁超時(shí)，這一切問題都可能會(huì)發(fā)生，你要問為什么?

那就是因?yàn)槟愕南到y(tǒng)常規(guī)化部署下，就是抗每秒 1000 的請(qǐng)求的，他們又不是設(shè)計(jì)來抗你每秒 4w 請(qǐng)求的。

架構(gòu)設(shè)計(jì)優(yōu)化

所以這個(gè)時(shí)候問題就牽扯到了一個(gè)點(diǎn)，那就是怎么才能讓你的搶購系統(tǒng)可以抗下來每秒 4w 請(qǐng)求呢?

為了解決這個(gè)問題，就得趁著面試官打瞌睡的時(shí)候，咱兄弟偷偷給你傳授一點(diǎn)武林秘籍了。

正常情況下，一臺(tái) 4 核 8G 的機(jī)器，開 200 個(gè)線程處理請(qǐng)求，如果他要調(diào)用別的服務(wù)，或者是訪問數(shù)據(jù)庫，基本上每秒單臺(tái)機(jī)器也就抗個(gè) 1000 的請(qǐng)求量。

并發(fā)搶購系統(tǒng)性能瓶頸分析

但是，注意，敲黑板劃重點(diǎn)了，不是說你的 4 核 8G 機(jī)器就菜雞到了只能抗每秒 1000 個(gè)請(qǐng)求，他的關(guān)鍵問題在于，他要調(diào)用別的服務(wù)，而且他還要訪問數(shù)據(jù)庫，就是因?yàn)檫@種通過網(wǎng)絡(luò)去訪問外部系統(tǒng)，才導(dǎo)致了他每秒抗的請(qǐng)求量比較菜雞一些。

大家看下圖 5：

圖 5：并發(fā)搶購系統(tǒng)性能瓶頸

大家要知道一點(diǎn)，類似 Redis、RocketMQ 這種中間件系統(tǒng)，經(jīng)過深度優(yōu)化之后，往往單臺(tái)抗個(gè)上萬甚至幾萬 QPS 都沒問題，所謂的深度優(yōu)化是什么意思?

簡(jiǎn)而言之就一點(diǎn)，你最好就是每次請(qǐng)求過來，完全就基于自己的內(nèi)存來讀寫數(shù)據(jù)，然后就直接返回了。

不要隨便通過網(wǎng)絡(luò)去訪問外部的系統(tǒng)，這種情況下，往往你的并發(fā)量可以提升幾個(gè)數(shù)量級(jí)。

如下圖 6 所示：

圖 6：并發(fā)搶購系統(tǒng)架構(gòu)深度優(yōu)化

并發(fā)搶購系統(tǒng)架構(gòu)優(yōu)化

所以說，一般這種場(chǎng)景下，有三個(gè)非常強(qiáng)悍的優(yōu)化手段，那就是大幅度減少對(duì)外部服務(wù)的依賴調(diào)用嗎;寫數(shù)據(jù)盡量直接寫緩存，然后異步寫 DB;讀數(shù)據(jù)盡量優(yōu)先把數(shù)據(jù)緩存在系統(tǒng) JVM 內(nèi)存里，本地讀取返回。

這里可以給大家舉一些例子，比如說，對(duì)于特殊商品固定價(jià)格搶購，那么對(duì)價(jià)格系統(tǒng)、營銷系統(tǒng)的調(diào)用是否就可以省略了，畢竟價(jià)格固定，也沒有優(yōu)惠這一說。

對(duì)于風(fēng)控和鑒權(quán)類的通用操作，是否可以前置到 API 網(wǎng)關(guān)層面讓他去執(zhí)行，從我們的業(yè)務(wù)系統(tǒng)里移除這類通用邏輯?這不就一下子減少了對(duì) 4 個(gè)系統(tǒng)的調(diào)用了。

再比如說，對(duì)庫存的扣減，是否可以讓庫存系統(tǒng)把數(shù)據(jù)同步到 Redis 里，我們直接同步扣 Redis 里的庫存，然后發(fā) MQ 消息異步去庫存系統(tǒng)的 DB 里扣庫存?

還有比如對(duì)商品數(shù)據(jù)的大量查詢，是否可以將商品數(shù)據(jù)緩存到 Redis 里，同時(shí)對(duì)熱門商品數(shù)據(jù)全部提前加載到搶購系統(tǒng)的 JVM 內(nèi)存里本地緩存?

經(jīng)過優(yōu)化后的搶購系統(tǒng)大致看起來是下面圖 7 這樣子的：

圖 7：并發(fā)搶購系統(tǒng)架構(gòu)緩存優(yōu)化

大家看上圖，這個(gè)時(shí)候經(jīng)過一通優(yōu)化之后，我們的搶購系統(tǒng)已經(jīng)不再直接調(diào)用任何服務(wù)了。

他在讀商品數(shù)據(jù)的時(shí)候，優(yōu)先都是從自己的 JVM 本地緩存里讀取預(yù)緩存的數(shù)據(jù)，幾乎就是純內(nèi)存操作，然后扣減庫存是去寫 Redis 的，對(duì)于庫存系統(tǒng)甚至是訂單系統(tǒng)的數(shù)據(jù)庫中的扣減庫存和下單，都是通過 MQ 異步化執(zhí)行的。

基本上系統(tǒng)優(yōu)化到這個(gè)水準(zhǔn)，主要給搶購系統(tǒng)多部署幾臺(tái)機(jī)器，就可以抗下每秒幾萬高并發(fā)的請(qǐng)求了。

但是這個(gè)時(shí)候完了嗎?當(dāng)然沒有，這個(gè)時(shí)候系統(tǒng)里存在的問題還非常的多，我們得繼續(xù)往下分析，進(jìn)一步一步一步的優(yōu)化。

①高并發(fā)搶購系統(tǒng)緩存擊穿問題分析與解決方案

首先，分析第一個(gè)問題，就是商品數(shù)據(jù)緩存在搶購系統(tǒng) JVM 本地緩存時(shí)的擊穿問題，我們?cè)趽屬徬到y(tǒng)的 JVM 本地緩存中放的數(shù)據(jù)，一般都是要設(shè)置一個(gè)過期時(shí)間的，因?yàn)槿绻阋恢本彺嬖?JVM 里，會(huì)導(dǎo)致商品數(shù)據(jù)有變化了，你也不知道。

所以假設(shè)我們?cè)O(shè)置一個(gè) 30min 的過期時(shí)間，每隔 30min 過期下，過期之后，搶購系統(tǒng)就得去 Redis 里查商品數(shù)據(jù)緩存，如果沒查到，那就得去調(diào)用商品系統(tǒng)的接口從數(shù)據(jù)庫里查了。

如下圖 8：

圖 8：高并發(fā)搶購系統(tǒng) — 緩存數(shù)據(jù)過期問題

那么當(dāng)你的搶購系統(tǒng)里的本地緩存過期了，此時(shí)本地緩存沒數(shù)據(jù)了，然后 Redis 里緩存可能此時(shí)也沒有的時(shí)候，就在這個(gè)非常要緊的關(guān)頭，偏偏就進(jìn)來了大量的請(qǐng)求，此時(shí)這大量請(qǐng)求在本地緩存都沒找到，去 Redis 里也沒找到，然后呢?

然后當(dāng)然就是完?duì)僮恿?，因?yàn)檫@些請(qǐng)求都會(huì)涌入到商品系統(tǒng)里去，讓商品系統(tǒng)從數(shù)據(jù)庫里查詢，直接把商品系統(tǒng)擊穿。

如下圖 9：

圖 9：高并發(fā)搶購系統(tǒng) — 緩存擊穿問題

所以這個(gè)時(shí)候，我們往往需要對(duì)這種本地緩存做一個(gè)特殊的方案設(shè)計(jì)，那就是對(duì)于本地緩存不要采取這種讓他自動(dòng)過期然后請(qǐng)求過來的時(shí)候讀取不到再去商品系統(tǒng)那里查找的模式，而是采取搶購系統(tǒng)針對(duì)本地緩存自動(dòng)定時(shí)刷新。

也就是說，搶購系統(tǒng)內(nèi)可以開一個(gè)后臺(tái)線程，然后讓他每隔 30min 自動(dòng)去 Redis 里查最新緩存數(shù)據(jù)，或者去商品系統(tǒng)查最新緩存數(shù)據(jù)，然后刷新本地緩存，這樣就可以避免說自動(dòng)過期后突然大量請(qǐng)求查不到緩存都涌入商品系統(tǒng)了。

如下圖 10：

圖 10：高并發(fā)搶購系統(tǒng) — 緩存自動(dòng)刷新機(jī)制

②高并發(fā)搶購系統(tǒng)數(shù)據(jù)不一致問題分析與解決方案

再來看下一個(gè)比較常見的問題，就是扣庫存的緩存與 DB 不一致問題，這個(gè)問題的場(chǎng)景可能發(fā)生在如下情況。

就是說你在 Redis 里扣完了庫存之后，通過 MQ 發(fā)送了一個(gè)消息異步讓那個(gè)庫存系統(tǒng)在 DB 里扣庫存，可是人家?guī)齑嫦到y(tǒng)還沒在 DB 里扣減呢，這個(gè)時(shí)候你突然因?yàn)楫惓；貪L了這次庫存扣減，此時(shí) Redis 里把扣的庫存恢復(fù)了，然后發(fā)了一個(gè)消息到 MQ 去恢復(fù)庫存扣減。

如下圖 11：

圖 11：高并發(fā)搶購系統(tǒng) — 數(shù)據(jù)不一致問題(一)

但是這個(gè)時(shí)候 Redis 里的庫存是恢復(fù)了，可是庫存系統(tǒng) DB 那里就是未必了，因?yàn)閹齑嫦到y(tǒng)從 MQ 里獲取消息的時(shí)候，很有可能是亂序獲取的，就是先獲取到恢復(fù)庫存的消息。

此時(shí)庫存系統(tǒng)一般會(huì)判斷一下，之前是否對(duì)這次搶購有過庫存扣減日志，如果沒有，他就不會(huì)去恢復(fù)庫存，然后接著再獲取到扣減庫存的消息，此時(shí)他就扣減了庫存，可是恢復(fù)庫存的消息再也沒機(jī)會(huì)處理了。

如下圖 12：

圖 12：高并發(fā)搶購系統(tǒng) — 數(shù)據(jù)不一致問題(二)

那么上面會(huì)導(dǎo)致什么呢?會(huì)導(dǎo)致 Redis 里扣減了庫存，又恢復(fù)了庫存，可是庫存系統(tǒng)的 DB 里先獲取了恢復(fù)庫存指令，結(jié)果什么都沒干，然后又獲取了扣減庫存指令，反而把庫存給扣了，此時(shí)緩存和 DB 里的庫存是不一致的。

所以針對(duì)這個(gè)問題，通常都會(huì)實(shí)現(xiàn) MQ 順序消息，也就是說，把同一個(gè)搶購訂單的多個(gè)庫存操作指令發(fā)送到 MQ 的一個(gè)分區(qū)里去，讓他們實(shí)現(xiàn)有序，強(qiáng)制要求庫存系統(tǒng)必須按照順序依次獲取后執(zhí)行，這樣就會(huì)先執(zhí)行扣減庫存指令，再執(zhí)行恢復(fù)庫存指令了。

如下圖 13：

圖 13：高并發(fā)搶購系統(tǒng) — MQ 順序消息

總結(jié)

好了，今天這篇文章到這里為止，就給大家講了一下大廠里我們經(jīng)常遇到的高并發(fā)搶購類系統(tǒng)的架構(gòu)設(shè)計(jì)和優(yōu)化過程，以及緩存擊穿與數(shù)據(jù)亂序不一致問題的分析和解決方案。

希望大家在閱讀后能在未來面試遇到這類問題的時(shí)候，有理有據(jù)的逐步分析逐步展開，讓面試官看到大家沉穩(wěn)如水、細(xì)致如絲的應(yīng)變能力。