我有話想說(shuō)

這篇文章的構(gòu)思始于2023年，受限于個(gè)人經(jīng)驗(yàn)與知識(shí)積累，初稿拖延至2025年1月才最終完成。在此過(guò)程中，許多同行大佬慷慨提供了審稿意見(jiàn)與建議，對(duì)此我深表感謝。

這是接近一篇萬(wàn)字長(zhǎng)文，為方便大家閱讀，我整理了文章的大綱并以思維導(dǎo)圖的形式展示。你可以根據(jù)自己的興趣點(diǎn)選擇性閱讀，希望這篇文章能為你應(yīng)對(duì)高并發(fā)場(chǎng)景提供啟發(fā)與幫助。

特別鳴謝：韓楠、王君、杜小非、冼潤(rùn)偉、李鴻庭（排名不分先后）

前言

在互聯(lián)網(wǎng)時(shí)代，高并發(fā)已經(jīng)成為后端開(kāi)發(fā)者繞不開(kāi)的話題。無(wú)論是電商平臺(tái)的秒殺活動(dòng)、搶購(gòu)系統(tǒng)，還是社交應(yīng)用的高頻互動(dòng)，高并發(fā)場(chǎng)景的出現(xiàn)往往伴隨著巨大的技術(shù)挑戰(zhàn)。

如何在流量激增的同時(shí)，確保系統(tǒng)穩(wěn)定運(yùn)行、快速響應(yīng)？這不僅是對(duì)技術(shù)能力的考驗(yàn)，更是對(duì)架構(gòu)設(shè)計(jì)和資源優(yōu)化的綜合考量。

在多年的工作實(shí)踐中，我有幸接觸并解決了許多高并發(fā)場(chǎng)景的實(shí)際問(wèn)題。因此，在這篇文章中，我將結(jié)合理論與實(shí)踐，深入剖析高并發(fā)的本質(zhì)、應(yīng)對(duì)策略，以及實(shí)際案例，希望能夠?yàn)槟憬议_(kāi)高并發(fā)背后的技術(shù)奧秘。

文中提到的高并發(fā)“標(biāo)準(zhǔn)”、三字真言——“砍、緩、多”，以及七大處理手段，均是我在工作中總結(jié)出的經(jīng)驗(yàn)。這些方法并非涵蓋所有可能的解決方案，但我希望它們能為你提供思路，同時(shí)也歡迎大家補(bǔ)充和交流。

什么是高并發(fā)？

百度百科：

通俗來(lái)講，高并發(fā)是指在同一個(gè)時(shí)間點(diǎn)，有很多用戶(hù)同時(shí)訪問(wèn)同一API接口或者Url地址。它經(jīng)常會(huì)發(fā)生在有大活躍用戶(hù)量，用戶(hù)高聚集的業(yè)務(wù)場(chǎng)景中

簡(jiǎn)單的說(shuō)，高并發(fā)是指系統(tǒng)在同一時(shí)間內(nèi)接受到大量的客戶(hù)端請(qǐng)求訪問(wèn)，需要系統(tǒng)（服務(wù)端）能夠快速響應(yīng)并處理請(qǐng)求的能力。在咱們互聯(lián)網(wǎng)應(yīng)用中，例如電商、游戲等在做活動(dòng)或者促銷(xiāo)的時(shí)候，這些熱點(diǎn)業(yè)務(wù)就非常大可能同時(shí)被大量用戶(hù)訪問(wèn)，并造成系統(tǒng)較大的負(fù)載。高并發(fā)一般伴隨著數(shù)據(jù)增長(zhǎng)、流量增加，這種現(xiàn)象可能是短時(shí)間的內(nèi)的峰值，也可能是持續(xù)不斷負(fù)載壓力，因此需要開(kāi)發(fā)在架構(gòu)設(shè)計(jì)、技術(shù)選型、性能監(jiān)控等多個(gè)方面進(jìn)行優(yōu)化、調(diào)整以提高系統(tǒng)的并發(fā)處理能力。

并發(fā)與并行的區(qū)別是什么？

并發(fā)和并行都涉及到同一時(shí)刻處理多個(gè)任務(wù)，但它們的概念和實(shí)現(xiàn)方式略有不同。

并發(fā)，指的是多個(gè)事情，在同一時(shí)間段內(nèi)同時(shí)發(fā)生了。 并行，指的是多個(gè)事情，在同一時(shí)間點(diǎn)上同時(shí)發(fā)生了。

并發(fā)，是指一個(gè)系統(tǒng)能夠同時(shí)處理多個(gè)任務(wù)或者請(qǐng)求，并且看起來(lái)好像這些任務(wù)是同時(shí)執(zhí)行的。實(shí)際上，這些任務(wù)只是在最短時(shí)間內(nèi)交替執(zhí)行，因?yàn)橛?jì)算機(jī)的處理速度非?？欤缭谝粋€(gè) CPU 上同時(shí)運(yùn)行多個(gè)應(yīng)用程序或是處理多個(gè)網(wǎng)絡(luò)請(qǐng)求。

并行，是指一個(gè)系統(tǒng)可以真正意義上同時(shí)處理多個(gè)任務(wù)或請(qǐng)求，因?yàn)樗卸鄠€(gè)執(zhí)行單元，可以同時(shí)執(zhí)行多個(gè)任務(wù)或請(qǐng)求。例如在擁有多個(gè) CPU 或多個(gè)核心的服務(wù)器上，可以同時(shí)處理多個(gè)請(qǐng)求或任務(wù)，這就是并行處理。

雖然兩者一字之差，但是我認(rèn)為他們屬于不同層面上的概念：

• 并發(fā)屬于是表達(dá)了指令發(fā)起端到指令執(zhí)行端的請(qǐng)求情況（系統(tǒng)外部）（系統(tǒng)外部）；
• 并行屬于是描述了系統(tǒng)（應(yīng)用）執(zhí)行任務(wù)時(shí)的模式（系統(tǒng)內(nèi)部）。

