一、的背景引入

?這篇文章，我們聊聊大量同學(xué)問我的一個(gè)問題，面試的時(shí)候被問到一個(gè)讓人特別手足無措的問題：你的系統(tǒng)如何支撐高并發(fā)？

大多數(shù)同學(xué)被問到這個(gè)問題壓根兒沒什么思路去回答，不知道從什么地方說起，其實(shí)本質(zhì)就是沒經(jīng)歷過一些真正有高并發(fā)系統(tǒng)的錘煉罷了。

因?yàn)闆]有過相關(guān)的項(xiàng)目經(jīng)歷，所以就沒法從真實(shí)的自身體會(huì)和經(jīng)驗(yàn)中提煉出一套回答，然后系統(tǒng)的闡述出來自己復(fù)雜過的系統(tǒng)如何支撐高并發(fā)的。

所以，這篇文章就從這個(gè)角度切入來簡(jiǎn)單說說這個(gè)問題，用一個(gè)最簡(jiǎn)單的思路來回答，大致如何應(yīng)對(duì)。

當(dāng)然這里首先說清楚一個(gè)前提：高并發(fā)系統(tǒng)各不相同。比如每秒百萬并發(fā)的中間件系統(tǒng)、每日百億請(qǐng)求的網(wǎng)關(guān)系統(tǒng)、瞬時(shí)每秒幾十萬請(qǐng)求的秒殺大促系統(tǒng)。

他們?cè)趹?yīng)對(duì)高并發(fā)的時(shí)候，因?yàn)橄到y(tǒng)各自?自身特點(diǎn)的不同，所以應(yīng)對(duì)架構(gòu)都是不一樣的。

另外，比如電商平臺(tái)中的訂單系統(tǒng)、商品系統(tǒng)、庫存系統(tǒng)，在高并發(fā)場(chǎng)景下的架構(gòu)設(shè)計(jì)也是不同的，因?yàn)楸澈蟮臉I(yè)務(wù)場(chǎng)景什么的都不一樣。

所以，這篇文章主要是給大家提供一個(gè)回答這類問題的思路，不涉及任何復(fù)雜架構(gòu)設(shè)計(jì)，讓你不至于在面試中被問到這個(gè)問題時(shí)，跟面試官大眼瞪小眼。

具體要真能在面試的時(shí)候回答好這個(gè)問題，建議各位參考一下本文思路，然后對(duì)你自己手頭負(fù)責(zé)的系統(tǒng)多去思考一下，最好做一些相關(guān)的架構(gòu)實(shí)踐。

二、先考慮一個(gè)最簡(jiǎn)單的系統(tǒng)架構(gòu)

假設(shè)剛剛開始你的系統(tǒng)就部署在一臺(tái)機(jī)器上，背后就連接了一臺(tái)數(shù)據(jù)庫，數(shù)據(jù)庫部署在一臺(tái)服務(wù)器上。

我們甚至可以再現(xiàn)實(shí)點(diǎn)，給個(gè)例子，你的系統(tǒng)部署的機(jī)器是4核8G，數(shù)據(jù)庫服務(wù)器是16核32G。

此時(shí)假設(shè)你的系統(tǒng)用戶量總共就10萬，用戶量很少，日活用戶按照不同系統(tǒng)的場(chǎng)景有區(qū)別，我們?nèi)∫粋€(gè)較為客觀的比例，10%吧，每天活躍的用戶就1萬。

按照28法則，每天高峰期算他4個(gè)小時(shí)，高峰期活躍的用戶占比達(dá)到80%，就是8000人活躍在4小時(shí)內(nèi)。

然后每個(gè)人對(duì)你的系統(tǒng)發(fā)起的請(qǐng)求，我們算他每天是20次吧。那么高峰期8000人發(fā)起的請(qǐng)求也才16萬次，平均到4小時(shí)內(nèi)的每秒（14400秒），每秒也就10次請(qǐng)求。

好吧！完全跟高并發(fā)搭不上邊，對(duì)不對(duì)？

然后系統(tǒng)層面每秒是10次請(qǐng)求，對(duì)數(shù)據(jù)庫的調(diào)用每次請(qǐng)求都會(huì)好幾次數(shù)據(jù)庫操作的，比如做做crud之類的。

