一道面試題的背景引入

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

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

所以冰悠，這篇文章就從這個(gè)角度切入來(lái)簡(jiǎn)單說(shuō)說(shuō)這個(gè)問(wèn)題堡妒，用一個(gè)最簡(jiǎn)單的思路來(lái)回答，大致如何應(yīng)對(duì)溉卓。

當(dāng)然這里首先說(shuō)清楚一個(gè)前提：高并發(fā)系統(tǒng)各不相同皮迟。比如每秒百萬(wàn)并發(fā)的中間件系統(tǒng)、每日百億請(qǐng)求的網(wǎng)關(guān)系統(tǒng)桑寨、瞬時(shí)每秒幾十萬(wàn)請(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)辨图、庫(kù)存系統(tǒng)，在高并發(fā)場(chǎng)景下的架構(gòu)設(shè)計(jì)也是不同的肢藐，因?yàn)楸澈蟮臉I(yè)務(wù)場(chǎng)景什么的都不一樣故河。

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

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

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

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

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

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

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

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

好吧!完全跟高并發(fā)搭不上邊注盈，對(duì)不對(duì)?

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

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

按照這臺(tái)數(shù)據(jù)庫(kù)服務(wù)器的配置鳍鸵，支撐是絕對(duì)沒(méi)問(wèn)題的。上述描述的系統(tǒng)尉间，用一張圖表示偿乖，就是下面這樣：

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

假設(shè)此時(shí)你的用戶數(shù)開(kāi)始快速增長(zhǎng)，比如注冊(cè)用戶量增長(zhǎng)了 50 倍哲嘲，上升到了 500 萬(wàn)贪薪。

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

按照上述的機(jī)器配置來(lái)說(shuō)，如果你的系統(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ù)庫(kù)層面台丛，以上述的配置而言耍缴，其實(shí)基本上 1500/s 的高峰請(qǐng)求壓力的話，還算可以接受。

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

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

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

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

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

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

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

添加負(fù)載均衡層蓉媳，將請(qǐng)求均勻打到系統(tǒng)層。

系統(tǒng)層采用集群化部署多臺(tái)機(jī)器锅铅，扛住初步的并發(fā)壓力酪呻。

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

數(shù)據(jù)庫(kù)分庫(kù)分表 + 讀寫(xiě)分離

假設(shè)此時(shí)用戶量繼續(xù)增長(zhǎng)，達(dá)到了 1000 萬(wàn)注冊(cè)用戶狠角，然后每天日活用戶是 100 萬(wàn)号杠。

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

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

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

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

沒(méi)錯(cuò)衡蚂，一般來(lái)說(shuō)，對(duì)那種普通配置的線上數(shù)據(jù)庫(kù)骏庸，建議就是讀寫(xiě)并發(fā)加起來(lái)毛甲，按照上述我們舉例的那個(gè)配置，不要超過(guò) 3000/s具被。

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

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

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

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

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

那么一旦分庫(kù)分表之后拇泣，采用兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上部署主庫(kù)來(lái)支撐寫(xiě)請(qǐng)求噪叙，每臺(tái)服務(wù)器承載的寫(xiě)并發(fā)就是 500/s。

每臺(tái)主庫(kù)掛載一個(gè)服務(wù)器部署從庫(kù)霉翔，那么 2 個(gè)從庫(kù)每個(gè)從庫(kù)支撐的讀并發(fā)就是 1000/s睁蕾。

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

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

緩存集群引入

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

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

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

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

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

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

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

具體來(lái)說(shuō)故爵，就是在寫(xiě)數(shù)據(jù)庫(kù)的時(shí)候同時(shí)寫(xiě)一份數(shù)據(jù)到緩存集群里，然后用緩存集群來(lái)承載大部分的讀請(qǐng)求隅津。

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

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

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

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

按照上述架構(gòu)确买，它的好處是什么呢?

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

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

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

不要盲目進(jìn)行數(shù)據(jù)庫(kù)擴(kuò)容歧譬，數(shù)據(jù)庫(kù)服務(wù)器成本昂貴岸浑，且本身就不是用來(lái)承載高并發(fā)的。

針對(duì)寫(xiě)少讀多的請(qǐng)求瑰步，引入緩存集群矢洲，用緩存集群抗住大量的讀請(qǐng)求。

引入消息中間件集群

接著再來(lái)看看數(shù)據(jù)庫(kù)寫(xiě)這塊的壓力缩焦，其實(shí)是跟讀類(lèi)似的读虏。

