面試官心理分析
說實話渊胸，如果面試官問你這個題目旬盯，那么你必須要使出全身吃奶勁了。為啥翎猛？因為你沒看到現(xiàn)在很多公司招聘的 JD 里都是說啥胖翰，有高并發(fā)就經(jīng)驗者優(yōu)先。
如果你確實有真才實學切厘，在互聯(lián)網(wǎng)公司里干過高并發(fā)系統(tǒng)萨咳，那你確實拿 offer 基本如探囊取物，沒啥問題疫稿。面試官也絕對不會這樣來問你培他，否則他就是蠢。
假設(shè)你在某知名電商公司干過高并發(fā)系統(tǒng)遗座，用戶上億舀凛，一天流量幾十億，高峰期并發(fā)量上萬途蒋，甚至是十萬猛遍。那么人家一定會仔細盤問你的系統(tǒng)架構(gòu)，你們系統(tǒng)啥架構(gòu)号坡？怎么部署的懊烤？部署了多少臺機器？緩存咋用的宽堆？MQ 咋用的腌紧？數(shù)據(jù)庫咋用的？就是深挖你到底是如何扛住高并發(fā)的畜隶。
因為真正干過高并發(fā)的人一定知道壁肋，脫離了業(yè)務(wù)的系統(tǒng)架構(gòu)都是在紙上談兵逮光，真正在復雜業(yè)務(wù)場景而且還高并發(fā)的時候，那系統(tǒng)架構(gòu)一定不是那么簡單的墩划，用個 redis涕刚，用 mq 就能搞定？當然不是乙帮，真實的系統(tǒng)架構(gòu)搭配上業(yè)務(wù)之后杜漠，會比這種簡單的所謂“高并發(fā)架構(gòu)”要復雜很多倍。
如果有面試官問你個問題說察净，如何設(shè)計一個高并發(fā)系統(tǒng)驾茴？那么不好意思，一定是因為你實際上沒干過高并發(fā)系統(tǒng)氢卡。面試官看你簡歷就沒啥出彩的锈至，感覺就不咋地，所以就會問問你译秦，如何設(shè)計一個高并發(fā)系統(tǒng)峡捡？其實說白了本質(zhì)就是看看你有沒有自己研究過，有沒有一定的知識積累筑悴。
最好的當然是招聘個真正干過高并發(fā)的哥兒們咯们拙，但是這種哥兒們?nèi)藬?shù)稀缺，不好招阁吝。所以可能次一點的就是招一個自己研究過的哥兒們砚婆，總比招一個啥也不會的哥兒們好吧！
所以這個時候你必須得做一把個人秀了突勇，秀出你所有關(guān)于高并發(fā)的知識装盯！
面試題剖析
其實所謂的高并發(fā)，如果你要理解這個問題呢甲馋，其實就得從高并發(fā)的根源出發(fā)埂奈，為啥會有高并發(fā)？為啥高并發(fā)就很牛逼摔刁？
我說的淺顯一點挥转，很簡單海蔽，就是因為剛開始系統(tǒng)都是連接數(shù)據(jù)庫的共屈，但是要知道數(shù)據(jù)庫支撐到每秒并發(fā)兩三千的時候，基本就快完了党窜。所以才有說拗引，很多公司，剛開始干的時候幌衣，技術(shù)比較 low矾削，結(jié)果業(yè)務(wù)發(fā)展太快壤玫，有的時候系統(tǒng)扛不住壓力就掛了。
當然會掛了哼凯，憑什么不掛欲间？你數(shù)據(jù)庫如果瞬間承載每秒 5000/8000，甚至上萬的并發(fā)断部，一定會宕機猎贴，因為比如 mysql 就壓根兒扛不住這么高的并發(fā)量。
所以為啥高并發(fā)牛逼蝴光？就是因為現(xiàn)在用互聯(lián)網(wǎng)的人越來越多她渴，很多 app、網(wǎng)站蔑祟、系統(tǒng)承載的都是高并發(fā)請求趁耗，可能高峰期每秒并發(fā)量幾千，很正常的疆虚。如果是什么雙十一之類的苛败，每秒并發(fā)幾萬幾十萬都有可能。
那么如此之高的并發(fā)量径簿，加上原本就如此之復雜的業(yè)務(wù)著拭，咋玩兒？真正厲害的牍帚，一定是在復雜業(yè)務(wù)系統(tǒng)里玩兒過高并發(fā)架構(gòu)的人儡遮，但是你沒有，那么我給你說一下你該怎么回答這個問題：
可以分為以下 6 點：
系統(tǒng)拆分
緩存
MQ
分庫分表
讀寫分離
ElasticSearch
系統(tǒng)拆分
將一個系統(tǒng)拆分為多個子系統(tǒng)暗赶，用 dubbo 來搞鄙币。然后每個系統(tǒng)連一個數(shù)據(jù)庫，這樣本來就一個庫蹂随，現(xiàn)在多個數(shù)據(jù)庫十嘿，不也可以扛高并發(fā)么。
緩存
緩存岳锁，必須得用緩存绩衷。大部分的高并發(fā)場景，都是讀多寫少激率，那你完全可以在數(shù)據(jù)庫和緩存里都寫一份咳燕，然后讀的時候大量走緩存不就得了。畢竟人家 redis 輕輕松松單機幾萬的并發(fā)乒躺。所以你可以考慮考慮你的項目里招盲，那些承載主要請求的讀場景，怎么用緩存來抗高并發(fā)嘉冒。
MQ
MQ曹货，必須得用 MQ咆繁。可能你還是會出現(xiàn)高并發(fā)寫的場景顶籽，比如說一個業(yè)務(wù)操作里要頻繁搞數(shù)據(jù)庫幾十次玩般，增刪改增刪改，瘋了礼饱。那高并發(fā)絕對搞掛你的系統(tǒng)壤短，你要是用 redis 來承載寫那肯定不行，人家是緩存慨仿，數(shù)據(jù)隨時就被 LRU 了久脯，數(shù)據(jù)格式還無比簡單，沒有事務(wù)支持镰吆。所以該用 mysql 還得用 mysql 啊帘撰。那你咋辦？用 MQ 吧万皿，大量的寫請求灌入 MQ 里摧找，排隊慢慢玩兒，后邊系統(tǒng)消費后慢慢寫牢硅，控制在 mysql 承載范圍之內(nèi)蹬耘。所以你得考慮考慮你的項目里，那些承載復雜寫業(yè)務(wù)邏輯的場景里减余，如何用 MQ 來異步寫综苔，提升并發(fā)性。MQ 單機抗幾萬并發(fā)也是 ok 的位岔，這個之前還特意說過如筛。
分庫分表
分庫分表，可能到了最后數(shù)據(jù)庫層面還是免不了抗高并發(fā)的要求抒抬，好吧杨刨，那么就將一個數(shù)據(jù)庫拆分為多個庫，多個庫來扛更高的并發(fā)擦剑；然后將一個表拆分為多個表妖胀，每個表的數(shù)據(jù)量保持少一點，提高 sql 跑的性能惠勒。
讀寫分離
讀寫分離赚抡，這個就是說大部分時候數(shù)據(jù)庫可能也是讀多寫少，沒必要所有請求都集中在一個庫上吧捉撮，可以搞個主從架構(gòu)怕品，主庫寫入妇垢，從庫讀取巾遭，搞一個讀寫分離肉康。讀流量太多的時候，還可以加更多的從庫灼舍。
ElasticSearch
Elasticsearch吼和，簡稱 es。es 是分布式的骑素，可以隨便擴容炫乓，分布式天然就可以支撐高并發(fā)，因為動不動就可以擴容加機器來扛更高的并發(fā)献丑。那么一些比較簡單的查詢末捣、統(tǒng)計類的操作，可以考慮用 es 來承載创橄，還有一些全文搜索類的操作箩做，也可以考慮用 es 來承載。
上面的 6 點妥畏，基本就是高并發(fā)系統(tǒng)肯定要干的一些事兒邦邦，大家可以仔細結(jié)合之前講過的知識考慮一下，到時候你可以系統(tǒng)的把這塊闡述一下醉蚁，然后每個部分要注意哪些問題燃辖，之前都講過了，你都可以闡述闡述网棍，表明你對這塊是有點積累的黔龟。
說句實話，畢竟你真正厲害的一點滥玷，不是在于弄明白一些技術(shù)捌锭，或者大概知道一個高并發(fā)系統(tǒng)應(yīng)該長什么樣？其實實際上在真正的復雜的業(yè)務(wù)系統(tǒng)里罗捎，做高并發(fā)要遠遠比上面提到的點要復雜幾十倍到上百倍观谦。你需要考慮：哪些需要分庫分表，哪些不需要分庫分表桨菜，單庫單表跟分庫分表如何 join豁状，哪些數(shù)據(jù)要放到緩存里去，放哪些數(shù)據(jù)才可以扛住高并發(fā)的請求倒得，你需要完成對一個復雜業(yè)務(wù)系統(tǒng)的分析之后泻红，然后逐步逐步的加入高并發(fā)的系統(tǒng)架構(gòu)的改造，這個過程是無比復雜的霞掺，一旦做過一次谊路，并且做好了，你在這個市場上就會非常的吃香菩彬。
其實大部分公司缠劝，真正看重的潮梯，不是說你掌握高并發(fā)相關(guān)的一些基本的架構(gòu)知識，架構(gòu)中的一些技術(shù)惨恭，RocketMQ秉馏、Kafka、Redis脱羡、Elasticsearch萝究，高并發(fā)這一塊，你了解了锉罐，也只能是次一等的人才帆竹。對一個有幾十萬行代碼的復雜的分布式系統(tǒng)，一步一步架構(gòu)脓规、設(shè)計以及實踐過高并發(fā)架構(gòu)的人馆揉，這個經(jīng)驗是難能可貴的。
