背景

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

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

(資料圖片僅供參考)

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

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

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

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

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

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

如下圖 1 所示：

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

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

一般來(lái)說(shuō)，我們的 APP 移動(dòng)端對(duì)后端訪問(wèn)都是通過(guò)一個(gè)域名來(lái)發(fā)起請(qǐng)求的，這個(gè)域名會(huì)經(jīng)過(guò) 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ā)給我們的搶購(gòu)系統(tǒng)。

所以大致如下圖 2 所示：

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

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

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

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

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

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

如下圖 3 所示：

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

但是如果說(shuō)搞這么一個(gè)活動(dòng)，某個(gè)特殊商品，限量 10w 份，大家又特別需要他，然后呢，限定就是每天上午 10:00 開(kāi)搶?zhuān)看味加袔资f(wàn)人眼睛放出紅光盯著手機(jī)屏幕準(zhǔn)備搶他，志在必得，這個(gè)時(shí)候，流量會(huì)搞成什么樣子呢？

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

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

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

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

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

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

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

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

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

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

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

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

大家看下圖 5：

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

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

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

如下圖 6 所示：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如下圖 8：

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

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

如下圖 9：

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

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

如下圖 10：

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

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

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

如下圖 11：

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

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

如下圖 12：

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

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

如下圖 13：

總結(jié)

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

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

關(guān)鍵詞： 這個(gè)時(shí)候 這個(gè)問(wèn)題 解決方案 負(fù)載均衡 也就是說(shuō)