高併發系統設計的 15 個錦囊

前言

大家好，我是田螺。

記得很久之前，去面試過字節跳動。被三面的面試官問了一道場景設計題目：如何設計一個高併發系統。當時我回答得比較粗糙，最近回想起來，所以整理了設計高併發系統的 15 個錦囊，相信大家看完會有幫助的。

如何理解高併發系統

所謂設計高併發系統，就是設計一個系統，保證它整體可用的同時，能夠處理很高的併發用戶請求，能夠承受很大的流量衝擊。

我們要設計高併發的系統，那就需要處理好一些常見的系統瓶頸問題，如內存不足、磁盤空間不足，連接數不夠，網絡寬帶不夠等等，以應對突發的流量洪峯。

1. 分而治之，橫向擴展

如果你只部署一個應用，只部署一臺服務器，那抗住的流量請求是非常有限的。並且，單體的應用，有單點的風險，如果它掛了，那服務就不可用了。

因此，設計一個高併發系統，我們可以分而治之，橫向擴展。也就是說，採用分佈式部署的方式，部署多臺服務器，把流量分流開，讓每個服務器都承擔一部分的併發和流量，提升整體系統的併發能力。

2. 微服務拆分（系統拆分）

要提高系統的吞吐，提高系統的處理併發請求的能力。除了採用分佈式部署的方式外，還可以做微服務拆分，這樣就可以達到分攤請求流量的目的，提高了併發能力。

所謂的微服務拆分，其實就是把一個單體的應用，按功能單一性，拆分爲多個服務模塊。比如一個電商系統，拆分爲用戶系統、訂單系統、商品系統等等。

3. 分庫分表

當業務量暴增的話，MySQL 單機磁盤容量會撐爆。並且，我們知道數據庫連接數是有限的。在高併發的場景下，大量請求訪問數據庫，MySQL單機是扛不住的！高併發場景下，會出現too many connections報錯。

所以高併發的系統，需要考慮拆分爲多個數據庫，來抗住高併發的毒打。而假如你的單表數據量非常大，存儲和查詢的性能就會遇到瓶頸了，如果你做了很多優化之後還是無法提升效率的時候，就需要考慮做分表了。一般千萬級別數據量，就需要分表，每個表的數據量少一點，提升 SQL 查詢性能。

當面試官問要求你設計一個高併發系統的時候，一般都要說到分庫分表這個點。

之前寫了分庫分表 15 連問，爲了應對面試官追問到底，大家可以順便複習一下分庫分表的相關經典面試題哈，可以看我這篇文章：分庫分表經典 15 連問

4. 池化技術

在高併發的場景下，數據庫連接數可能成爲瓶頸，因爲連接數是有限的。

我們的請求調用數據庫時，都會先獲取數據庫的連接，然後依靠這個連接來查詢數據，搞完收工，最後關閉連接，釋放資源。如果我們不用數據庫連接池的話，每次執行SQL，都要創建連接和銷燬連接，這就會導致每個查詢請求都變得更慢了，相應的，系統處理用戶請求的能力就降低了。

因此，需要使用池化技術，即數據庫連接池、HTTP 連接池、Redis 連接池等等。使用數據庫連接池，可以避免每次查詢都新建連接，減少不必要的資源開銷，通過複用連接池，提高系統處理高併發請求的能力。

同理，我們使用線程池，也能讓任務並行處理，更高效地完成任務。大家可以看下我之前線程池的這篇文章，到時候面試官問到這塊時，剛好可以擴展開來講

• 面試必備：Java 線程池解析

• 細數線程池的 10 個坑

5. 主從分離

通常來說，一臺單機的 MySQL 服務器，可以支持500左右的TPS和10000左右的QPS，即單機支撐的請求訪問是有限的。因此你做了分佈式部署，部署了多臺機器，部署了主數據庫、從數據庫。