高并發(fā)的怎樣才算高？

不同的讀者看到這里的時(shí)候，心里都會(huì)有一個(gè)答案：

• 擁有大項(xiàng)目經(jīng)歷的同行肯定想，沒(méi)個(gè)幾十萬(wàn)、上百萬(wàn)的QPS都不叫高并發(fā)吧？
• 萌新可能認(rèn)為，我平常系統(tǒng)峰值最高就兩三千的 QPS，那么起碼也得高一個(gè)量級(jí)才算吧？

我是這么認(rèn)為的：

高并發(fā)的高并沒(méi)有一個(gè)具體的量化標(biāo)準(zhǔn)的，并不是必須得多少個(gè)萬(wàn)級(jí)別的 QPS 才算是高，因?yàn)椤?strong class="ql-author-78617836" style="margin: 0px; padding: 0px;">高】在物理學(xué)里是相對(duì)的概念。

對(duì)于小型的系統(tǒng)或ToB系統(tǒng)來(lái)說(shuō)，如果初期架構(gòu)設(shè)計(jì)沒(méi)考慮好或者資源有限，幾百上千的 QPS 的并發(fā)訪問(wèn)可能已經(jīng)會(huì)對(duì)系統(tǒng)造成一定的壓力；

對(duì)于大型互聯(lián)網(wǎng)公司或應(yīng)用，每秒鐘數(shù)萬(wàn)甚至數(shù)十萬(wàn)的并發(fā)訪問(wèn)甚至峰值達(dá)到百萬(wàn)級(jí)這都并不罕見(jiàn)。

因此，在討論高并發(fā)時(shí)，我們不必將其想象為極端數(shù)量級(jí)的并發(fā)情況。關(guān)鍵在于理解特定業(yè)務(wù)場(chǎng)景下，在何種條件（包括人力、技術(shù)力、計(jì)算力）下，為了達(dá)到既定目標(biāo)（如穩(wěn)定性、安全性、用戶(hù)體驗(yàn)）而需要處理的并發(fā)量。

基于這些因素，當(dāng)并發(fā)量達(dá)到一定水平，足以影響這些目標(biāo)時(shí)，我們通常將這種情況視為高并發(fā)。這樣的判斷并不僅僅基于并發(fā)量的增加是否達(dá)到了某個(gè)具體的“高并發(fā)”標(biāo)準(zhǔn)。

高性能等于高并發(fā)嗎？

首先，高并發(fā)與高性能之間確實(shí)存在直接的聯(lián)系。高性能指的是系統(tǒng)或應(yīng)用程序能夠迅速處理單一請(qǐng)求的能力，這意味著在相同的時(shí)間內(nèi)，一個(gè)性能更優(yōu)的系統(tǒng)能夠處理更多的請(qǐng)求，從而提升其并發(fā)處理能力。

以一個(gè)系統(tǒng)接口為例，假設(shè)它在單線程環(huán)境下能夠達(dá)到每秒100次查詢(xún)（100QPS），這意味著處理單個(gè)請(qǐng)求的時(shí)間大約是0.01秒。如果我們將處理速度提升十倍，即每個(gè)請(qǐng)求的處理時(shí)間縮短到0.001秒，那么理論上的QPS可以提升到1000QPS。這個(gè)例子清晰地展示了高性能與高并發(fā)之間的正相關(guān)性。

然而，高性能與高并發(fā)并非完全等同。

• 高性能關(guān)注單個(gè)請(qǐng)求的處理效率，
• 高并發(fā)關(guān)注系統(tǒng)同時(shí)處理大量請(qǐng)求的能力。

一個(gè)系統(tǒng)即使設(shè)計(jì)之初就考慮了高并發(fā)，能夠同時(shí)接收大量請(qǐng)求，但如果單個(gè)請(qǐng)求的處理時(shí)間較長(zhǎng)，其響應(yīng)速度和整體性能可能仍不理想。

例如，某接口通過(guò)隊(duì)列異步處理請(qǐng)求，雖然能應(yīng)對(duì)高并發(fā)，但如果隊(duì)列設(shè)計(jì)不合理或任務(wù)本身耗時(shí)較長(zhǎng)（如5-8秒），會(huì)影響用戶(hù)的實(shí)時(shí)體驗(yàn)。

綜上所述，盡管高性能與高并發(fā)緊密相關(guān)，它們并不是同一概念。實(shí)際上，高性能的解決方案可以視為高并發(fā)解決方案的一個(gè)重要組成部分，但高并發(fā)系統(tǒng)的設(shè)計(jì)還需綜合考慮分布式架構(gòu)、緩存、限流等技術(shù)，以?xún)?yōu)化整體性能和用戶(hù)體驗(yàn)。

不滿(mǎn)足高并發(fā)會(huì)有什么后果？

在高并發(fā)環(huán)境下，如果系統(tǒng)不能有效處理大量并發(fā)請(qǐng)求，可能會(huì)導(dǎo)致多種嚴(yán)重后果，影響系統(tǒng)的性能和用戶(hù)體驗(yàn)。

下圖是系統(tǒng)在高并發(fā)場(chǎng)景下不同的層面的后果表現(xiàn)：

然而我們后端開(kāi)發(fā)關(guān)注的層面更多是偏向于接口、數(shù)據(jù)庫(kù)還有服務(wù)器層面，因此我根據(jù)上圖我重新篩選與整理了一份詳細(xì)的表格如下：

有哪些通用的高并發(fā)方案？

通過(guò)上述我們清楚的了解到高并發(fā)處理不當(dāng)?shù)膰?yán)重性，那么究竟有沒(méi)有拿來(lái)即用的方案直接套上去就可以解決了呢？

有，我把過(guò)往的經(jīng)驗(yàn)總接了一下，從大方向來(lái)看一共三大類(lèi)：限流、異步、冗余。

這三個(gè)詞，我相信大家都不陌生，我也給他們都各用一句話來(lái)描述。

