（1）當公司系統併發開始增加時，做系統拆分，將乙個系統拆分為多個子系統，用dubbo來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，不也可以抗高併發麼。
（2）快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟人家redis輕輕鬆鬆單機幾萬的併發啊。沒問題的。所以你可以考慮考慮你的專案裡，那些承載主要請求的讀場景，怎麼用快取來抗高併發。
（3）mq，必須得用mq。可能你還是會出現高併發寫的場景，比如說乙個業務操作裡要頻繁搞資料庫幾十次，增刪改增刪改，瘋了。那高併發絕對搞掛你的系統，你要是用redis來承載寫那肯定不行，人家是快取，資料隨時就被lru了，資料格式還無比簡單，沒有事務支援。所以該用mysql還得用mysql啊。那你咋辦？用mq吧，大量的寫請求灌入mq裡，排隊慢慢玩兒，後邊系統消費後慢慢寫，控制在mysql承載範圍之內。所以你得考慮考慮你的專案裡，那些承載複雜寫業務邏輯的場景裡，如何用mq來非同步寫，提公升併發性。mq單機抗幾萬併發也是ok的，這個之前還特意說過。
（4）如果mq還是扛不住，可能到了最後資料庫層面還是免不了抗高併發的要求，好吧，，就分庫分表，就將乙個資料庫拆分為多個庫，多個庫來抗更高的併發；然後將乙個表拆分為多個表，每個表的資料量保持少一點，提高sql跑的效能。
（5）當快取資料量很多時，可能會有很多快取失效，就來資料庫查詢，如果資料庫還是扛不住，就讀寫分離，這個就是說大部分時候資料庫可能也是讀多寫少，沒必要所有請求都集中在乙個庫上吧，可以搞個主從架構，主庫寫入，從庫讀取，搞乙個讀寫分離。讀流量太多的時候，還可以加更多的從庫。
（6）elasticsearch，可以考慮用es。es是分布式的，可以隨便擴容，分布式天然就可以支撐高併發，因為動不動就可以擴容加機器來抗更高的併發。那麼一些比較簡單的查詢、統計類的操作，可以考慮用es來承載，還有一些全文搜尋類的操作，也可以考慮用es來承載。
如何設計乙個高併發系統
總結如果你確實有真才實學，在網際網路公司裡幹過高併發系統，那你確實拿 offer 基本如探囊取物，沒啥問題。面試官也絕對不會這樣來問你，否則他就是蠢。假設你在某知名電商公司幹過高併發系統，使用者上億，一天流量幾十億，高峰期併發量上萬，甚至是十萬。那麼人家一定會仔細盤問你的系統架構，你們系統啥架構？怎...
如何設計乙個高併發系統
系統拆分，將乙個系統拆分為多個子系統，用dubbo來搞。然後每個系統連乙個資料庫，這樣本來就乙個庫，現在多個資料庫，不也可以抗高併發麼。快取，必須得用快取。大部分的高併發場景，都是讀多寫少，那你完全可以在資料庫和快取裡都寫乙份，然後讀的時候大量走快取不就得了。畢竟人家redis輕輕鬆鬆單機幾萬的併發...
設計乙個高併發系統
公升級過程為 最初系統 新增負載均衡 資料庫分庫分表 讀寫分離 快取集群 訊息中介軟體集群 假設系統機器是4核8g，資料庫伺服器是16核32g。日活使用者1w，系統層面每秒10次請求，資料庫層每秒30次請求。使用者量增長了50倍，日活使用者50萬，高峰期對系統每秒請求500 s，對資料庫的每秒請求1...