前言

大家好，我是田螺。

分享一道字節(jié)面試場(chǎng)景題：假設(shè)你負(fù)責(zé)的業(yè)務(wù)系統(tǒng)，流量突增，比如QPS暴增100倍，你要怎么處理？

有些伙伴一聽完題目，就不假思索回答，那就加機(jī)器呀、擴(kuò)容什么的。當(dāng)然，這個(gè)不能算錯(cuò)，但是你只得其中一小點(diǎn)的分?jǐn)?shù)，肯定不及格的。

作為一名優(yōu)秀的后端開發(fā)程序員，我們應(yīng)當(dāng)從多個(gè)維度去思考這個(gè)問題，盡可能回答完整、正確。

• 緊急響應(yīng)階段：快速止血
• 冷靜分析：為什么？暴增的流量合理嘛
• 健壯設(shè)計(jì)，增強(qiáng)系統(tǒng)身體素質(zhì)
• 壓力測(cè)試，測(cè)試系統(tǒng)抗壓能力

1.緊急響應(yīng)階段：快速止血

如果我們負(fù)責(zé)的系統(tǒng)，突發(fā)流量洪峰來了，超過系統(tǒng)的承載能力，為了保護(hù)我們的系統(tǒng)，需要快速止血!

1.1 限流

我們可以采取限流方案。其實(shí)就是保護(hù)系統(tǒng)，多余的請(qǐng)求，直接丟棄。

什么是限流：在計(jì)算機(jī)網(wǎng)絡(luò)中，限流就是控制網(wǎng)絡(luò)接口發(fā)送或接收請(qǐng)求的速率，它可防止DoS攻擊和限制Web爬蟲。限流，也稱流量控制。是指系統(tǒng)在面臨高并發(fā)，或者大流量請(qǐng)求的情況下，限制新的請(qǐng)求對(duì)系統(tǒng)的訪問，從而保證系統(tǒng)的穩(wěn)定性。

圖片

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

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

1.2 降級(jí)熔斷

熔斷降級(jí)是保護(hù)系統(tǒng)的一種手段。當(dāng)前互聯(lián)網(wǎng)系統(tǒng)一般都是分布式部署的。而分布式系統(tǒng)中偶爾會(huì)出現(xiàn)某個(gè)基礎(chǔ)服務(wù)不可用，最終導(dǎo)致整個(gè)系統(tǒng)不可用的情況, 這種現(xiàn)象被稱為服務(wù)雪崩效應(yīng)。

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

圖片

如果服務(wù)C出現(xiàn)問題，比如是因?yàn)槁?code style="background-color: rgb(231, 243, 237); padding: 1px 3px; border-radius: 4px; overflow-wrap: break-word; text-indent: 0px; display: inline-block;">SQL導(dǎo)致調(diào)用緩慢，那將導(dǎo)致B也會(huì)延遲，從而A也會(huì)延遲。堵住的A請(qǐng)求會(huì)消耗占用系統(tǒng)的線程、IO、CPU等資源。當(dāng)請(qǐng)求A的服務(wù)越來越多，占用計(jì)算機(jī)的資源也越來越多，最終會(huì)導(dǎo)致系統(tǒng)瓶頸出現(xiàn)，造成其他的請(qǐng)求同樣不可用，最后導(dǎo)致業(yè)務(wù)系統(tǒng)崩潰。

因此，面對(duì)突發(fā)激增100倍的流量，我們可以采取熔斷降級(jí)。

• 熔斷：對(duì)非核心服務(wù)（如推薦、評(píng)論）啟用熔斷機(jī)制（如Hystrix），快速失敗以釋放資源，優(yōu)先保障核心鏈路（如支付、下單）。
• 服務(wù)降級(jí)：關(guān)閉非關(guān)鍵功能（如數(shù)據(jù)分析、日志記錄），返回兜底數(shù)據(jù)（如緩存中的默認(rèn)商品信息），降低后端壓力。

1.3 彈性擴(kuò)容