假如說(shuō)你所有寫(xiě)請(qǐng)求全部都落地?cái)?shù)據(jù)庫(kù)的主庫(kù)層，當(dāng)然是沒(méi)問(wèn)題的袁滥，但是寫(xiě)壓力要是越來(lái)越大了呢?

比如每秒要寫(xiě)幾萬(wàn)條數(shù)據(jù)盖桥，此時(shí)難道也是不停的給主庫(kù)加機(jī)器嗎?

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

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

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

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

那么此時(shí)你完全可以引入消息中間件集群，把允許異步化的每秒 500 次請(qǐng)求寫(xiě)入 MQ赏参，然后基于 MQ 做一個(gè)削峰填谷志笼。

比如就以平穩(wěn)的 100/s 的速度消費(fèi)出來(lái)沿盅，然后落入數(shù)據(jù)庫(kù)中即可，此時(shí)就會(huì)大幅度降低數(shù)據(jù)庫(kù)的寫(xiě)入壓力纫溃。

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

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

所以，它本身也跟緩存系統(tǒng)一樣坊谁，可以用很少的資源支撐很高的并發(fā)請(qǐng)求费彼，用它來(lái)支撐部分允許異步化的高并發(fā)寫(xiě)入是沒(méi)問(wèn)題的，比使用數(shù)據(jù)庫(kù)直接支撐那部分高并發(fā)請(qǐng)求要減少很多的機(jī)器使用量口芍。

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

大家看看虹钮，是不是發(fā)現(xiàn)減輕了數(shù)據(jù)庫(kù)的壓力?到目前為止，通過(guò)下面的手段膘融，我們已經(jīng)可以讓系統(tǒng)架構(gòu)盡可能用最小的機(jī)器資源抗住了最大的請(qǐng)求壓力芙粱，減輕了數(shù)據(jù)庫(kù)的負(fù)擔(dān)：

系統(tǒng)集群化。

數(shù)據(jù)庫(kù)層面的分庫(kù)分表+讀寫(xiě)分離氧映。

針對(duì)讀多寫(xiě)少的請(qǐng)求春畔，引入緩存集群。

針對(duì)高寫(xiě)入的壓力岛都，引入消息中間件集群律姨。

初步來(lái)說(shuō)，簡(jiǎn)單的一個(gè)高并發(fā)系統(tǒng)的闡述是說(shuō)完了臼疫。但是择份，故事到這里還遠(yuǎn)遠(yuǎn)沒(méi)有結(jié)束。

現(xiàn)在能 Hold 住高并發(fā)面試題了嗎?

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

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

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

比如說(shuō)每秒百萬(wàn)并發(fā)的中間件系統(tǒng)灭红、每日百億請(qǐng)求的網(wǎng)關(guān)系統(tǒng)侣滩、瞬時(shí)每秒幾十萬(wàn)請(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)出來(lái)的架構(gòu)復(fù)雜度會(huì)遠(yuǎn)遠(yuǎn)超出大部分沒(méi)接觸過(guò)的同學(xué)的想象悔醋。

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

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

一個(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ù)保持敬畏之心冰抢，這些東西都很難通過(guò)一些文章來(lái)表述清楚松嘶。

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

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

諸如此類(lèi)的問(wèn)題非常多，這些也不可能通過(guò)文章給全部說(shuō)清楚歧寺。

本文能帶給你什么啟發(fā)?

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

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

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

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

比如說(shuō)战坤，你熟悉 Elasticsearch 技術(shù)曙强，那么你就可以思考，在高并發(fā)的架構(gòu)之下途茫，是不是可以通過(guò)分布式架構(gòu)的 ES 技術(shù)支撐高并發(fā)的搜索?

上面所說(shuō)碟嘴，權(quán)當(dāng)拋磚引玉。大家自己平時(shí)一定要多思考慈省，多畫(huà)圖臀防，盤(pá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)求壓力增長(zhǎng) 10 倍脱吱，你的架構(gòu)如何支撐?如果請(qǐng)求壓力增長(zhǎng) 100 倍，你的架構(gòu)如何支撐?如果請(qǐng)求壓力增長(zhǎng) 1000 倍认罩，你的架構(gòu)如何支撐?

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

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

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

感興趣的可以自己來(lái)我的Java架構(gòu)群找蜜，可以獲取免費(fèi)的學(xué)習(xí)資料饼暑，群號(hào)：855801563對(duì)Java技術(shù)，架構(gòu)技術(shù)感興趣的同學(xué)洗做，歡迎加群弓叛，一起學(xué)習(xí)，相互討論诚纸。