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

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：空間域名、虛擬空間、營銷軟件、網站建設、平遠網站維護、網站推廣。

該怎么回答這個面試題：

可以分為以下 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，高并發這一塊，你了解了，也只能是次一等的人才。對一個有幾十萬行代碼的復雜的分布式系統，一步一步架構、設計以及實踐過高并發架構的人，這個經驗是難能可貴的。

新聞名稱：怎樣設計一個高并發系統？
當前地址：http://www.yijiale78.com/article40/peheho.html

成都網站建設公司_創新互聯，為您提供微信公眾號、搜索引擎優化、網站內鏈、外貿網站建設、網站建設、網站排名

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