1. 限流，溢出的流量就不要了
2. 異步，不著急的任務(wù)就放緩處理
3. 冗余，弄多幾個(gè)副本分擔(dān)壓力

因此，高并發(fā)的通用解決方案我認(rèn)為無(wú)疑就是三字真言：砍、緩、多。

每個(gè)類(lèi)型其實(shí)又細(xì)分共七大處理手段，我整理了一張表格給到各位，毫不夸張說(shuō)，從我過(guò)往經(jīng)驗(yàn)來(lái)看，以下方案可以解決我們?nèi)粘Ｓ龅?0%的并發(fā)問(wèn)題。

 三字真言，七大處理手段固然好使，但是并不代表可以濫用，像限流、集群、緩存等更多屬于短期收益高的應(yīng)急手段。

舉個(gè)例子，可能我們的問(wèn)題其實(shí)就是一個(gè)慢查詢(xún)導(dǎo)致的數(shù)據(jù)庫(kù)負(fù)載過(guò)高，從而影響了應(yīng)用的工作線程數(shù)阻塞，最后影響到了應(yīng)用服務(wù)器的CPU過(guò)載從而導(dǎo)致接口無(wú)法響應(yīng)，這種情況下我們貿(mào)然的去堆硬件、加緩存而不去優(yōu)化語(yǔ)句，這無(wú)疑是飲鴆止渴，還會(huì)額外增加成本（硬件、維護(hù)）。

如果本質(zhì)問(wèn)題未得到根本解決，問(wèn)題終將再次出現(xiàn)，時(shí)間只是決定它重現(xiàn)的變量。

高并發(fā)有哪些場(chǎng)景？

從大層面來(lái)看，高并發(fā)場(chǎng)景可以分為“讀”和“寫(xiě)”兩類(lèi)。以典型的互聯(lián)網(wǎng)系統(tǒng)為例，讀寫(xiě)比例通常為 8:2，即讀多寫(xiě)少。因此，讀寫(xiě)場(chǎng)景各自具有不同的特點(diǎn)，采用的優(yōu)化方案也有所區(qū)別。

讀場(chǎng)景

在互聯(lián)網(wǎng)應(yīng)用中，系統(tǒng)通常可以看作是一個(gè)資源整合的平臺(tái)，因此讀操作占據(jù)了較大的比例。無(wú)論是數(shù)據(jù)庫(kù)還是接口，讀操作一般具有以下兩個(gè)特點(diǎn)：冪等性和負(fù)載均衡性（除非接口設(shè)計(jì)得不合理，如讀寫(xiě)混合的情況）。

冪等性指的是：

相同的參數(shù)調(diào)用同一個(gè)方法，無(wú)論執(zhí)行一次還是多次，響應(yīng)的結(jié)果都是一致的。將這一概念應(yīng)用到讀場(chǎng)景中，意味著對(duì)于相同的輸入?yún)?shù)、相同的處理邏輯，最終返回的結(jié)果始終一致。

負(fù)載均衡性

讀操作由于具備天然的冪等性，API 服務(wù)通常傾向于設(shè)計(jì)為“無(wú)狀態(tài)”。這種設(shè)計(jì)使得在面臨負(fù)載瓶頸時(shí)，可以通過(guò)增加服務(wù)副本實(shí)現(xiàn)橫向擴(kuò)展（Scale-Out），無(wú)需引入復(fù)雜的邏輯處理。此時(shí)，系統(tǒng)的關(guān)注點(diǎn)更多集中在數(shù)據(jù)庫(kù)（存儲(chǔ)系統(tǒng)）和服務(wù)器的性能及負(fù)載上。

眾所周知，關(guān)系型數(shù)據(jù)庫(kù)在處理分布式寫(xiě)（例如分庫(kù)分表）時(shí)面臨較大的挑戰(zhàn)，但在分布式讀方面具有天然優(yōu)勢(shì)。成熟的數(shù)據(jù)庫(kù)通常能夠通過(guò)簡(jiǎn)單的組件實(shí)現(xiàn)一主多從架構(gòu)，支持讀寫(xiě)分離。

無(wú)論是接口層面的服務(wù)集群，還是數(shù)據(jù)庫(kù)層面的一主多從架構(gòu)，其核心策略都在于通過(guò)【多】副本來(lái)分擔(dān)壓力，提升性能與可用性。

然而，這種場(chǎng)景通常假設(shè)數(shù)據(jù)是靜態(tài)的，不涉及復(fù)雜的計(jì)算。當(dāng)面對(duì)復(fù)雜計(jì)算的高并發(fā)場(chǎng)景時(shí)，數(shù)據(jù)庫(kù)（存儲(chǔ)系統(tǒng)）的負(fù)載壓力會(huì)更加明顯。

優(yōu)化手段

為應(yīng)對(duì)上述問(wèn)題，可以引入以下優(yōu)化手段：

1. 緩存：將熱數(shù)據(jù)存儲(chǔ)在內(nèi)存（Redis）中，減少對(duì)數(shù)據(jù)庫(kù)的直接訪問(wèn)。

2. 靜態(tài)化：將動(dòng)態(tài)生成的數(shù)據(jù)轉(zhuǎn)換為靜態(tài)（如 HTML 文件、中間表數(shù)據(jù)），在一定時(shí)間內(nèi)復(fù)用熱數(shù)據(jù)。

無(wú)論是增加服務(wù)副本，還是使用緩存和靜態(tài)化手段，其核心思想都是一致的：冗余。通過(guò)冗余數(shù)據(jù)或資源，減少系統(tǒng)在高并發(fā)場(chǎng)景下的負(fù)載壓力。

寫(xiě)場(chǎng)景

相比讀操作，寫(xiě)操作在高并發(fā)場(chǎng)景下更復(fù)雜，因其缺乏天生的數(shù)據(jù)冪等性和負(fù)載均衡。寫(xiě)操作的優(yōu)化主要圍繞數(shù)據(jù)一致性、高性能和異步處理展開(kāi)。