如果是突發(fā)的流量高峰，除了降級(jí)、限流保證系統(tǒng)不跨，我們還可以采用這兩種方案，保證系統(tǒng)盡可能服務(wù)用戶請(qǐng)求：

• 擴(kuò)容：比如增加從庫(kù)、提升配置的方式，提升系統(tǒng)/組件的流量承載能力。比如增加MySQL、Redis從庫(kù)來處理查詢請(qǐng)求。
• 切流量：服務(wù)多機(jī)房部署，如果高并發(fā)流量來了，把流量從一個(gè)機(jī)房切換到另一個(gè)機(jī)房。

1.4 消息隊(duì)列，削鋒

我們搞一些雙十一、雙十二等運(yùn)營(yíng)活動(dòng)時(shí)，需要避免流量暴漲，打垮應(yīng)用系統(tǒng)的風(fēng)險(xiǎn)。因此一般會(huì)引入消息隊(duì)列，來應(yīng)對(duì)高并發(fā)的場(chǎng)景。

圖片

假設(shè)你的應(yīng)用系統(tǒng)每秒最多可以處理2k個(gè)請(qǐng)求，每秒?yún)s有5k的請(qǐng)求過來，可以引入消息隊(duì)列，應(yīng)用系統(tǒng)每秒從消息隊(duì)列拉2k請(qǐng)求處理得了。

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

面對(duì)突發(fā)流量，我們得思考清楚，這個(gè)QPS來源是否合理呢？

到底是因?yàn)殡p十一、雙十二這些促銷活動(dòng)，還是因?yàn)橐恍┊惓５牧髁磕兀ū热绱a產(chǎn)生的bug呀，或者是惡意攻擊等等）

• 我們得分析日志、監(jiān)控等，如果是bug，得評(píng)估影響范圍，快速修復(fù)。
• 如果是惡意攻擊，我們得限制IP、加入黑名單、風(fēng)控?cái)r截等等。
• 如果是正常的促銷活動(dòng)，我們得分析流量暴增的范圍、時(shí)間，比如單個(gè)接口還是所有接口呢？分析系統(tǒng)瓶頸是否符合壓測(cè)的指標(biāo)（ CPU/內(nèi)存/磁盤等等），確認(rèn)是否要采取緊急處理。

3. 設(shè)計(jì)階段：健壯設(shè)計(jì)，增強(qiáng)系統(tǒng)身體素質(zhì)

回到設(shè)計(jì)階段，我們?nèi)绾伪苊膺@些突發(fā)的流量倍增呢？

3.1 分而治之，橫向擴(kuò)展

如果你只部署一個(gè)應(yīng)用，只部署一臺(tái)服務(wù)器，那抗住的流量請(qǐng)求是非常有限的。并且，單體的應(yīng)用，有單點(diǎn)的風(fēng)險(xiǎn)，如果它掛了，那服務(wù)就不可用了。

因此，設(shè)計(jì)一個(gè)高并發(fā)系統(tǒng)，我們可以分而治之，橫向擴(kuò)展。也就是說，采用分布式部署的方式，部署多臺(tái)服務(wù)器，把流量分流開，讓每個(gè)服務(wù)器都承擔(dān)一部分的并發(fā)和流量，提升整體系統(tǒng)的并發(fā)能力。

3.2 微服務(wù)拆分（系統(tǒng)拆分）

要提高系統(tǒng)的吞吐，提高系統(tǒng)的處理并發(fā)請(qǐng)求的能力。除了采用分布式部署的方式外，還可以做微服務(wù)拆分，這樣就可以達(dá)到分?jǐn)傉?qǐng)求流量的目的，提高了并發(fā)能力。

所謂的微服務(wù)拆分，其實(shí)就是把一個(gè)單體的應(yīng)用，按功能單一性，拆分為多個(gè)服務(wù)模塊。比如一個(gè)電商系統(tǒng)，拆分為用戶系統(tǒng)、訂單系統(tǒng)、商品系統(tǒng)等等。

圖片

3.3 分庫(kù)分表

