Java面試常問題：如何設計一個高併發系統？你該如何優雅的回答

面試原題

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

面試官心理分析

說實話，若是面試官問你這個題目，那麼你必需要使出全身吃奶勁了。爲啥？由於你沒看到如今不少公司招聘的 JD 裏都是說啥，有高併發就經驗者優先。

若是你確實有真才實學，在互聯網公司裏幹太高併發系統，那你確實拿 offer 基本如探囊取物，沒啥問題。面試官也絕對不會這樣來問你，不然他就是蠢。

假設你在某知名電商公司幹太高併發系統，用戶上億，一天流量幾十億，高峯期併發量上萬，甚至是十萬。那麼人家必定會仔細盤問你的系統架構，大家系統啥架構？怎麼部署的？部署了多少臺機器？緩存咋用的？MQ 咋用的？數據庫咋用的？就是深挖你究竟是如何扛住高併發的。

由於真正幹太高併發的人必定知道，脫離了業務的系統架構都是在紙上談兵，真正在複雜業務場景並且還高併發的時候，那系統架構必定不是那麼簡單的，用個 redis，用 mq 就能搞定？固然不是，真實的系統架構搭配上業務以後，會比這種簡單的所謂「高併發架構」要複雜不少倍。

若是有面試官問你個問題說，如何設計一個高併發系統？那麼很差意思，必定是由於你實際上沒幹太高併發系統。面試官看你簡歷就沒啥出彩的，感受就不咋地，因此就會問問你，如何設計一個高併發系統？其實說白了本質就是看看你有沒有本身研究過，有沒有必定的知識積累。

最好的固然是招聘個真正幹太高併發的哥兒們咯，可是這種哥兒們人數稀缺，很差招。因此可能次一點的就是招一個本身研究過的哥兒們，總比招一個傻也不會的哥兒們好吧！

因此這個時候你必須得作一把我的秀了，秀出你全部關於高併發的知識！

面試題剖析

其實所謂的高併發，若是你要理解這個問題呢，其實就得從高併發的根源出發，爲啥會有高併發？爲啥高併發就很牛逼？

我說的淺顯一點，很簡單，就是由於剛開始系統都是鏈接數據庫的，可是要知道數據庫支撐到每秒併發兩三千的時候，基本就快完了。因此纔有說，不少公司，剛開始乾的時候，技術比較 low，結果業務發展太快，有的時候系統扛不住壓力就掛了。

固然會掛了，憑什麼不掛？你數據庫若是瞬間承載每秒 5000/8000，甚至上萬的併發，必定會宕機，由於好比 mysql 就壓根兒扛不住這麼高的併發量。

因此爲啥高併發牛逼？就是由於如今用互聯網的人愈來愈多，不少app、網站、系統承載的都是高併發請求，可能高峯期每秒併發量幾千，很正常的。若是是什麼雙十一之類的，每秒併發幾萬幾十萬都有可能。

那麼如此之高的併發量，加上本來就如此之複雜的業務，咋玩兒？真正厲害的，必定是在複雜業務系統裏玩兒太高併發架構的人，可是你沒有，那麼我給你說一下你該怎麼回答這個問題：

能夠分爲如下 6 點：

• 系統拆分

• 緩存

• MQ

• 分庫分表

• 讀寫分離

• ElasticSearch

系統拆分

將一個系統拆分爲多個子系統，用 dubbo 來搞。而後每一個系統連一個數據庫，這樣原本就一個庫，如今多個數據庫，不也能夠扛高併發麼。

緩存

緩存，必須得用緩存。大部分的高併發場景，都是讀多寫少，那你徹底能夠在數據庫和緩存裏都寫一份，而後讀的時候大量走緩存不就得了。畢竟人家 redis 輕輕鬆鬆單機幾萬的併發。因此你能夠考慮考慮你的項目裏，那些承載主要請求的讀場景，怎麼用緩存來抗高併發。

MQ

MQ，必須得用 MQ。可能你仍是會出現高併發寫的場景，好比說一個業務操做裏要頻繁搞數據庫幾十次，增刪改增刪改，瘋了。那高併發絕對搞掛你的系統，你要是用 redis 來承載寫那確定不行，人家是緩存，數據隨時就被 LRU 了，數據格式還無比簡單，沒有事務支持。因此該用 mysql 還得用 mysql 啊。那你咋辦？用 MQ 吧，大量的寫請求灌入 MQ 裏，排隊慢慢玩兒，後邊系統消費後慢慢寫，控制在 mysql 承載範圍以內。因此你得考慮考慮你的項目裏，那些承載複雜寫業務邏輯的場景裏，如何用 MQ 來異步寫，提高併發性。MQ 單機抗幾萬併發也是 ok 的，這個以前還特地說過。

分庫分表

分庫分表，可能到了最後數據庫層面仍是免不了抗高併發的要求，好吧，那麼就將一個數據庫拆分爲多個庫，多個庫來扛更高的併發；而後將一個表拆分爲多個表，每一個表的數據量保持少一點，提升 sql 跑的性能。

讀寫分離

讀寫分離，這個就是說大部分時候數據庫可能也是讀多寫少，不必全部請求都集中在一個庫上吧，能夠搞個主從架構，主庫寫入，從庫讀取，搞一個讀寫分離。讀流量太多的時候，還能夠加更多的從庫。

ElasticSearch

Elasticsearch，簡稱 es。es 是分佈式的，能夠隨便擴容，分佈式自然就能夠支撐高併發，由於動不動就能夠擴容加機器來扛更高的併發。那麼一些比較簡單的查詢、統計類的操做，能夠考慮用 es 來承載，還有一些全文搜索類的操做，也能夠考慮用 es 來承載。

總結

上面的 6 點，基本就是高併發系統確定要乾的一些事兒，你們能夠仔細結合以前講過的知識考慮一下，到時候你能夠系統的把這塊闡述一下，而後每一個部分要注意哪些問題，以前都講過了，你均可以闡述闡述，代表你對這塊是有點積累的。

說句實話，畢竟你真正厲害的一點，不是在於弄明白一些技術，或者大概知道一個高併發系統應該長什麼樣？其實實際上在真正的複雜的業務系統裏，作高併發要遠遠比上面提到的點要複雜幾十倍到上百倍。你須要考慮：哪些須要分庫分表，哪些不須要分庫分表，單庫單表跟分庫分表如何 join，哪些數據要放到緩存裏去，放哪些數據再能夠扛住高併發的請求，你須要完成對一個複雜業務系統的分析以後，而後逐步逐步的加入高併發的系統架構的改造，這個過程是無比複雜的，一旦作過一次，而且作好了，你在這個市場上就會很是的吃香。

其實大部分公司，真正看重的，不是說你掌握高併發相關的一些基本的架構知識，架構中的一些技術，RocketMQ、Kafka、Redis、Elasticsearch，高併發這一塊，你瞭解了，也只能是次一等的人才。對一個有幾十萬行代碼的複雜的分佈式系統，一步一步架構、設計以及實踐太高併發架構的人，這個經驗是難能難得的。

---

寫在最後：

歡迎你們關注我新開通的公衆號【風平浪靜如碼】，海量Java相關文章，學習資料都會在裏面更新，整理的資料也會放在裏面。

以爲寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！

轉載自簡書 原文連接：www.jianshu.com/p/a68a3e3h8…