總結如果你確實有真才實學，在網際網路公司裡幹過高併發系統，那你確實拿 offer 基本如探囊取物，沒啥問題。面試官也絕對不會這樣來問你，否則他就是蠢。
假設你在某知名電商公司幹過高併發系統，使用者上億，一天流量幾十億，高峰期併發量上萬，甚至是十萬。那麼人家一定會仔細盤問你的系統架構，你們系統啥架構？怎麼部署的？部署了多少臺機器？快取咋用的？mq 咋用的？資料庫咋用的？就是深挖你到底是如何扛住高併發的。
因為真正幹過高併發的人一定知道，脫離了業務的系統架構都是在紙上談兵，真正在複雜業務場景而且還高併發的時候，那系統架構一定不是那麼簡單的，用個redis，用mq就能搞定？當然不是，真實的系統架構搭配上業務之後，會比這種簡單的所謂「高併發架構」要複雜很多倍。
如果有面試官問你個問題說，如何設計乙個高併發系統？那麼不好意思，一定是因為你實際上沒乾過高併發系統。面試官看你簡歷就沒啥出彩的，感覺就不咋地，所以就會問問你，如何設計乙個高併發系統？其實說白了本質就是看看你有沒有自己研究過，有沒有一定的知識積累。
最好的當然是招聘個真正幹過高併發的咯，但是這種人很少，不好招。所以可能次一點的就是招乙個自己研究過的，總比招乙個啥也不會的好吧！
所以這個時候你必須得做一把個人秀了，秀出你所有關於高併發的知識！
可以分為以下 6 點：
將乙個系統拆分為多個子系統，用 dubbo 來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，不也可以扛高併發麼。
快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟 redis 輕輕鬆鬆單機幾萬的併發。所以你可以考慮考慮你的專案裡，那些承載主要請求的讀場景，怎麼用快取來抗高併發。
mq，必須得用 mq。可能你還是會出現高併發寫的場景，比如說乙個業務操作裡要頻繁搞資料庫幾十次，增刪改增刪改，瘋了。那高併發絕對搞掛你的系統，你要是用 redis 來承載寫那肯定不行，人家是快取，資料隨時就被 lru 了，資料格式還無比簡單，沒有事務支援。所以該用 mysql 還得用 mysql 啊。那你咋辦？用 mq 吧，大量的寫請求灌入 mq 裡，排隊慢慢玩兒，後邊系統消費後慢慢寫，控制在 mysql 承載範圍之內。所以你得考慮考慮你的專案裡，那些承載複雜寫業務邏輯的場景裡，如何用 mq 來非同步寫，提公升併發性。mq 單機抗幾萬併發也是 ok 的。
分庫分表，可能到了最後資料庫層面還是免不了抗高併發的要求，好吧，那麼就將乙個資料庫拆分為多個庫，多個庫來扛更高的併發；然後將乙個表拆分為多個表，每個表的資料量保持少一點，提高 sql 跑的效能。
讀寫分離，這個就是說大部分時候資料庫可能也是讀多寫少，沒必要所有請求都集中在乙個庫上吧，可以搞個主從架構，主庫寫入，從庫讀取，搞乙個讀寫分離。讀流量太多的時候，還可以加更多的從庫。
elasticsearch，簡稱 es。es 是分布式的，可以隨便擴容，分布式天然就可以支撐高併發，因為動不動就可以擴容加機器來扛更高的併發。那麼一些比較簡單的查詢、統計類的操作，可以考慮用 es 來承載，還有一些全文搜尋類的操作，也可以考慮用 es 來承載。
上面的 6 點，基本就是高併發系統肯定要幹的一些事兒，到時候你可以系統的把這塊闡述一下，然後每個部分要注意哪些問題，之前都講過了，你都可以闡述闡述，表明你對這塊是有點積累的。
說句實話，畢竟你真正厲害的一點，不是在於弄明白一些技術，或者大概知道乙個高併發系統應該長什麼樣？其實實際上在真正的複雜的業務系統裡，做高併發要遠遠比上面提到的點要複雜幾十倍到上百倍。你需要考慮：哪些需要分庫分表，哪些不需要分庫分表，單庫單錶跟分庫分表如何 join，哪些資料要放到快取裡去，放哪些資料才可以扛住高併發的請求，你需要完成對乙個複雜業務系統的分析之後，然後逐步逐步的加入高併發的系統架構的改造，這個過程是無比複雜的，一旦做過一次，並且做好了，你在這個市場上就會非常的吃香。
其實大部分公司，真正看重的，不是說你掌握高併發相關的一些基本的架構知識，架構中的一些技術，rocketmq、kafka、redis、elasticsearch，高併發這一塊，你了解了，也只能是次一等的人才。對乙個有幾十萬行**的複雜的分布式系統，一步一步架構、設計以及實踐過高併發架構的人，這個經驗是難能可貴的。
如何設計乙個高併發系統
系統拆分，將乙個系統拆分為多個子系統，用dubbo來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，不也可以抗高併發麼。快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟人家redis輕輕鬆鬆單機幾萬的併發...
設計乙個高併發系統
公升級過程為 最初系統 新增負載均衡 資料庫分庫分表 讀寫分離 快取集群 訊息中介軟體集群 假設系統機器是4核8g，資料庫伺服器是16核32g。日活使用者1w，系統層面每秒10次請求，資料庫層每秒30次請求。使用者量增長了50倍，日活使用者50萬，高峰期對系統每秒請求500 s，對資料庫的每秒請求1...
如何設計乙個高可用 高併發秒殺系統
如今的網際網路已經在海量服務領域有了很成熟的理論，因此自己也很慶幸，能夠從 0 到 1 完整踐行海量服務。微視春節專案中的集卡瓜分活動，是乙個典型的秒殺場景，自己參與其中，分享一些心得和總結。上圖是乙個典型的網際網路業務，使用者完成乙個寫操作，一般會通過接入層和邏輯層，這裡的服務都是無狀態，可以通過...