那么我們?nèi)∫粋€(gè)一次請(qǐng)求對(duì)應(yīng)3次數(shù)據(jù)庫請(qǐng)求吧，那這樣的話，數(shù)據(jù)庫層每秒也就30次請(qǐng)求，對(duì)不對(duì)？

按照這臺(tái)數(shù)據(jù)庫服務(wù)器的配置，支撐是絕對(duì)沒問題的。

上述描述的系統(tǒng)，用一張圖表示，就是下面這樣：

三、系統(tǒng)集群化部署

假設(shè)此時(shí)你的用戶數(shù)開始快速增長，比如注冊(cè)用戶量增長了50倍，上升到了500萬。

此時(shí)日活用戶是50萬，高峰期對(duì)系統(tǒng)每秒請(qǐng)求是500/s。然后對(duì)數(shù)據(jù)庫的每秒請(qǐng)求數(shù)量是1500/s，這個(gè)時(shí)候會(huì)怎么樣呢？

按照上述的機(jī)器配置來說，如果你的系統(tǒng)內(nèi)處理的是較為復(fù)雜的一些業(yè)務(wù)邏輯，是那種重業(yè)務(wù)邏輯的系統(tǒng)的話，是比較耗費(fèi)CPU的。

此時(shí)，4核8G的機(jī)器每秒請(qǐng)求達(dá)到500/s的時(shí)候，很可能你會(huì)發(fā)現(xiàn)你的機(jī)器CPU負(fù)載較高了。

然后數(shù)據(jù)庫層面，以上述的配置而言，其實(shí)基本上1500/s的高峰請(qǐng)求壓力的話，還算可以接受。

這個(gè)主要是要觀察數(shù)據(jù)庫所在機(jī)器的磁盤負(fù)載、網(wǎng)絡(luò)負(fù)載、CPU負(fù)載、內(nèi)存負(fù)載，按照我們的線上經(jīng)驗(yàn)而言，那個(gè)配置的數(shù)據(jù)庫在1500/s請(qǐng)求壓力下是沒?問題的。

所以此時(shí)你需要做的一個(gè)事情，首先就是要支持你的系統(tǒng)集群化部署。

你可以在前面掛一個(gè)負(fù)載均衡層，把請(qǐng)求均勻打到系統(tǒng)層面，讓系統(tǒng)可以用多臺(tái)機(jī)器集群化支撐更高的并發(fā)壓力。

比如說這里假設(shè)給系統(tǒng)增加部署一臺(tái)機(jī)器，那么每臺(tái)機(jī)器就只有250/s的請(qǐng)求了。

這樣一來，兩臺(tái)機(jī)器的CPU負(fù)載都會(huì)明顯降低，這個(gè)初步的“高并發(fā)”不就先cover住了嗎？

要是連這個(gè)都不做，那單臺(tái)機(jī)器負(fù)載越來越高的時(shí)候，極端情況下是可能出現(xiàn)機(jī)器上部署的系統(tǒng)無法有足夠的資源響應(yīng)請(qǐng)求了，然后出現(xiàn)請(qǐng)求卡死，甚至系統(tǒng)宕機(jī)之類的問題。

所以，簡(jiǎn)單小結(jié)，第一步要做的：

0. 添加負(fù)載均衡層，將請(qǐng)求均勻打到系統(tǒng)層。
1. 系統(tǒng)層采用集群化部署多臺(tái)機(jī)器，扛住初步的并發(fā)壓力。?

此時(shí)的架構(gòu)圖變成下面的樣子：

四、數(shù)據(jù)庫分庫分表 + 讀寫分離

?假設(shè)此時(shí)用戶量繼續(xù)增長，達(dá)到了1000萬注冊(cè)用戶，然后每天日活用戶是100萬。

那么此時(shí)對(duì)系統(tǒng)層面的請(qǐng)求量會(huì)達(dá)到每秒1000/s，系統(tǒng)層面，你可以繼續(xù)通過集群化的方式來擴(kuò)容，反正前面的負(fù)載均衡層會(huì)均勻分散流量過去的。

但是，這時(shí)數(shù)據(jù)庫層面接受的請(qǐng)求量會(huì)達(dá)到3000/s，這個(gè)就有點(diǎn)問題了。