但是，如果雙十一搞活動，流量肯定會猛增的。如果所有的查詢請求，都走主庫的話，主庫肯定扛不住，因爲查詢請求量是非常非常大的。因此一般都要求做主從分離，然後實時性要求不高的讀請求，都去讀從庫，寫的請求或者實時性要求高的請求，才走主庫。這樣就很好保護了主庫，也提高了系統的吞吐。

當然，如果回答了主從分離，面試官可能擴展開問你主從複製原理，問你主從延遲問題等等，這塊大家需要全方位複習好哈。可以去看看我之前的這篇文章

面試必備：聊聊 MySQL 的主從

6. 使用緩存

無論是操作系統，瀏覽器，還是一些複雜的中間件，你都可以看到緩存的影子。我們使用緩存，主要是提升系統接口的性能，這樣高併發場景，你的系統就可以支持更多的用戶同時訪問。

常用的緩存包括：Redis緩存，JVM本地緩存，memcached等等。就拿Redis來說，它單機就能輕輕鬆鬆應對幾萬的併發，你讀場景的業務，可以用緩存來抗高併發。

緩存雖然用得爽，但是要注意緩存使用的一些問題：

• 緩存與數據庫的一致性問題

• 緩存雪崩

• 緩存穿透

• 緩存擊穿

如果大家打算使用Redis的話，需要知道一些注意點，可以看下我之前的這篇文章哈，挺好的。使用 Redis，你必須知道的 21 個注意要點

7. CDN，加速靜態資源訪問

商品圖片，icon等等靜態資源，可以對頁面做靜態化處理，減少訪問服務端的請求。如果用戶分佈在全國各地，有的在上海，有的在深圳，地域相差很遠，網速也各不相同。爲了讓用戶最快訪問到頁面，可以使用CDN。CDN可以讓用戶就近獲取所需內容。

什麼是 CDN？

Content Delivery Network/Content Distribution Network, 翻譯過來就是內容分發網絡，它表示將靜態資源分發到位於多個地理位置機房的服務器，可以做到數據就近訪問，加速了靜態資源的訪問速度，因此讓系統更好處理正常別的動態請求。

8. 消息隊列，削鋒

我們搞一些雙十一、雙十二等運營活動時，需要避免流量暴漲，打垮應用系統的風險。因此一般會引入消息隊列，來應對高併發的場景。

假設你的應用系統每秒最多可以處理2k個請求，每秒卻有5k的請求過來，可以引入消息隊列，應用系統每秒從消息隊列拉2k請求處理得了。

有些夥伴擔心這樣可能會出現消息積壓的問題：

• 首先，搞一些運營活動，不會每時每刻都那麼多請求過來你的系統（除非有人惡意攻擊），高峯期過去後，積壓的請求可以慢慢處理；

• 其次，如果消息隊列長度超過最大數量，可以直接拋棄用戶請求或跳轉到錯誤頁面；

9. ElasticSearch

Elasticsearch，大家都使用得比較多了吧，一般搜索功能都會用到它。它是一個分佈式、高擴展、高實時的搜索與數據分析引擎，簡稱爲ES。

我們在聊高併發，爲啥聊到ES呢？因爲ES可以擴容方便，天然支撐高併發。當數據量大的時候，不用動不動就加機器擴容，分庫等等，可以考慮用ES來支持簡單的查詢搜索、統計類的操作。

10. 降級熔斷

熔斷降級是保護系統的一種手段。當前互聯網系統一般都是分佈式部署的。而分佈式系統中偶爾會出現某個基礎服務不可用，最終導致整個系統不可用的情況, 這種現象被稱爲服務雪崩效應。

比如分佈式調用鏈路A->B->C....，下圖所示：

如果服務C出現問題，比如是因爲慢SQL導致調用緩慢，那將導致B也會延遲，從而A也會延遲。堵住的A請求會消耗佔用系統的線程、IO、CPU 等資源。當請求A的服務越來越多，佔用計算機的資源也越來越多，最終會導致系統瓶頸出現，造成其他的請求同樣不可用，最後導致業務系統崩潰。