異步處理

異步處理在高并發(fā)的寫(xiě)場(chǎng)景中是最直接有效的，其核心思想采用【緩】的策略。隊(duì)列和調(diào)度任務(wù)在這里扮演了兩個(gè)關(guān)鍵角色：緩沖和延緩。

• 隊(duì)列：可作為數(shù)據(jù)的臨時(shí)存儲(chǔ)區(qū)域，隊(duì)列將高并發(fā)的寫(xiě)操作轉(zhuǎn)化為串行處理（或少量并行），從而起到緩沖作用，有效減輕后端系統(tǒng)的瞬時(shí)壓力。例如：數(shù)據(jù)采集
• 調(diào)度任務(wù)：通過(guò)控制處理頻率（速度和時(shí)間），調(diào)度任務(wù)將非實(shí)時(shí)性強(qiáng)的操作延遲處理，并在流量低峰期集中批量執(zhí)行，從而實(shí)現(xiàn)流量的平滑化。例如：排行榜、季度報(bào)表等

然而，異步處理并非萬(wàn)能，存在一定的場(chǎng)景局限性。并不是所有的寫(xiě)操作都適合使用隊(duì)列。例如，對(duì)于時(shí)效性要求較高的請(qǐng)求，異步處理可能無(wú)法滿(mǎn)足需求，此時(shí)需要采用一些特殊手段來(lái)彌補(bǔ)，例如輪詢(xún)查詢(xún)、WebSocket 推送等實(shí)時(shí)機(jī)制。

高性能寫(xiě)

在高性能存儲(chǔ)場(chǎng)景中，NoSQL —— Redis 是常見(jiàn)的選擇。一個(gè)典型的應(yīng)用場(chǎng)景是搶購(gòu)系統(tǒng)，其中針對(duì)高并發(fā)寫(xiě)操作的解決方案通常采用“預(yù)扣減”策略。其處理流程如下：

1. 數(shù)據(jù)同步：通過(guò)后臺(tái)服務(wù)或定時(shí)調(diào)度任務(wù)，將數(shù)據(jù)庫(kù)中的庫(kù)存數(shù)據(jù)提前同步到 Redis。
2. 庫(kù)存判斷：通過(guò) Redis 實(shí)現(xiàn)庫(kù)存的快速判斷。
3. 扣減操作：每次對(duì)熱門(mén)商品的庫(kù)存進(jìn)行扣減時(shí)，直接在 Redis 中使用 INCR -N 指令完成。

這種方法有效避免了數(shù)據(jù)庫(kù)在高并發(fā)寫(xiě)入場(chǎng)景下因鎖機(jī)制導(dǎo)致的性能瓶頸，同時(shí)充分利用 Redis 的高吞吐能力，顯著提升了系統(tǒng)的響應(yīng)效率。

限流

在互聯(lián)網(wǎng)領(lǐng)域，流量被視為至關(guān)重要的資源，因此有一句話廣為流傳：“流量為王”，因?yàn)榱髁恐苯雨P(guān)系到用戶(hù)接觸度和潛在的商業(yè)價(jià)值。

盡管流量的增加在理論上是有利的，但在資源有限的現(xiàn)實(shí)環(huán)境中，過(guò)量的流量可能會(huì)成為系統(tǒng)的負(fù)擔(dān)，甚至導(dǎo)致系統(tǒng)崩潰。

因此，為了避免系統(tǒng)因流量激增而超出承載能力，我們通常采用限流策略，其核心思想是通過(guò)“砍”的方式對(duì)流量進(jìn)行控制。限流策略可以分為技術(shù)限流和業(yè)務(wù)限流兩種方式。

技術(shù)限流

技術(shù)限流通過(guò)技術(shù)手段對(duì)訪問(wèn)流量進(jìn)行控制，確保系統(tǒng)在其負(fù)載能力范圍內(nèi)平穩(wěn)運(yùn)行。通常，這類(lèi)限流措施會(huì)在流量入口（如 API 網(wǎng)關(guān)）處實(shí)現(xiàn)。常見(jiàn)的技術(shù)限流策略包括：

• 速率限制（Rate Limiting）：限制用戶(hù)在單位時(shí)間內(nèi)的最大請(qǐng)求次數(shù)。
• 令牌桶（Token Bucket）：通過(guò)令牌分發(fā)機(jī)制控制請(qǐng)求速率，允許一定程度的突發(fā)流量。
• 漏桶（Leaky Bucket）：將請(qǐng)求以固定速率排出，平滑流量波動(dòng)。
• 熔斷器（Circuit Breaker）：在系統(tǒng)檢測(cè)到異?；蜻^(guò)載時(shí)，主動(dòng)中斷請(qǐng)求鏈路，保護(hù)系統(tǒng)免于崩潰。

業(yè)務(wù)限流

業(yè)務(wù)限流從業(yè)務(wù)層面出發(fā)，通過(guò)調(diào)整業(yè)務(wù)策略來(lái)控制流量，不僅可以減輕系統(tǒng)負(fù)擔(dān)，還能優(yōu)化用戶(hù)體驗(yàn)。常見(jiàn)的業(yè)務(wù)限流策略包括：

• 用戶(hù)分級(jí)服務(wù)：根據(jù)用戶(hù)等級(jí)或類(lèi)型實(shí)施差異化的訪問(wèn)策略，例如，VIP 用戶(hù)享有更高的請(qǐng)求優(yōu)先級(jí)或更大的訪問(wèn)額度。
• 預(yù)約機(jī)制：針對(duì)流量激增的場(chǎng)景，通過(guò)預(yù)約制度控制用戶(hù)訪問(wèn)。例如，在特定時(shí)間段內(nèi)限制服務(wù)人數(shù)，分批次提供服務(wù)。

我遇到的高并發(fā)優(yōu)化場(chǎng)景