此時(shí)數(shù)據(jù)庫層面的并發(fā)請(qǐng)求翻了一倍，你一定會(huì)發(fā)現(xiàn)線上的數(shù)據(jù)庫負(fù)載越來越高。

每次到了高峰期，磁盤IO、網(wǎng)絡(luò)IO、內(nèi)存消耗、CPU負(fù)載的壓力都會(huì)很高，大家很擔(dān)心數(shù)據(jù)庫服務(wù)器能否抗住。

沒錯(cuò)，一般來說，對(duì)那種普通配置的線上數(shù)據(jù)庫，建議就是讀寫并發(fā)加起來，按照上述我們舉例的那個(gè)配置，不要超過3000/s。

因?yàn)閿?shù)據(jù)庫壓力過大，首先一個(gè)問題就是高峰期系統(tǒng)性能可能會(huì)降低，因?yàn)閿?shù)據(jù)庫負(fù)載過高對(duì)性能會(huì)有影響。?

另外一個(gè)，壓力過大把你的數(shù)據(jù)庫給搞掛了怎么辦？

所以此時(shí)你必須得對(duì)系統(tǒng)做分庫分表 + 讀寫分離，也就是把一個(gè)庫拆分為多個(gè)庫，部署在多個(gè)數(shù)據(jù)庫服務(wù)上，這是作為主庫承載寫入請(qǐng)求的。

然后每個(gè)主庫都掛載至少一個(gè)從庫，由從庫來承載讀請(qǐng)求。

此時(shí)假設(shè)對(duì)數(shù)據(jù)庫層面的讀寫并發(fā)是3000/s，其中寫并發(fā)占到了1000/s，讀并發(fā)占到了2000/s。

那么一旦分庫分表之后，采用兩臺(tái)數(shù)據(jù)庫服務(wù)器上部署主庫來支撐寫請(qǐng)求，每臺(tái)服務(wù)器承載的寫并發(fā)就是500/s。每臺(tái)主庫掛載一個(gè)服務(wù)器部署從庫，那么2個(gè)從庫每個(gè)從庫支撐的讀并發(fā)就是1000/s。

簡(jiǎn)單總結(jié)，并發(fā)量繼續(xù)增長時(shí)，我們就需要focus在數(shù)據(jù)庫層面：分庫分表、讀寫分離。

此時(shí)的架構(gòu)圖如下所示：

五、緩存集群引入

?接著就好辦了，如果你的注冊(cè)用戶量越來越大，此時(shí)你可以不停的加機(jī)器，比如說系統(tǒng)層面不停加機(jī)器，就可以承載更高的并發(fā)請(qǐng)求。

然后數(shù)據(jù)庫層面如果寫入并發(fā)越來越高，就擴(kuò)容加數(shù)據(jù)庫服務(wù)器，通過分庫分表是可以支持?jǐn)U容機(jī)器的，如果數(shù)據(jù)庫層面的讀并發(fā)越來越高，就擴(kuò)容加更多的從庫。

但是這里有一個(gè)很大的問題：數(shù)據(jù)庫其實(shí)本身不是用來承載高并發(fā)請(qǐng)求的，所以通常來說，數(shù)據(jù)庫單機(jī)每秒承載的并發(fā)就在幾千的數(shù)量級(jí)，而且數(shù)據(jù)庫使用的機(jī)器都是比較高配置，比較昂貴的機(jī)器，成本很高。

如果你就是簡(jiǎn)單的不停的加機(jī)器，其實(shí)是不對(duì)的。

所以在高并發(fā)架構(gòu)里通常都有緩存這個(gè)環(huán)節(jié)，緩存系統(tǒng)的設(shè)計(jì)就是為了承載高并發(fā)而生。

所以單機(jī)承載的并發(fā)量都在每秒幾萬，甚至每秒數(shù)十萬，對(duì)高并發(fā)的承載能力比數(shù)據(jù)庫系統(tǒng)要高出一到兩個(gè)數(shù)量級(jí)。

所以你完全可以根據(jù)系統(tǒng)的業(yè)務(wù)特性，對(duì)那種寫少讀多的請(qǐng)求，引入緩存集群。?

具體來說，就是在寫數(shù)據(jù)庫的時(shí)候同時(shí)寫一份數(shù)據(jù)到緩存集群里，然后用緩存集群來承載大部分的讀請(qǐng)求。

