突破Java面試(45)-高并發系統的架構設計0

Github

1 面試題

如何設計一個高并發系統？

2 考點分析

問你這個題目,就必須要使出全身吃奶勁了。為啥？

因為你沒看到現在很多公司招聘的jd裡都是說啥，有高并發經驗者優先!

是以如果你确實有真才實學，在網際網路公司裡幹過高并發系統，那你确實拿offer基本如探囊取物，沒啥問題。

但是如果你要是真是幹過高并發系統，面試官絕對絕對不會問這個問題，否則他就是蠢。

假設你在某知名電商公司幹過高并發系統，使用者上億，一天流量幾十億，高峰期并發量上萬，甚至是十萬。那麼人家一定會仔細盤問你的系統架構？怎麼部署的？部署了多少台機器？緩存咋用的？MQ咋用的？資料庫咋用的？就是深挖你到底是如何抗下高并發的。

因為真正幹過高并發的人一定知道，脫離了業務的系統架構都是在紙上談兵，真正在複雜業務場景而且還高并發的時候，那系統架構一定不是那麼簡單的，用個redis，用mq就能搞定？

當然不是，真實的系統架構搭配上業務之後，會比這種簡單的所謂“高并發架構”要複雜很多倍。

如果有面試官問你個問題說，如何設計一個高并發系統？

那麼不好意思，一定是因為你實際上沒幹過高并發系統。面試官看你履歷就沒啥出彩的，感覺就不咋地，是以就會問問你，如何設計一個高并發系統？其實說白了本質就是看看你有沒有自己研究過，有沒有一定的知識積累。

最好的當然是招聘個真正幹過高并發的哥兒們咯，但是這種人數稀缺，不好招。是以可能次一點的就是招一個自己研究過的哥兒們，總比招一個傻也不會的哥兒們好吧！

是以這個時候你必須得做一把個人秀了，秀出你所有關于高并發的知識！

3 高并發的意義

其實所謂的高并發，如果你要了解這個問題呢，其實就得從高并發的根源出發，為啥會有高并發？為啥高并發就很牛逼？

淺顯一點，很簡單，就是因為剛開始系統都是連接配接資料庫的，但是要知道資料庫支撐到每秒并發兩三千的時候，基本就快完了。是以才有說，很多公司，剛開始幹的時候，技術比較low，結果業務發展太快，有的時候系統扛不住壓力就挂了。

當然會挂了，憑什麼不挂？你資料庫如果瞬間承載每秒5000,8000，甚至上萬的并發，一定會當機，因為比如mysql就壓根兒扛不住這麼高的并發量。

是以為啥高并發牛逼？就是因為現在用網際網路的人越來越多，很多app、網站、系統承載的都是高并發請求，可能高峰期每秒并發量幾千，很正常的。如果是什麼雙十一了之類的，每秒并發幾萬幾十萬都有可能。

那麼如此之高的并發量，加上原本就如此之複雜的業務，咋玩兒？真正厲害的，一定是在複雜業務系統裡玩兒過高并發架構的人

但是你沒有，那麼給你說一下該怎麼回答這個問題

• 高并發系統的架構組成

4 系統拆分

将一個系統拆分為多個子系統，用dubbo來搞。然後每個系統連一個資料庫，這樣本來就一個庫，現在多個資料庫，不也可以抗高并發麼。

5 緩存

大部分高并發場景，都是讀多寫少，完全可以在資料庫和緩存裡都寫一份，然後讀的時候大量走緩存.

畢竟Redis輕輕松松單機幾萬的并發,是以你可以考慮考慮你的項目裡，那些承載主要請求的讀場景，怎麼用緩存來抗高并發

6 消息隊列

可能你還是會出現高并發寫的場景，比如一個業務操作裡要頻繁搞資料庫幾十次，增删改增删改瘋了。那高并發絕對搞挂你的系統，你要是用Redis來承載寫那肯定不行，人家是緩存，資料随時就被LRU了，資料格式還無比簡單，沒有事務支援

是以該用MySQL還得用MySQL。那你咋辦？

用MQ吧，大量的寫請求灌入MQ裡，排隊慢慢玩兒，後邊系統消費後慢慢寫，控制在MySQL承載範圍之内。是以你得考慮考慮你的項目裡，那些承載複雜寫業務邏輯的場景裡，如何用MQ來異步寫，提升并發性。MQ單機抗幾萬并發也是ok的

7 分庫分表

可能到了最後資料庫層面還是免不了抗高并發的要求

那麼就将一個資料庫拆分為多個庫，多個庫來抗更高的并發

然後将一個表拆分為多個表，每個表的資料量保持少一點，提高SQL跑的性能。

8 讀寫分離

大部分時候資料庫可能也是讀多寫少，就沒必要所有請求都集中在一個庫，可以搞個主從架構，主庫寫入，從庫讀取，搞一個讀寫分離。讀流量太多的時候，還可以加更多的從庫

9 Elasticsearch

ES是分布式的，可以随便擴容，分布式天然就可以支撐高并發，因為動不動就可以擴容加機器來抗更高的并發。那麼一些比較簡單的查詢、統計類的操作，可以考慮用ES承載，還有一些全文搜尋類的操作，也可以考慮用ES

10 總結

上面及點，基本就是高并發系統肯定要幹的一些事兒，大家可以仔細結合之前講過的知識考慮一下，到時候你可以系統的把這塊闡述一下，然後每個部分要注意哪些問題，之前都講過了，你都可以闡述闡述，表明你對這塊是有點積累的。

說句實話，畢竟真正你厲害的一點，不是在于弄明白一些技術，或者大概知道一個高并發系統應該長什麼樣？

其實實際上在真正的複雜的業務系統裡，做高并發要遠遠比我這個圖複雜幾十倍到上百倍。

你需要考慮，哪些需要分庫分表，哪些不需要分庫分表，單庫單表跟分庫分表如何join，哪些資料要放到緩存裡去啊，放哪些資料再可以抗掉高并發的請求，你需要完成對一個複雜業務系統的分析之後，然後逐漸逐漸的加入高并發的系統架構的改造，這個過程是務必複雜的，一旦做過一次，一旦做好了，你在這個市場上就會非常的吃香。

其實大部分公司，真正看重的，不是說你掌握高并發相關的一些基本的架構知識，架構中的一些技術，RocketMQ、Kafka、Redis、Elasticsearch，高并發這一塊，次一等的人才。

對一個有幾十萬行代碼的複雜的分布式系統，一步一步架構、設計以及實踐過高并發架構的人，這個經驗是難能可貴的!

參考

• 《Java工程師面試突擊第1季-中華石杉老師》