在之前的討論中，我們探討了許多高并發(fā)場(chǎng)景的理論知識(shí)。接下來(lái)，我將分享一些實(shí)際工作中的優(yōu)化案例。

無(wú)狀態(tài)讓API服務(wù)"力大飛磚"

多年來(lái)，我司主要通過(guò) Redis 和 服務(wù)集群 來(lái)優(yōu)化系統(tǒng)性能。隨著用戶(hù)數(shù)量和日活躍度的持續(xù)增長(zhǎng)，API服務(wù)的CPU壓力逐漸增大。為應(yīng)對(duì)這一挑戰(zhàn)，我們從設(shè)計(jì)之初便采用了 無(wú)狀態(tài)服務(wù)，并引入 Nginx 實(shí)現(xiàn)負(fù)載均衡，使服務(wù)能夠根據(jù)流量需求進(jìn)行 橫向擴(kuò)展，從而實(shí)現(xiàn)集群化部署。

問(wèn)題背景

近期，由于合作方投流，平臺(tái)流量進(jìn)一步增長(zhǎng)，特別是在晚高峰時(shí)，部分API服務(wù)節(jié)點(diǎn)出現(xiàn)滿(mǎn)負(fù)載情況，而數(shù)據(jù)庫(kù)負(fù)載卻保持正常。通過(guò)監(jiān)控和代碼分析發(fā)現(xiàn)，問(wèn)題出在某些接口的實(shí)現(xiàn)上。這些接口每次讀取大量數(shù)據(jù)，并通過(guò) Foreach 進(jìn)行逐條查詢(xún)和計(jì)算。由于查詢(xún)是基于主鍵的，數(shù)據(jù)庫(kù)壓力不大，但數(shù)據(jù)量過(guò)大直接導(dǎo)致單次請(qǐng)求執(zhí)行時(shí)間過(guò)長(zhǎng)。當(dāng)晚高峰多名用戶(hù)并發(fā)請(qǐng)求時(shí)，這些接口瞬間占滿(mǎn)API服務(wù)的工作線程，導(dǎo)致 CPU負(fù)載飆升。

臨時(shí)應(yīng)對(duì)

為應(yīng)對(duì)流量高峰，我們通過(guò) API橫向擴(kuò)容 的方式，臨時(shí)增加了多臺(tái)節(jié)點(diǎn)機(jī)，緩解了服務(wù)壓力，確保平臺(tái)能夠穩(wěn)定運(yùn)行，抓住這波流量。

緩存很有用，但姿勢(shì)要對(duì)

為了優(yōu)化性能，我們幾乎對(duì)所有核心業(yè)務(wù)（如首頁(yè)數(shù)據(jù)、推薦位、排行榜、作品內(nèi)容等）都采用了 緩存策略。

這種方法在過(guò)去幾年中效果顯著：只要出現(xiàn)性能瓶頸，引入緩存幾乎總能解決問(wèn)題。尤其是首頁(yè)業(yè)務(wù)，這類(lèi)數(shù)據(jù)通常是每隔數(shù)小時(shí)更新一次的偽靜態(tài)數(shù)據(jù)，使用緩存完全合理。

然而，這也引出了一個(gè)值得思考的問(wèn)題：緩存是否能解決所有性能問(wèn)題？

緩存雖然能夠顯著提升數(shù)據(jù)讀取性能，但對(duì)于復(fù)雜計(jì)算、接口設(shè)計(jì)缺陷以及高并發(fā)場(chǎng)景下的線程占用問(wèn)題，緩存并非萬(wàn)能。我們需要結(jié)合具體場(chǎng)景，從代碼優(yōu)化、接口設(shè)計(jì)、數(shù)據(jù)庫(kù)查詢(xún)效率等多方面入手，才能真正解決性能瓶頸。

在一年的最后一天，我們發(fā)現(xiàn)了一個(gè)嚴(yán)重問(wèn)題。12月31日午夜12點(diǎn)，咱們數(shù)據(jù)庫(kù)的CPU使用率突然從20%激增至100%。通過(guò)檢查接口日志和數(shù)據(jù)庫(kù)阻塞日志，問(wèn)題鎖定在一條長(zhǎng)期使用的排行榜SQL語(yǔ)句。按理說(shuō)，這部分?jǐn)?shù)據(jù)應(yīng)有緩存，為何系統(tǒng)會(huì)崩潰？經(jīng)過(guò)代碼審查，問(wèn)題如下：

問(wèn)題分析

偽代碼如下：

// 緩存策略模式 - cache-aside
var redisKey = "rankinglist:" + DateTime.Now.ToString("yyyyMMdd");
var rankingListCache = redis.Get(redisKey); // 從緩存獲取數(shù)據(jù)
if (rankingListCache != null)
    return rankingListCache;
var data = db.RankingList.GetList(); // 從數(shù)據(jù)庫(kù)獲取數(shù)據(jù)，復(fù)雜查詢(xún)
if (data.Any())
{
    redis.Set(redisKey, data, 3600); // 寫(xiě)入緩存
    return data;
}
return new List();

1. 緩存鍵設(shè)計(jì)問(wèn)題

緩存鍵基于 DateTime.Now.ToString("yyyyMMdd") 生成，導(dǎo)致跨年、跨月、跨日時(shí)，年度榜、月榜、周榜在午夜12點(diǎn)立即失效，觸發(fā)所有請(qǐng)求直接訪問(wèn)數(shù)據(jù)庫(kù)。

2. 緩存穿透問(wèn)題