這樣的話，通過緩存集群，就可以用更少的機(jī)器資源承載更高的并發(fā)。

比如說上面那個(gè)圖里，讀請(qǐng)求目前是每秒2000/s，兩個(gè)從庫各自抗了1000/s讀請(qǐng)求，但是其中可能每秒1800次的讀請(qǐng)求都是可以直接讀緩存里的不怎么變化的數(shù)據(jù)的。

那么此時(shí)你一旦引入緩存集群，就可以抗下來這1800/s讀請(qǐng)求，落到數(shù)據(jù)庫層面的讀請(qǐng)求就200/s。

同樣，給大家來一張架構(gòu)圖，一起來感受一下：

按照上述架構(gòu)，他的好處是什么呢？

可能未來你的系統(tǒng)讀請(qǐng)求每秒都幾萬次了，但是可能80%~90%都是通過緩存集群來讀的，而緩存集群里的機(jī)器可能單機(jī)每秒都可以支撐幾萬讀請(qǐng)求，所以耗費(fèi)機(jī)器資源很少，可能就兩三臺(tái)機(jī)器就夠了。

你要是換成是數(shù)據(jù)庫來試一下，可能就要不停的加從庫到10臺(tái)、20臺(tái)機(jī)器才能抗住每秒幾萬的讀并發(fā)，那個(gè)成本是極高的。

好了，我們?cè)賮砗?jiǎn)單小結(jié)，承載高并發(fā)需要考慮的第三個(gè)點(diǎn)：

• 不要盲目進(jìn)行數(shù)據(jù)庫擴(kuò)容，數(shù)據(jù)庫服務(wù)器成本昂貴，且本身就不是用來承載高并發(fā)的
• 針對(duì)寫少讀多的請(qǐng)求，引入緩存集群，用緩存集群抗住大量的讀請(qǐng)求

六、引入消息中間件集群

接著再來看看數(shù)據(jù)庫寫這塊的壓力，其實(shí)是跟讀類似的。

假如說你所有寫請(qǐng)求全部都落地?cái)?shù)據(jù)庫的主庫層，當(dāng)然是沒問題的，但是寫壓力要是越來越大了呢？

比如每秒要寫幾萬條數(shù)據(jù)，此時(shí)難道也是不停的給主庫加機(jī)器嗎？

可以當(dāng)然也可以，但是同理，你耗費(fèi)的機(jī)器資源是很大的，這個(gè)就是數(shù)據(jù)庫系統(tǒng)的特點(diǎn)所決定的。

相同的資源下，數(shù)據(jù)庫系統(tǒng)太重太復(fù)雜，所以并發(fā)承載能力就在幾千/s的量級(jí)，所以此時(shí)你需要引入別的一些技術(shù)。

比如說消息中間件技術(shù)，也就是MQ集群，他是非常好的做寫請(qǐng)求異步化處理，實(shí)現(xiàn)削峰填谷的效果。

假如說，你現(xiàn)在每秒是1000/s次寫請(qǐng)求，其中比如500次請(qǐng)求是必須請(qǐng)求過來立馬寫入數(shù)據(jù)庫中的，但是另外500次寫請(qǐng)求是可以允許異步化等待個(gè)幾十秒，甚至幾分鐘后才落入數(shù)據(jù)庫內(nèi)的。

那么此時(shí)你完全可以引入消息中間件集群，把允許異步化的每秒500次請(qǐng)求寫入MQ，然后基于MQ做一個(gè)削峰填谷。比如就以平穩(wěn)的100/s的速度消費(fèi)出來然后落入數(shù)據(jù)庫中即可，此時(shí)就會(huì)大幅度降低數(shù)據(jù)庫的寫入壓力。

ps：關(guān)于MQ削峰填谷的概念，在公眾號(hào)之前講消息中間件的文章中已詳細(xì)闡述，如果大伙兒忘記了，可以回顧一下。

此時(shí)，架構(gòu)圖變成了下面這樣：

大家看上面的架構(gòu)圖，首先消息中間件系統(tǒng)本身也是為高并發(fā)而生，所以通常單機(jī)都是支撐幾萬甚至十萬級(jí)的并發(fā)請(qǐng)求的。

