1、面試題
如何設計一個高並發系統？
2、面試官心里分析
說實話，如果面試官問你這個題目，那么你必須要使出全身吃奶勁了。為啥？因為你沒看到現在很多公司招聘的jd里都是說啥，有高並發就經驗者優先。
所以如果你確實有真才實學，在互聯網公司里干過高並發系統，那你確實拿offer基本如探囊取物，沒啥問題。但是如果你要是真是干過高並發系統，面試官絕對絕對不會問這個問題，否則他就是蠢。
假設你在某知名電商公司干過高並發系統，用戶上億，一天流量幾十億，高峰期並發量上萬，甚至是十萬。那么人家一定會仔細盤問你的系統架構，你們系統啥架構？怎么部署的？部署了多少台機器？緩存咋用的？MQ咋用的？數據庫咋用的？就是深挖你到底是如何抗下高並發的。
因為真正干過高並發的人一定知道，脫離了業務的系統架構都是在紙上談兵，真正在復雜業務場景而且還高並發的時候，那系統架構一定不是那么簡單的，用個redis，用mq就能搞定？當然不是，真實的系統架構搭配上業務之后，會比這種簡單的所謂“高並發架構”要復雜很多倍。
如果有面試官問你個問題說，如何設計一個高並發系統？那么不好意思，一定是因為你實際上沒干過高並發系統。面試官看你簡歷就沒啥出彩的，感覺就不咋地，所以就會問問你，如何設計一個高並發系統？其實說白了本質就是看看你有沒有自己研究過，有沒有一定的知識積累。
最好的當然是招聘個真正干過高並發的哥兒們咯，但是這種哥兒們人數稀缺，不好招。所以可能次一點的就是招一個自己研究過的哥兒們，總比招一個傻也不會的哥兒們好吧！
所以這個時候你必須得做一把個人秀了，秀出你所有關於高並發的知識！
3、面試題剖析
其實所謂的高並發，如果你要理解這個問題呢，其實就得從高並發的根源出發，為啥會有高並發？為啥高並發就很牛逼？
我說的淺顯一點，很簡單，就是因為剛開始系統都是連接數據庫的，但是要知道數據庫支撐到每秒並發兩三千的時候，基本就快完了。所以才有說，很多公司，剛開始干的時候，技術比較low，結果業務發展太快，有的時候系統扛不住壓力就掛了。
當然會掛了，憑什么不掛？你數據庫如果瞬間承載每秒5000,8000，甚至上萬的並發，一定會宕機，因為比如mysql就壓根兒扛不住這么高的並發量。
所以為啥高並發牛逼？就是因為現在用互聯網的人越來越多，很多app、網站、系統承載的都是高並發請求，可能高峰期每秒並發量幾千，很正常的。如果是什么雙十一了之類的，每秒並發幾萬幾十萬都有可能。
那么如此之高的並發量，加上原本就如此之復雜的業務，咋玩兒？真正厲害的，一定是在復雜業務系統里玩兒過高並發架構的人，但是你沒有，那么我給你說一下你該怎么回答這個問題：
（1）系統拆分，將一個系統拆分為多個子系統，用dubbo來搞。然后每個系統連一個數據庫，這樣本來就一個庫，現在多個數據庫，不也可以抗高並發么。
（2）緩存，必須得用緩存。大部分的高並發場景，都是讀多寫少，那你完全可以在數據庫和緩存里都寫一份，然后讀的時候大量走緩存不就得了。畢竟人家redis輕輕松松單機幾萬的並發啊。沒問題的。所以你可以考慮考慮你的項目里，那些承載主要請求的讀場景，怎么用緩存來抗高並發。
（3）MQ，必須得用MQ。可能你還是會出現高並發寫的場景，比如說一個業務操作里要頻繁搞數據庫幾十次，增刪改增刪改，瘋了。那高並發絕對搞掛你的系統，你要是用redis來承載寫那肯定不行，人家是緩存，數據隨時就被LRU了，數據格式還無比簡單，沒有事務支持。所以該用mysql還得用mysql啊。那你咋辦？用MQ吧，大量的寫請求灌入MQ里，排隊慢慢玩兒，后邊系統消費后慢慢寫，控制在mysql承載范圍之內。所以你得考慮考慮你的項目里，那些承載復雜寫業務邏輯的場景里，如何用MQ來異步寫，提升並發性。MQ單機抗幾萬並發也是ok的，這個之前還特意說過。
（4）分庫分表，可能到了最后數據庫層面還是免不了抗高並發的要求，好吧，那么就將一個數據庫拆分為多個庫，多個庫來抗更高的並發；然后將一個表拆分為多個表，每個表的數據量保持少一點，提高sql跑的性能。
（5）讀寫分離，這個就是說大部分時候數據庫可能也是讀多寫少，沒必要所有請求都集中在一個庫上吧，可以搞個主從架構，主庫寫入，從庫讀取，搞一個讀寫分離。讀流量太多的時候，還可以加更多的從庫。
（6）Elasticsearch，可以考慮用es。es是分布式的，可以隨便擴容，分布式天然就可以支撐高並發，因為動不動就可以擴容加機器來抗更高的並發。那么一些比較簡單的查詢、統計類的操作，可以考慮用es來承載，還有一些全文搜索類的操作，也可以考慮用es來承載。
上面的6點，基本就是高並發系統肯定要干的一些事兒，大家可以仔細結合之前講過的知識考慮一下，到時候你可以系統的把這塊闡述一下，然后每個部分要注意哪些問題，之前都講過了，你都可以闡述闡述，表明你對這塊是有點積累的。
說句實話，畢竟真正你厲害的一點，不是在於弄明白一些技術，或者大概知道一個高並發系統應該長什么樣？其實實際上在真正的復雜的業務系統里，做高並發要遠遠比我這個圖復雜幾十倍到上百倍。你需要考慮，哪些需要分庫分表，哪些不需要分庫分表，單庫單表跟分庫分表如何join，哪些數據要放到緩存里去啊，放哪些數據再可以抗掉高並發的請求，你需要完成對一個復雜業務系統的分析之后，然后逐步逐步的加入高並發的系統架構的改造，這個過程是務必復雜的，一旦做過一次，一旦做好了，你在這個市場上就會非常的吃香。
其實大部分公司，真正看重的，不是說你掌握高並發相關的一些基本的架構知識，架構中的一些技術，RocketMQ、Kafka、Redis、Elasticsearch，高並發這一塊，次一等的人才。對一個有幾十萬行代碼的復雜的分布式系統，一步一步架構、設計以及實踐過高並發架構的人，這個經驗是難能可貴的。
我這邊其實平時我會發布一些免費的課程，每隔一段時間定期發布一點，主要是盡可能給大家講一些免費的課程，保證質量， 讓大家學到一些東西。
我主要還是專注在自己的架構師體系的課程上面，是一年多的時間，非常長，內容極其龐大，我從一開始就帶着你從0開始，動手構建一個10萬行以上代碼量的這么個龐大的系統，針對這種復雜系統的業務場景，里面隱含的各種技術問題和坑，我會通過1年多的時間，一步一步的講解各種技術和架構，解決真實的大型的系統中的各種問題。