僅當(dāng) data.Any()`為真時(shí)才會(huì)更新緩存。如果數(shù)據(jù)庫(kù)查詢(xún)結(jié)果為空，則不會(huì)寫(xiě)入緩存，導(dǎo)致每次請(qǐng)求都直接訪問(wèn)數(shù)據(jù)庫(kù)。

臨時(shí)優(yōu)化

針對(duì)上述問(wèn)題，我們進(jìn)行了以下優(yōu)化：

var redisKey = "rankinglist:" + type; // 改為基于榜單類(lèi)型的緩存鍵
var rankingListCache = redis.Get(redisKey); // 從緩存獲取數(shù)據(jù)
if (rankingListCache != null)
    return rankingListCache;
var data = db.RankingList.GetList(); // 從數(shù)據(jù)庫(kù)獲取數(shù)據(jù)
if (data.Any())
{
    redis.Set(redisKey, data, 3600); // 緩存有效數(shù)據(jù)
    return data;
}
else
{
    redis.Set(redisKey, new List(), 60); // 緩存空數(shù)據(jù)1分鐘
    return new List();
}

1. 緩存鍵設(shè)計(jì)優(yōu)化

   去掉基于日期的緩存鍵，改為按榜單類(lèi)型（如年度榜、月榜、周榜）生成緩存鍵，避免因日期變更導(dǎo)致緩存大規(guī)模失效。

2. 緩存穿透防護(hù)

   即使數(shù)據(jù)庫(kù)查詢(xún)結(jié)果為空，也緩存空數(shù)據(jù)（有效期1分鐘），避免頻繁查詢(xún)數(shù)據(jù)庫(kù)。

通過(guò)以上優(yōu)化，臨時(shí)解決了Redis引發(fā)的緩存穿透和緩存雪崩問(wèn)題。

長(zhǎng)期優(yōu)化

從數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)角度，我們進(jìn)一步采取了 主從分離策略，將首頁(yè)只讀業(yè)務(wù)和復(fù)雜查詢(xún)遷移至從庫(kù)。遷移后，通過(guò) Zabbix 監(jiān)控發(fā)現(xiàn)，主庫(kù)CPU負(fù)載高峰現(xiàn)象徹底解決，主庫(kù)負(fù)載降低了50%，主從庫(kù)運(yùn)行穩(wěn)定，性能大幅提升。

異步與靜態(tài)化

一個(gè)工作日的早晨，系統(tǒng)再次報(bào)警，部分用戶(hù)反饋無(wú)法訪問(wèn)平臺(tái)功能。問(wèn)題持續(xù)約 20 分鐘后逐漸恢復(fù)。通過(guò)日志和監(jiān)控分析發(fā)現(xiàn)，問(wèn)題源于從庫(kù) CPU 負(fù)載達(dá)到 100%，由類(lèi)報(bào)表功能的復(fù)雜查詢(xún)引發(fā)。

前一天啟動(dòng)的活動(dòng)吸引了大量用戶(hù)次日參與，但部分緩存失效導(dǎo)致相關(guān)功能查詢(xún)直接落庫(kù)。由于查詢(xún)語(yǔ)句執(zhí)行時(shí)間較長(zhǎng)（5-10 秒），結(jié)果無(wú)法及時(shí)寫(xiě)入 Redis，后續(xù)用戶(hù)的請(qǐng)求均直接查詢(xún)數(shù)據(jù)庫(kù)，導(dǎo)致 CPU 瞬間飆升至 100%。這種現(xiàn)象稱(chēng)為緩存擊穿。高并發(fā)下的查詢(xún)超時(shí)進(jìn)一步加劇了無(wú)法緩存的情況，形成惡性循環(huán)。

得益于主從分離策略，本次僅部分功能受影響，但復(fù)雜查詢(xún)?cè)诟卟l(fā)場(chǎng)景下對(duì)數(shù)據(jù)庫(kù)負(fù)載的壓力較大，亟需優(yōu)化。

考慮到相關(guān)數(shù)據(jù)短時(shí)間內(nèi)不會(huì)變化，我們對(duì)架構(gòu)進(jìn)行了調(diào)整：

1. 靜態(tài)化數(shù)據(jù)處理：將實(shí)時(shí) SQL 查詢(xún)改為通過(guò)調(diào)度任務(wù)定時(shí)執(zhí)行，將查詢(xún)結(jié)果壓縮后存儲(chǔ)至中間表。
2. 接口調(diào)整：修改接口邏輯，直接從中間表讀取數(shù)據(jù)。

這種策略有效降低了數(shù)據(jù)庫(kù)對(duì)復(fù)雜查詢(xún)的計(jì)算壓力，同時(shí)顯著提高了接口的并發(fā)處理能力。

復(fù)雜 SQL 在高并發(fā)場(chǎng)景下對(duì)數(shù)據(jù)庫(kù)影響較大，尤其配置不足時(shí)更易成為瓶頸。通過(guò)靜態(tài)化處理和中間表設(shè)計(jì)，既緩解了數(shù)據(jù)庫(kù)壓力，又優(yōu)化了用戶(hù)體驗(yàn)。

限制不住，就扛下來(lái)

俗話說(shuō)：“人怕出名，豬怕壯”隨著平臺(tái)不斷發(fā)展壯大，關(guān)注度提高的同時(shí)，挑戰(zhàn)也隨之而來(lái)，如盜版和競(jìng)爭(zhēng)對(duì)手使用爬蟲(chóng)抓取數(shù)據(jù)。這些爬蟲(chóng)不僅可能將商業(yè)數(shù)據(jù)發(fā)布到免費(fèi)網(wǎng)站，損害平臺(tái)利益，還會(huì)通過(guò)頻繁請(qǐng)求導(dǎo)致系統(tǒng)壓力激增。

雖然“流量為王”，但惡意爬蟲(chóng)的流量對(duì)平臺(tái)毫無(wú)價(jià)值。為此，我們迅速在網(wǎng)關(guān)層面實(shí)施限流策略，從 IP、Cookies、UA 等多個(gè)維度限制密集請(qǐng)求，有效應(yīng)對(duì)了基礎(chǔ)、粗暴的爬蟲(chóng)攻擊。

然而，某日搜索庫(kù)服務(wù)器 CPU 使用率驟然飆升。分析后發(fā)現(xiàn)，黑客通過(guò)模擬客戶(hù)端身份并以分布式方式繞過(guò)限流策略發(fā)起攻擊。為長(zhǎng)期防御此類(lèi)問(wèn)題，我們需要從前后端入手，增加校驗(yàn)規(guī)則、更換密鑰、加強(qiáng)客戶(hù)端防護(hù)等多方面提升系統(tǒng)安全性。

但我們也深知，沒(méi)有絕對(duì)完美的安全策略，后端服務(wù)必須具備一定的抗壓能力。

非常遺憾的是，我們用Like做搜索作為技術(shù)債務(wù)保留了下來(lái)，也是這次事故的兇手，為解決這一問(wèn)題，我們引入了 ElasticSearch，通過(guò)定時(shí)任務(wù)定期同步搜索庫(kù)數(shù)據(jù)至 ElasticSearch，并調(diào)整接口邏輯指向 ElasticSearch。這一優(yōu)化顯著提升了搜索性能，使系統(tǒng)在高并發(fā)場(chǎng)景下更穩(wěn)定，也更從容地應(yīng)對(duì)爬蟲(chóng)流量攻擊。

怎么應(yīng)對(duì)火熱搶購(gòu)？

雖然我們公司主營(yíng)文娛類(lèi)業(yè)務(wù)，但任何形式的優(yōu)惠或免費(fèi)活動(dòng)都能吸引大量用戶(hù)，類(lèi)似電商平臺(tái)的搶購(gòu)活動(dòng)。

以平臺(tái)推出的福利商城為例，用戶(hù)通過(guò)完成任務(wù)或參與活動(dòng)獲得虛擬幣，用于兌換“代券”免費(fèi)觀看作品。代券每天限量，每晚12點(diǎn)系統(tǒng)自動(dòng)刷新庫(kù)存，開(kāi)啟新一輪兌換。

在一次五一活動(dòng)中，我們吸引了大量用戶(hù)參與。然而活動(dòng)結(jié)束后的第二天凌晨，主庫(kù) CPU 負(fù)載突然飆升至 100%，持續(xù)約 15 分鐘。經(jīng)過(guò)分析發(fā)現(xiàn)，問(wèn)題出在用戶(hù)集中搶兌代券時(shí)，SQL 執(zhí)行遇到高并發(fā)鎖競(jìng)爭(zhēng)。盡管庫(kù)存扣減的 SQL 語(yǔ)句很簡(jiǎn)單：

UPDATE TableA SET Stock = Stock - 1 WHERE Stock > 0;

問(wèn)題的根源在于并發(fā)環(huán)境下共享數(shù)據(jù)產(chǎn)生的鎖競(jìng)爭(zhēng)。

鎖競(jìng)爭(zhēng)的高負(fù)載原因：

1.自旋鎖的忙等：

自旋鎖在鎖被占用時(shí)，線程會(huì)不斷循環(huán)嘗試獲取鎖而不掛起，導(dǎo)致CPU持續(xù)執(zhí)行無(wú)效操作，顯著增加CPU負(fù)載。

2.頻繁的上下文切換：

高并發(fā)下，線程競(jìng)爭(zhēng)鎖未果時(shí)會(huì)被掛起并進(jìn)入等待隊(duì)列，鎖釋放后再被喚醒。頻繁的掛起和喚醒引發(fā)大量上下文切換，消耗CPU資源，提升負(fù)載。

3.死鎖檢測(cè)的開(kāi)銷(xiāo)：

在高并發(fā)場(chǎng)景中，數(shù)據(jù)庫(kù)或操作系統(tǒng)需要掃描等待圖或事務(wù)依賴(lài)關(guān)系以檢測(cè)死鎖，這種復(fù)雜計(jì)算會(huì)顯著增加CPU負(fù)擔(dān)。

為解決這一問(wèn)題，我提出了兩種優(yōu)化方案：

1. 調(diào)整庫(kù)存刷新時(shí)間
   建議將庫(kù)存刷新時(shí)間改為凌晨 4-5 點(diǎn)的低峰期，避開(kāi)用戶(hù)集中“蹲點(diǎn)”兌換的高峰時(shí)段。這是成本最低的解決方案，但團(tuán)隊(duì)認(rèn)為用戶(hù)已習(xí)慣現(xiàn)有模式，調(diào)整可能影響用戶(hù)體驗(yàn)。
2. 預(yù)扣庫(kù)存方案
   針對(duì)高并發(fā)問(wèn)題，設(shè)計(jì)了基于 Redis 的預(yù)扣庫(kù)存機(jī)制：
1. 庫(kù)存同步至 Redis：后臺(tái)對(duì)熱門(mén)商品新增或編輯時(shí)，將庫(kù)存同步到 Redis。
2. Redis 扣減邏輯：客戶(hù)端請(qǐng)求兌換時(shí)，系統(tǒng)先檢查 Redis 中的庫(kù)存，若庫(kù)存量大于 0，使用 INCR 命令扣減庫(kù)存。只有扣減成功，才生成兌換記錄。
3. 庫(kù)存回寫(xiě)數(shù)據(jù)庫(kù)：當(dāng) Redis 庫(kù)存扣減至 0 時(shí)，將庫(kù)存同步回?cái)?shù)據(jù)庫(kù)，并更新庫(kù)存狀態(tài)供客戶(hù)端展示。

通過(guò) Redis 的高性能讀取和寫(xiě)入操作，避免了數(shù)據(jù)庫(kù)的鎖競(jìng)爭(zhēng)問(wèn)題，同時(shí)顯著降低了 CPU 負(fù)載。

搶購(gòu)可以使用隊(duì)列處理么？

針對(duì)“搶購(gòu)”類(lèi)業(yè)務(wù)場(chǎng)景，可以考慮引入隊(duì)列機(jī)制來(lái)緩解熱點(diǎn)數(shù)據(jù)更新導(dǎo)致的高負(fù)載問(wèn)題。隊(duì)列的先進(jìn)先出（FIFO）特性和串行處理機(jī)制能夠有效降低數(shù)據(jù)庫(kù)壓力，避免高并發(fā)寫(xiě)入引發(fā)的性能瓶頸。然而，隊(duì)列的引入往往意味著異步處理用戶(hù)請(qǐng)求，這對(duì)需要即時(shí)反饋的場(chǎng)景帶來(lái)了新的挑戰(zhàn)。

例如，類(lèi)似【智行火車(chē)票】APP的排隊(duì)下單系統(tǒng)（盡管未明確其是否使用隊(duì)列），其邏輯與隊(duì)列機(jī)制非常相似：

1. 用戶(hù)下單后進(jìn)入排隊(duì)頁(yè)面（中間頁(yè)），頁(yè)面通過(guò)定時(shí)刷新更新訂單狀態(tài)。
2. 處理完成后，頁(yè)面展示支付按鈕供用戶(hù)操作。
3. 支付完成但尚未出票時(shí)，用戶(hù)會(huì)跳轉(zhuǎn)到訂單詳情頁(yè)，出票后則以通知形式告知用戶(hù)。

再舉個(gè)例子，以上面說(shuō)的福利商城的“搶購(gòu)”業(yè)務(wù)為例：

1. 用戶(hù)點(diǎn)擊【兌換】按鈕后，系統(tǒng)將請(qǐng)求放入隊(duì)列中，隊(duì)列逐步消費(fèi)這些請(qǐng)求。用戶(hù)此時(shí)會(huì)進(jìn)入一個(gè)中間等待頁(yè)面，等待兌換結(jié)果。
2. 由于并發(fā)情況下庫(kù)存數(shù)據(jù)未能實(shí)時(shí)同步扣減，最終兌換結(jié)果可能失敗。
3. 對(duì)于結(jié)果通知的方式，可以選擇通過(guò) WebSocket 實(shí)時(shí)推送，也可以在中間頁(yè)由客戶(hù)端輪詢(xún)獲取結(jié)果。

然而，這種改造方式需要前后端協(xié)同配合，且需要調(diào)整用戶(hù)交互邏輯，改造成本相對(duì)較高。

針對(duì)“搶購(gòu)”類(lèi)業(yè)務(wù)場(chǎng)景，優(yōu)化方案有多種選擇。具體方案應(yīng)根據(jù)系統(tǒng)的實(shí)際體量和業(yè)務(wù)需求，選擇最優(yōu)的處理方式。

隊(duì)列適用場(chǎng)景分析

在我們的平臺(tái)上，隊(duì)列適用于以下寫(xiě)入場(chǎng)景：

1. 客戶(hù)端行為日志采集
   用戶(hù)操作頻繁、請(qǐng)求量大，但對(duì)響應(yīng)時(shí)間要求不高。日志采集主要用于生成報(bào)告供內(nèi)部分析，因此無(wú)需實(shí)時(shí)寫(xiě)入數(shù)據(jù)庫(kù)。通過(guò)隊(duì)列異步處理，可有效緩解高并發(fā)寫(xiě)入壓力。
2. 個(gè)推數(shù)據(jù)處理
   個(gè)推數(shù)據(jù)雖需基于用戶(hù)行為進(jìn)行實(shí)時(shí)推薦，但本質(zhì)上是偽實(shí)時(shí)場(chǎng)景。推薦算法的響應(yīng)時(shí)間通常在 0.01 秒到 3 秒之間波動(dòng)，當(dāng)無(wú)法即時(shí)生成推薦結(jié)果時(shí)，可使用公共推薦庫(kù)作為替代。隊(duì)列能夠?qū)⑼扑]計(jì)算轉(zhuǎn)移至后臺(tái)，分散系統(tǒng)壓力，提升整體性能。
3. 公共數(shù)據(jù)統(tǒng)計(jì)
   用戶(hù)觀看廣告后，平臺(tái)會(huì)贈(zèng)送代金券，同時(shí)廣告的總觀看次數(shù)需要更新。在晚高峰時(shí)，大量用戶(hù)集中操作會(huì)對(duì)廣告數(shù)據(jù)表造成寫(xiě)入壓力，甚至引發(fā)鎖競(jìng)爭(zhēng)或死鎖問(wèn)題。為優(yōu)化性能，可將“廣告觀看次數(shù) +1”的操作通過(guò)消息隊(duì)列（MQ）異步處理。用戶(hù)領(lǐng)取獎(jiǎng)勵(lì)后，系統(tǒng)將更新請(qǐng)求寫(xiě)入隊(duì)列，由后臺(tái)異步更新數(shù)據(jù)庫(kù)，避免高并發(fā)直接寫(xiě)入。

高并發(fā)不是終點(diǎn)

高并發(fā)不是終點(diǎn)，而是一場(chǎng)持續(xù)的“攻防戰(zhàn)”。優(yōu)化高并發(fā)系統(tǒng)需要從技術(shù)與業(yè)務(wù)雙重角度出發(fā)，既要平衡用戶(hù)體驗(yàn)、系統(tǒng)性能與資源成本，又要根據(jù)具體場(chǎng)景靈活應(yīng)用各種策略。無(wú)論是三字真言“砍、緩、多”，還是七大處理手段，都沒(méi)有絕對(duì)的萬(wàn)能解法——正如軟件工程的經(jīng)典原則所言：【沒(méi)有銀彈】。真正的高并發(fā)優(yōu)化核心，不僅在于提升系統(tǒng)性能與穩(wěn)定性，更在于如何在有限的資源條件下，以最優(yōu)成本滿(mǎn)足業(yè)務(wù)需求。

高并發(fā)不是終點(diǎn)，而是開(kāi)發(fā)者不斷突破技術(shù)邊界的新起點(diǎn)。希望本文的經(jīng)驗(yàn)與總結(jié)，能夠?yàn)槟銘?yīng)對(duì)高并發(fā)場(chǎng)景提供啟發(fā)與幫助。