背景

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

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

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

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

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

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

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

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

如下圖 1 所示：

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

網(wǎng)絡(luò)拓撲架構(gòu)設(shè)計

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

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

然后請求會發(fā)送到我們的 SLB 負載均衡系統(tǒng)上去，接著 SLB 負載均衡系統(tǒ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ò)拓撲架構(gòu)設(shè)計

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

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

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

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

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

這個問題的話，不大好說，因為不同的公司其實是不太一樣的，但是我們可以取一個較為中間的值，整個系統(tǒng)日常的話每秒也就 1000 次請求，這個是比較中肯的一個值，不高也不低。

如下圖 3 所示：

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

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

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

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

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

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

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

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

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

那就是因為你的系統(tǒng)常規(guī)化部署下，就是抗每秒 1000 的請求的，他們又不是設(shè)計來抗你每秒 4w 請求的。

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

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

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

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

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

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

大家看下圖 5：

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

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

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

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

如下圖 6 所示：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先，分析第一個問題，就是商品數(shù)據(jù)緩存在搶購系統(tǒng) JVM 本地緩存時的擊穿問題，我們在搶購系統(tǒng)的 JVM 本地緩存中放的數(shù)據(jù)，一般都是要設(shè)置一個過期時間的，因為如果你一直緩存在 JVM 里，會導(dǎo)致商品數(shù)據(jù)有變化了，你也不知道。

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

如下圖 8：

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

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

然后當然就是完犢子了，因為這些請求都會涌入到商品系統(tǒng)里去，讓商品系統(tǒng)從數(shù)據(jù)庫里查詢，直接把商品系統(tǒng)擊穿。

如下圖 9：

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

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

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

如下圖 10：

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

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

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

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

如下圖 11：

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

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

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

如下圖 12：

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

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

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

如下圖 13：

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

總結(jié)

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

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