人人都開始聊高并發，高并發，那么所謂的高并發到底應該是啥，應該怎么理解這個高并發這個概念呢？這么說來就得要思考為啥會產生高并發？

簡單來說，因為我們從傳統的單體項目開始系統都是需要直接連接數據庫的，而數據庫支撐到每秒并發兩三千的時候，基本就快到極限了。因此，當我們剛開始設計系統的時候，就是一個簡單的單體項目直連數據庫，并沒考慮那么多，結果后期由于業務發展太快，有的時候并發流量過大系統扛不住壓力然后就掛了。

這種情況下數據庫掛掉是很正常的，每秒幾千，甚至上萬的并發直接打到數據庫，必然會宕機，因為mysql根本就扛不住這么高的并發量啊。

?

所以為啥高并發這個名詞這么火？就是因為現在互聯網用戶越來越多，很多互聯網站點、系統承載的都是高并發請求，高峰期每秒并發量幾千，都是很正常的。特別是在促銷活動比如京東六一八，天貓雙十一之類的，每秒并發幾萬幾十萬都有可能。

?

那么問題來了，面對如此之高的并發量，再加上原本已經如此之復雜的業務，怎么辦呢，怎么設計一個能支撐高并發的系統呢？我們來簡單聊聊：

（1）首先是系統拆分，我們可以將一個復雜的“大”系統拆分為多個子系統，可以用現在最流行的springcloud架構來做，然后對數據庫按業務進行垂直拆分，讓每個系統（服務）連一個數據庫，這樣的話相當于將原本一個大的庫拆分成多個數據庫，數據庫壓力就可以分攤到各個庫，也就可以抗高并發了。

（2）然后就是緩存，緩存在高并發系統中幾乎是必不可少的。因為大部分的高并發場景，都是讀多寫少，我們完全可以將訪問量大的數據在寫入數據庫的時候同時在緩存里再寫一份，然后讀的時候直接走緩存就行了。常用的緩存像redis輕輕松松單機幾萬的并發沒任何問題。另外真正的高并發系統一般是做多級緩存的，比如nginx緩存、redis緩存、jvm緩存等。所以你可以考慮在你的系統里對于那些需要承載主要讀請求的場景，怎么使用緩存來抗高并發。

（3）使用MQ，這個也是毋庸置疑的，也是高并發必備組件，畢竟MQ的功能之一就是流量削峰。因為系統中仍然有可能還是會出現高并發寫的場景，比如電商促銷活動或者秒殺活動下，你不可能直接將所有的訂單直接操作到數據庫中吧。想想那一瞬間的下單量，那高并發絕對搞掛你的數據庫，然后你的系統也就跟著掛了，而且這種寫的數據肯定不能用redis來承載的，畢竟redis是用來做緩存的，緩存是有過期策略的，寫滿了還會被redis的內存淘汰機制給清理了（LRU），而且redis數據格式太簡單了，也沒有標準的事務支持。所以總的來說還是得用mysql。那么怎么解決這個問題呢？這個時候MQ就派上用場了啊，我們直接將大量的寫請求（比如下單數據）寫入MQ中，依次排隊等候慢慢消費就行啦，我們只需要控制從MQ中每秒消費的請求控制在mysql承載范圍之內就ok了，比如mysql每秒最多支撐2000并發，那你就每秒從MQ從消費小于2000的請求就行了。所以你得考慮你的系統里，那些承載復雜寫業務邏輯的場景里，如何用MQ來異步寫，提升并發性。MQ單機抗幾萬并發也是ok的，而且是高可用的不會造成數據丟失。

（4）分庫分表，這個其實在第(1)點的時候就已經說明了，數據庫層面我們可以將一個數據庫拆分為多個庫，用來抗更高的并發；然后將一個表拆分為多個表，每個表的數據量保持少一點，提高sql的性能。

（5）讀寫分離，這個也是針對數據庫層面的，因為可能大部分時候數據庫也是讀多寫少，可以搞個主從架構，主庫寫入，從庫讀取，搞一個讀寫分離，避免所有請求直接打到一個數據庫中，分攤單庫的壓力。讀流量太多的時候，還可以加更多的從庫。

（6）可以考慮使用Elasticsearch。畢竟es是分布式的，擴展也方便，分布式天然就可以支撐高并發。針對全文搜索類、聚合類、統計類的操作，可以考慮用es來承載。

借圖：

?

上面介紹的，基本上一般是高并發系統都需要涉及到的幾個方面。

?

其實，像MQ、Redis、Elasticsearch這種一門或者幾門技術的基本使用對一般開發者來說都不是什么難事，難得是怎么把這些技術結合起來，一步步架構、設計整合到我們的具體的業務場景中，形成一個分布式架構系統，讓我們的系統能真正支持高并發。

?

關注微信公眾號“蝦米聊吧”，一起學習，一起進步！

微信掃描二維碼，關注我的公眾號

總結

以上是生活随笔為你收集整理的如何设计一个高并发系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。