前言

大家好，我是田螺。

分享一道字節面試場景題：假設你負責的業務系統，流量突增，比如QPS暴增100倍，你要怎么處理？

有些伙伴一聽完題目，就不假思索回答，那就加機器呀、擴容什么的。當然，這個不能算錯，但是你只得其中一小點的分數，肯定不及格的。

作為一名優秀的后端開發程序員，我們應當從多個維度去思考這個問題，盡可能回答完整、正確。

• 緊急響應階段：快速止血
• 冷靜分析：為什么？暴增的流量合理嘛
• 健壯設計，增強系統身體素質
• 壓力測試，測試系統抗壓能力

1.緊急響應階段：快速止血

如果我們負責的系統，突發流量洪峰來了，超過系統的承載能力，為了保護我們的系統，需要快速止血!

1.1 限流

我們可以采取限流方案。其實就是保護系統，多余的請求，直接丟棄。

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

圖片

• 可以使用Guava的RateLimiter單機版限流，也可以使用Redis分布式限流，還可以使用阿里開源組件sentinel限流。
• 還可以通過令牌桶、漏桶算法限制請求速率，丟棄超出閾值的請求，避免系統過載。

• 令牌桶算法：系統以固定速率向桶中添加令牌，請求需獲取令牌才能被處理。若桶空則觸發限流。
• 漏桶算法：請求像水一樣流入漏桶，桶以恒定速率出水（處理請求）。桶滿則溢出觸發限流。

1.2 降級熔斷

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

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

圖片

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

因此，面對突發激增100倍的流量，我們可以采取熔斷降級。

• 熔斷：對非核心服務（如推薦、評論）啟用熔斷機制（如Hystrix），快速失敗以釋放資源，優先保障核心鏈路（如支付、下單）。
• 服務降級：關閉非關鍵功能（如數據分析、日志記錄），返回兜底數據（如緩存中的默認商品信息），降低后端壓力。

1.3 彈性擴容

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

• 擴容：比如增加從庫、提升配置的方式，提升系統/組件的流量承載能力。比如增加MySQL、Redis從庫來處理查詢請求。
• 切流量：服務多機房部署，如果高并發流量來了，把流量從一個機房切換到另一個機房。

1.4 消息隊列，削鋒

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

圖片

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

2.冷靜分析：為什么？暴增的流量是否合理？

面對突發流量，我們得思考清楚，這個QPS來源是否合理呢？

到底是因為雙十一、雙十二這些促銷活動，還是因為一些異常的流量呢（比如代碼產生的bug呀，或者是惡意攻擊等等）

• 我們得分析日志、監控等，如果是bug，得評估影響范圍，快速修復。
• 如果是惡意攻擊，我們得限制IP、加入黑名單、風控攔截等等。
• 如果是正常的促銷活動，我們得分析流量暴增的范圍、時間，比如單個接口還是所有接口呢？分析系統瓶頸是否符合壓測的指標（ CPU/內存/磁盤等等），確認是否要采取緊急處理。

3. 設計階段：健壯設計，增強系統身體素質

回到設計階段，我們如何避免這些突發的流量倍增呢？

3.1 分而治之，橫向擴展

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

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

3.2 微服務拆分（系統拆分）

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

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

圖片

3.3 分庫分表

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

因此，應對流量激增的場景，需要考慮拆分為多個數據庫，來抗住高并發的毒打。而假如你的單表數據量非常大，存儲和查詢的性能就會遇到瓶頸了，如果你做了很多優化之后還是無法提升效率的時候，就需要考慮做分表了。一般千萬級別數據量，就需要分表，每個表的數據量少一點，提升SQL查詢性能。

3.4 池化技術

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

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

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

3.5 使用緩存

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

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

3.6 異步

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

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

4.壓力測試，測試系統抗壓能力

壓力測試確定系統瓶頸。

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

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

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

5. 最后

假設你負責的業務系統，流量突增100倍。

• 我們可以通過限流、熔斷降級、擴容、流量削峰等手段，快速給系統止血。（快速止血）
• 我們止血后，我們快速定位問題，分析是bug還是惡意攻擊還是正常促銷引起的。（分析傷口原因）
• 我們通過橫向擴展、服務拆分、分庫分表、池化技術、緩存、異步、壓測等手段，增強系統身體素質。

最后補充一句，我們在設計階段，假設任何環節都會掛，做好兜底方案。