所以，他本身也跟緩存系統(tǒng)一樣，可以用很少的資源支撐很高的并發(fā)請(qǐng)求，用他來支撐部分允許異步化的高并發(fā)寫入是沒問題的，比使用數(shù)據(jù)庫直接支撐那部分高并發(fā)請(qǐng)求要減少很多的機(jī)器使用量。

而且經(jīng)過消息中間件的削峰填谷之后，比如就用穩(wěn)定的100/s的速度寫數(shù)據(jù)庫，那么數(shù)據(jù)庫層面接收的寫請(qǐng)求壓力，不就成了500/s + 100/s = 600/s了么？

大家看看，是不是發(fā)現(xiàn)減輕了數(shù)據(jù)庫的壓力？

到目前為止，通過下面的手段，我們已經(jīng)可以讓系統(tǒng)架構(gòu)盡可能用最小的機(jī)器資源抗住了最大的請(qǐng)求壓力，減輕了數(shù)據(jù)庫的負(fù)擔(dān)。

• 系統(tǒng)集群化
• 數(shù)據(jù)庫層面的分庫分表+讀寫分離
• 針對(duì)讀多寫少的請(qǐng)求，引入緩存集群
• 針對(duì)高寫入的壓力，引入消息中間件集群，

初步來說，簡(jiǎn)單的一個(gè)高并發(fā)系統(tǒng)的闡述是說完了。

但是，其實(shí)故事到這里還遠(yuǎn)遠(yuǎn)沒有結(jié)束。

七、現(xiàn)在能hold住高并發(fā)面試題了嗎？

看完了這篇文章，你覺得自己能回答好面試?yán)锏母卟l(fā)問題了嗎？

很遺憾，答案是不能。而且我覺得單單憑借幾篇文章是絕對(duì)不可能真的讓你完全回答好這個(gè)問題的，這里有很多原因在里面。

首先，高并發(fā)這個(gè)話題本身是非常復(fù)雜的，遠(yuǎn)遠(yuǎn)不是一些文章可以說的清楚的，他的本質(zhì)就在于，真實(shí)的支撐復(fù)雜業(yè)務(wù)場(chǎng)景的高并發(fā)系統(tǒng)架構(gòu)其實(shí)是非常復(fù)雜的。

比如說每秒百萬并發(fā)的中間件系統(tǒng)、每日百億請(qǐng)求的網(wǎng)關(guān)系統(tǒng)、瞬時(shí)每秒幾十萬請(qǐng)求的秒殺大促系統(tǒng)、支撐幾億用戶的大規(guī)模高并發(fā)電商平臺(tái)架構(gòu)，等等。

為了支撐高并發(fā)請(qǐng)求，在系統(tǒng)架構(gòu)的設(shè)計(jì)時(shí)，會(huì)結(jié)合具體的業(yè)務(wù)場(chǎng)景和特點(diǎn)，設(shè)計(jì)出各種復(fù)雜的架構(gòu)，這需要大量底層技術(shù)支撐，需要精妙的架構(gòu)和機(jī)制設(shè)計(jì)的能力。

最終，各種復(fù)雜系統(tǒng)呈現(xiàn)出來的架構(gòu)復(fù)雜度會(huì)遠(yuǎn)遠(yuǎn)超出大部分沒接觸過的同學(xué)的想象。

但是那么復(fù)雜的系統(tǒng)架構(gòu)，通過一些文章是很難說的清楚里面的各種細(xì)節(jié)以及落地生產(chǎn)的過程的。

其次，高并發(fā)這話題本身包含的內(nèi)容也遠(yuǎn)遠(yuǎn)不止本文說的這么幾個(gè)topic：分庫分表、緩存、消息。

一個(gè)完整而復(fù)雜的高并發(fā)系統(tǒng)架構(gòu)中，一定會(huì)包含各種復(fù)雜的自研基礎(chǔ)架構(gòu)系統(tǒng)、各種精妙的架構(gòu)設(shè)計(jì)（比如熱點(diǎn)緩存架構(gòu)設(shè)計(jì)、多優(yōu)先級(jí)高吞吐MQ架構(gòu)設(shè)計(jì)、系統(tǒng)全鏈路并發(fā)性能優(yōu)化設(shè)計(jì)，等等）、還有各種復(fù)雜系統(tǒng)組合而成的高并發(fā)架構(gòu)整體技術(shù)方案、還有NoSQL（Elasticsearch等）/負(fù)載均衡/Web服務(wù)器等相關(guān)技術(shù)。

