原文出處：https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/high-concurrency-design.md
歡迎 star 關(guān)注 GitHub 項目最新動態(tài)！
面試題
如何設(shè)計一個高并發(fā)系統(tǒng)？
面試官心理分析
說實話，如果面試官問你這個題目，那么你必須要使出全身吃奶勁了衣迷。為啥？因為你沒看到現(xiàn)在很多公司招聘的 JD 里都是說啥酱酬，有高并發(fā)就經(jīng)驗者優(yōu)先壶谒。
如果你確實有真才實學(xué)，在互聯(lián)網(wǎng)公司里干過高并發(fā)系統(tǒng)岳悟，那你確實拿 offer 基本如探囊取物佃迄，沒啥問題。面試官也絕對不會這樣來問你贵少，否則他就是蠢呵俏。
假設(shè)你在某知名電商公司干過高并發(fā)系統(tǒng)，用戶上億滔灶，一天流量幾十億普碎，高峰期并發(fā)量上萬，甚至是十萬录平。那么人家一定會仔細(xì)盤問你的系統(tǒng)架構(gòu)麻车，你們系統(tǒng)啥架構(gòu)缀皱？怎么部署的？部署了多少臺機器动猬？緩存咋用的啤斗？MQ 咋用的？數(shù)據(jù)庫咋用的赁咙？就是深挖你到底是如何扛住高并發(fā)的钮莲。
因為真正干過高并發(fā)的人一定知道，脫離了業(yè)務(wù)的系統(tǒng)架構(gòu)都是在紙上談兵彼水，真正在復(fù)雜業(yè)務(wù)場景而且還高并發(fā)的時候崔拥，那系統(tǒng)架構(gòu)一定不是那么簡單的，用個 redis凤覆，用 mq 就能搞定链瓦？當(dāng)然不是，真實的系統(tǒng)架構(gòu)搭配上業(yè)務(wù)之后盯桦，會比這種簡單的所謂“高并發(fā)架構(gòu)”要復(fù)雜很多倍慈俯。
如果有面試官問你個問題說，如何設(shè)計一個高并發(fā)系統(tǒng)拥峦？那么不好意思肥卡，一定是因為你實際上沒干過高并發(fā)系統(tǒng)。面試官看你簡歷就沒啥出彩的事镣，感覺就不咋地，所以就會問問你揪胃，如何設(shè)計一個高并發(fā)系統(tǒng)璃哟？其實說白了本質(zhì)就是看看你有沒有自己研究過，有沒有一定的知識積累喊递。
最好的當(dāng)然是招聘個真正干過高并發(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)扛不住壓力就掛了获高。
當(dāng)然會掛了，憑什么不掛吻育？你數(shù)據(jù)庫如果瞬間承載每秒 5000/8000念秧，甚至上萬的并發(fā)，一定會宕機布疼，因為比如 mysql 就壓根兒扛不住這么高的并發(fā)量摊趾。
所以為啥高并發(fā)牛逼？就是因為現(xiàn)在用互聯(lián)網(wǎng)的人越來越多游两，很多 app砾层、網(wǎng)站、系統(tǒng)承載的都是高并發(fā)請求贱案，可能高峰期每秒并發(fā)量幾千肛炮，很正常的。如果是什么雙十一之類的宝踪，每秒并發(fā)幾萬幾十萬都有可能侨糟。
那么如此之高的并發(fā)量，加上原本就如此之復(fù)雜的業(yè)務(wù)瘩燥，咋玩兒秕重？真正厲害的，一定是在復(fù)雜業(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)彭羹。所以你得考慮考慮你的項目里，那些承載復(fù)雜寫業(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)肯定要干的一些事兒寝姿，大家可以仔細(xì)結(jié)合之前講過的知識考慮一下交排，到時候你可以系統(tǒng)的把這塊闡述一下，然后每個部分要注意哪些問題饵筑，之前都講過了埃篓，你都可以闡述闡述，表明你對這塊是有點積累的根资。
說句實話架专，畢竟你真正厲害的一點，不是在于弄明白一些技術(shù)玄帕，或者大概知道一個高并發(fā)系統(tǒng)應(yīng)該長什么樣部脚？其實實際上在真正的復(fù)雜的業(yè)務(wù)系統(tǒng)里，做高并發(fā)要遠(yuǎn)遠(yuǎn)比上面提到的點要復(fù)雜幾十倍到上百倍裤纹。你需要考慮：哪些需要分庫分表委刘，哪些不需要分庫分表，單庫單表跟分庫分表如何 join，哪些數(shù)據(jù)要放到緩存里去锡移，放哪些數(shù)據(jù)才可以扛住高并發(fā)的請求呕童，你需要完成對一個復(fù)雜業(yè)務(wù)系統(tǒng)的分析之后，然后逐步逐步的加入高并發(fā)的系統(tǒng)架構(gòu)的改造罩抗，這個過程是無比復(fù)雜的拉庵，一旦做過一次，并且做好了套蒂，你在這個市場上就會非常的吃香钞支。
其實大部分公司，真正看重的操刀，不是說你掌握高并發(fā)相關(guān)的一些基本的架構(gòu)知識烁挟，架構(gòu)中的一些技術(shù)，RocketMQ骨坑、Kafka撼嗓、Redis、Elasticsearch欢唾，高并發(fā)這一塊且警，你了解了，也只能是次一等的人才礁遣。對一個有幾十萬行代碼的復(fù)雜的分布式系統(tǒng)斑芜，一步一步架構(gòu)、設(shè)計以及實踐過高并發(fā)架構(gòu)的人祟霍，這個經(jīng)驗是難能可貴的杏头。