當(dāng)業(yè)務(wù)量暴增的話，MySQL單機(jī)磁盤容量會(huì)撐爆。并且，我們知道數(shù)據(jù)庫(kù)連接數(shù)是有限的。在高并發(fā)的場(chǎng)景下，大量請(qǐng)求訪問數(shù)據(jù)庫(kù)，MySQL單機(jī)是扛不住的！高并發(fā)（流量倍增）場(chǎng)景下，會(huì)出現(xiàn)too many connections報(bào)錯(cuò)。

因此，應(yīng)對(duì)流量激增的場(chǎng)景，需要考慮拆分為多個(gè)數(shù)據(jù)庫(kù)，來抗住高并發(fā)的毒打。而假如你的單表數(shù)據(jù)量非常大，存儲(chǔ)和查詢的性能就會(huì)遇到瓶頸了，如果你做了很多優(yōu)化之后還是無法提升效率的時(shí)候，就需要考慮做分表了。一般千萬級(jí)別數(shù)據(jù)量，就需要分表，每個(gè)表的數(shù)據(jù)量少一點(diǎn)，提升SQL查詢性能。

3.4 池化技術(shù)

在高并發(fā)的場(chǎng)景下，數(shù)據(jù)庫(kù)連接數(shù)可能成為瓶頸，因?yàn)檫B接數(shù)是有限的。

我們的請(qǐng)求調(diào)用數(shù)據(jù)庫(kù)時(shí)，都會(huì)先獲取數(shù)據(jù)庫(kù)的連接，然后依靠這個(gè)連接來查詢數(shù)據(jù)，搞完收工，最后關(guān)閉連接，釋放資源。如果我們不用數(shù)據(jù)庫(kù)連接池的話，每次執(zhí)行SQL，都要?jiǎng)?chuàng)建連接和銷毀連接，這就會(huì)導(dǎo)致每個(gè)查詢請(qǐng)求都變得更慢了，相應(yīng)的，系統(tǒng)處理用戶請(qǐng)求的能力就降低了。

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

3.5 使用緩存

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

常用的緩存包括：Redis緩存，JVM本地緩存，memcached等等。就拿Redis來說，它單機(jī)就能輕輕松松應(yīng)對(duì)幾萬的并發(fā)，你讀場(chǎng)景的業(yè)務(wù)，可以用緩存來抗高并發(fā)。

3.6 異步

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

因此，設(shè)計(jì)一個(gè)應(yīng)對(duì)激增流量的高并發(fā)系統(tǒng)，需要在恰當(dāng)?shù)膱?chǎng)景使用異步。如何使用異步呢？后端可以借用消息隊(duì)列實(shí)現(xiàn)。比如在海量秒殺請(qǐng)求過來時(shí)，先放到消息隊(duì)列中，快速響應(yīng)用戶，告訴用戶請(qǐng)求正在處理中，這樣就可以釋放資源來處理更多的請(qǐng)求。秒殺請(qǐng)求處理完后，通知用戶秒殺搶購(gòu)成功或者失敗。

4.壓力測(cè)試，測(cè)試系統(tǒng)抗壓能力

壓力測(cè)試確定系統(tǒng)瓶頸。

設(shè)計(jì)高并發(fā)系統(tǒng)，離不開最重要的一環(huán)，就是壓力測(cè)試。就是在系統(tǒng)上線前，需要對(duì)系統(tǒng)進(jìn)行壓力測(cè)試，測(cè)清楚你的系統(tǒng)支撐的最大并發(fā)是多少，確定系統(tǒng)的瓶頸點(diǎn)，讓自己心里有底，最好預(yù)防措施。

壓測(cè)完要分析整個(gè)調(diào)用鏈路，性能可能出現(xiàn)問題是網(wǎng)絡(luò)層（如帶寬）、Nginx層、服務(wù)層、還是數(shù)據(jù)路緩存等中間件等等。

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

5. 最后

假設(shè)你負(fù)責(zé)的業(yè)務(wù)系統(tǒng)，流量突增100倍。

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

最后補(bǔ)充一句，我們?cè)谠O(shè)計(jì)階段，假設(shè)任何環(huán)節(jié)都會(huì)掛，做好兜底方案。