所以大家切記要對(duì)技術(shù)保持敬畏之心，這些東西都很難通過一些文章來表述清楚。

最后，真正在生產(chǎn)落地的時(shí)候，高并發(fā)場(chǎng)景下你的系統(tǒng)會(huì)出現(xiàn)大量的技術(shù)問題。

比如說消息中間件吞吐量上不去需要優(yōu)化、磁盤寫壓力過大性能太差、內(nèi)存消耗過大容易撐爆、分庫分表中間件不知道為什么丟了數(shù)據(jù)，等等吧。

諸如此類的問題非常多，這些也不可能通過文章給全部說清楚。

八、本文能帶給你什么啟發(fā)？

其實(shí)本文的定位，就是對(duì)高并發(fā)這個(gè)面試topic做一個(gè)掃盲，因?yàn)槲野l(fā)現(xiàn)大部分來問我這個(gè)問題的同學(xué)，連本文闡述的最最基本的高并發(fā)架構(gòu)演進(jìn)思路可能都沒理解。

當(dāng)然，也是因?yàn)楫吘箾]真的做過高并發(fā)系統(tǒng)，沒相關(guān)經(jīng)驗(yàn)，確實(shí)很難理解好這個(gè)問題。

所以本文就是讓很多沒接觸過的同學(xué)有一個(gè)初步的感知，這個(gè)高并發(fā)到底是怎么回事兒，到底對(duì)系統(tǒng)哪里有壓力，要在系統(tǒng)架構(gòu)里引入什么東西，才可以比較好的支撐住較高的并發(fā)壓力。

而且你可以順著本文的思路繼續(xù)思考下去，結(jié)合你自己熟悉和知道的一些技術(shù)繼續(xù)思考。

比如說，你熟悉Elasticsearch技術(shù)，那么你就可以思考，唉？在高并發(fā)的架構(gòu)之下，是不是可以通過分布式架構(gòu)的ES技術(shù)支撐高并發(fā)的搜索？

上面所說，權(quán)當(dāng)拋磚引玉。大家自己平時(shí)一定要多思考，自己多畫圖，盤點(diǎn)盤點(diǎn)自己手頭系統(tǒng)的請(qǐng)求壓力。計(jì)算一下分散到各個(gè)中間件層面的請(qǐng)求壓力，到底應(yīng)該如何利用最少的機(jī)器資源最好的支撐更高的并發(fā)請(qǐng)求。

這才是一個(gè)好的高并發(fā)架構(gòu)設(shè)計(jì)思路。

如果起到這個(gè)效果，本文就成功了。剩下的，還是建議各位同學(xué)，對(duì)高并發(fā)這個(gè)話題，結(jié)合自己手頭負(fù)責(zé)的系統(tǒng)多做思考。

比如當(dāng)前業(yè)務(wù)場(chǎng)景下，你的系統(tǒng)有多大的請(qǐng)求壓力？如果請(qǐng)求壓力增長10倍你的架構(gòu)如何支撐？如果請(qǐng)求壓力增長100倍，你的架構(gòu)如何支撐？如果請(qǐng)求壓力增長1000倍，你的架構(gòu)如何支撐？

平時(shí)一定多給自己設(shè)置一些技術(shù)挑戰(zhàn)，敦促自己去思考自己的系統(tǒng)，最好多做寫架構(gòu)上的演練、落地和實(shí)踐，自己實(shí)際操作一下，才有更好的感知。

然后在面試的時(shí)候，起碼自己做過一定深度的思考，結(jié)合自己負(fù)責(zé)的系統(tǒng)做過一些實(shí)踐，可以跟面試官有一個(gè)較為清晰和系統(tǒng)的闡述。

雖然大部分同學(xué)可能沒機(jī)會(huì)經(jīng)歷那種真正大規(guī)模超高并發(fā)的系統(tǒng)架構(gòu)的設(shè)計(jì)，但是本文如果能讓大家平時(shí)對(duì)自己的項(xiàng)目多一些思考。在面試的時(shí)候，有一些系統(tǒng)性的思路和闡述，那么也就達(dá)到本文的目的了。