我有話想說

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

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

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

前言

在互聯(lián)網(wǎng)時(shí)代，高并發(fā)已經(jīng)成為后端開發(fā)者繞不開的話題。無論是電商平臺(tái)的秒殺活動(dòng)、搶購系統(tǒng)，還是社交應(yīng)用的高頻互動(dòng)，高并發(fā)場景的出現(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ā)場景的實(shí)際問題。因此，在這篇文章中，我將結(jié)合理論與實(shí)踐，深入剖析高并發(fā)的本質(zhì)、應(yīng)對(duì)策略，以及實(shí)際案例，希望能夠?yàn)槟憬议_高并發(fā)背后的技術(shù)奧秘。

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

什么是高并發(fā)？

百度百科：

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

簡單的說，高并發(fā)是指系統(tǒng)在同一時(shí)間內(nèi)接受到大量的客戶端請(qǐng)求訪問，需要系統(tǒng)（服務(wù)端）能夠快速響應(yīng)并處理請(qǐng)求的能力。在咱們互聯(lián)網(wǎng)應(yīng)用中，例如電商、游戲等在做活動(dòng)或者促銷的時(shí)候，這些熱點(diǎn)業(yè)務(wù)就非常大可能同時(shí)被大量用戶訪問，并造成系統(tǒng)較大的負(fù)載。高并發(fā)一般伴隨著數(shù)據(jù)增長、流量增加，這種現(xiàn)象可能是短時(shí)間的內(nèi)的峰值，也可能是持續(xù)不斷負(fù)載壓力，因此需要開發(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)求，并且看起來好像這些任務(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)歷的同行肯定想，沒個(gè)幾十萬、上百萬的QPS都不叫高并發(fā)吧？
• 萌新可能認(rèn)為，我平常系統(tǒng)峰值最高就兩三千的 QPS，那么起碼也得高一個(gè)量級(jí)才算吧？

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

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

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

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

因此，在討論高并發(fā)時(shí)，我們不必將其想象為極端數(shù)量級(jí)的并發(fā)情況。關(guān)鍵在于理解特定業(yè)務(wù)場景下，在何種條件（包括人力、技術(shù)力、計(jì)算力）下，為了達(dá)到既定目標(biāo)（如穩(wěn)定性、安全性、用戶體驗(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次查詢（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í)間較長，其響應(yīng)速度和整體性能可能仍不理想。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

讀場景

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

冪等性指的是：

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

負(fù)載均衡性

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

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

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

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

優(yōu)化手段

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

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

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

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

寫場景

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

異步處理

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

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

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

高性能寫

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

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

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

限流

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

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

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

技術(shù)限流

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

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

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

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

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

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

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

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

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

問題背景

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

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

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

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

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

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

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

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

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

問題分析

偽代碼如下：

// 緩存策略模式 - 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ù)庫獲取數(shù)據(jù)，復(fù)雜查詢
if (data.Any())
{
    redis.Set(redisKey, data, 3600); // 寫入緩存
    return data;
}
return new List();

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

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

2. 緩存穿透問題

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

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

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

var redisKey = "rankinglist:" + type; // 改為基于榜單類型的緩存鍵
var rankingListCache = redis.Get(redisKey); // 從緩存獲取數(shù)據(jù)
if (rankingListCache != null)
    return rankingListCache;
var data = db.RankingList.GetList(); // 從數(shù)據(jù)庫獲取數(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)化

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

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

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

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

長期優(yōu)化

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

異步與靜態(tài)化

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

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

得益于主從分離策略，本次僅部分功能受影響，但復(fù)雜查詢?cè)诟卟l(fā)場景下對(duì)數(shù)據(jù)庫負(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 查詢改為通過調(diào)度任務(wù)定時(shí)執(zhí)行，將查詢結(jié)果壓縮后存儲(chǔ)至中間表。
2. 接口調(diào)整：修改接口邏輯，直接從中間表讀取數(shù)據(jù)。

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

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

限制不住，就扛下來

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

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

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

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

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

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

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

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

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

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

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

鎖競爭的高負(fù)載原因：

1.自旋鎖的忙等：

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

2.頻繁的上下文切換：

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

3.死鎖檢測的開銷：

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

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

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

通過 Redis 的高性能讀取和寫入操作，避免了數(shù)據(jù)庫的鎖競爭問題，同時(shí)顯著降低了 CPU 負(fù)載。

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

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

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

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

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

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

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

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

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

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

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

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

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

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