爲了應對服務雪崩, 常見的做法是熔斷和降級。最簡單是加開關控制，當下遊系統出問題時，開關打開降級，不再調用下游系統。還可以選用開源組件Hystrix來支持。

你要保證設計的系統能應對高併發場景，那肯定要考慮熔斷降級邏輯進來。

11. 限流

限流也是我們應對高併發的一種方案。我們當然希望，在高併發大流量過來時，系統能全部請求都正常處理。但是有時候沒辦法，系統的 CPU、網絡帶寬、內存、線程等資源都是有限的。因此，我們要考慮限流。

如果你的系統每秒扛住的請求是一千，如果一秒鐘來了十萬請求呢？換個角度就是說，高併發的時候，流量洪峯來了，超過系統的承載能力，怎麼辦呢？

這時候，我們可以採取限流方案。就是爲了保護系統，多餘的請求，直接丟棄。

什麼是限流：在計算機網絡中，限流就是控制網絡接口發送或接收請求的速率，它可防止 DoS 攻擊和限制 Web 爬蟲。限流，也稱流量控制。是指系統在面臨高併發，或者大流量請求的情況下，限制新的請求對系統的訪問，從而保證系統的穩定性。

可以使用Guava的RateLimiter單機版限流，也可以使用Redis分佈式限流，還可以使用阿里開源組件sentinel限流。

面試的時候，你說到限流這塊的話？面試官很大概率會問你限流的算法，因此，大家在準備面試的時候，需要複習一下這幾種經典的限流算法哈，可以看下我之前的這篇文章，面試必備：4 種經典限流算法講解

12. 異步

回憶一下什麼是同步，什麼是異步呢？以方法調用爲例，它代表調用方要阻塞等待被調用方法中的邏輯執行完成。這種方式下，當被調用方法響應時間較長時，會造成調用方長久的阻塞，在高併發下會造成整體系統性能下降甚至發生雪崩。異步調用恰恰相反，調用方不需要等待方法邏輯執行完成就可以返回執行其他的邏輯，在被調用方法執行完畢後再通過回調、事件通知等方式將結果反饋給調用方。

因此，設計一個高併發的系統，需要在恰當的場景使用異步。如何使用異步呢？後端可以借用消息隊列實現。比如在海量秒殺請求過來時，先放到消息隊列中，快速響應用戶，告訴用戶請求正在處理中，這樣就可以釋放資源來處理更多的請求。秒殺請求處理完後，通知用戶秒殺搶購成功或者失敗。

13. 接口的常規優化

設計一個高併發的系統，需要設計接口的性能足夠好，這樣系統在相同時間，就可以處理更多的請求。當說到這裏的話，可以跟面試官說說接口優化的一些方案了。大家可以看下我的這篇文章哈: 實戰總結！18 種接口優化方案的總結

14. 壓力測試確定系統瓶頸

設計高併發系統，離不開最重要的一環，就是壓力測試。就是在系統上線前，需要對系統進行壓力測試，測清楚你的系統支撐的最大併發是多少，確定系統的瓶頸點，讓自己心裏有底，最好預防措施。

壓測完要分析整個調用鏈路，性能可能出現問題是網絡層（如帶寬）、Nginx 層、服務層、還是數據路緩存等中間件等等。

loadrunner是一款不錯的壓力測試工具，jmeter則是接口性能測試工具，都可以來做下壓測。

15. 應對突發流量峯值：擴容 + 切流量

如果是突發的流量高峯，除了降級、限流保證系統不跨，我們可以採用這兩種方案，保證系統儘可能服務用戶請求：

• 擴容：比如增加從庫、提升配置的方式，提升系統 / 組件的流量承載能力。比如增加MySQL、Redis從庫來處理查詢請求。

• 切流量：服務多機房部署，如果高併發流量來了，把流量從一個機房切換到另一個機房。

參考與感謝

• 極客時間高併發系統設計 40 問 [1]

參考資料

[1]

極客時間高併發系統設計 40 問: https://time.geekbang.org/column/article/192203

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/PPA8Iw6K2M2xVnGE-Tf6zw