阿里面試：10Wqps高并發，具體 的 “限流閾值” 怎么 計算 ？

本文 的 原文 地址

原始的內容，請參考 本文 的 原文 地址

本文 的 原文 地址

尼恩說在前面

在40歲老架構師 尼恩的讀者交流群(50+)中，最近有小伙伴拿到了一線互聯網企業如阿里、滴滴、極兔、有贊、希音、百度、網易、美團的面試資格，遇到很多很重要的面試題：

10wqps 限流 閾值，是怎么計算出來的？

你們項目中，怎么限流的？

前段時間小伙伴面試阿里，遇到這個問題。 小伙伴沒有準備好， 面試掛了。

問題說明：

限流這項技術，看似簡單，實則涉及到算法理論選擇與復雜工程落地之間的大量細節與權衡。

記住，當被問及限流時，千萬別只停留在背誦算法層面。

45歲老架構師 尼恩提示：

要主動把話題引向閾值的科學計算方法論，向面試官展示你如何結合流量預估、壓力測試、 監控數據、 自適應動態調整等多種手段，來解決一個現實的復雜工程難題。

這正是展現你技術深度、讓你與眾不同的關鍵所在。

限流：是大廠面試、高P面試的核心面試題

注：本文以 PDF 持續更新，最新尼恩 架構筆記、面試題 的PDF文件，請到文末《技術自由圈》公號獲取

為什么要限流

簡單來說：

限流在很多場景中用來限制并發和請求量，比如說秒殺搶購，保護自身系統和下游系統不被巨型流量沖垮等。

以微博為例，例如某某明星公布了戀情，訪問從平時的50萬增加到了500萬，系統的規劃能力，最多可以支撐200萬訪問，那么就要執行限流規則，保證是一個可用的狀態，不至于服務器崩潰，所有請求不可用。

限流的思想

在保證可用的情況下盡可能多增加進入的人數，其余的人在排隊等待，或者返回友好提示，保證里面的進行系統的用戶可以正常使用，防止系統雪崩。

日常生活中，有哪些需要限流的地方?

像我旁邊有一個國家景區，平時可能根本沒什么人前往，但是一到五一或者春節就人滿為患，這時候景區管理人員就會實行一系列的政策來限制進入人流量，

為什么要限流呢?

假如景區能容納一萬人，現在進去了三萬人，勢必摩肩接踵，整不好還會有事故發生，這樣的結果就是所有人的體驗都不好，如果發生了事故景區可能還要關閉，導致對外不可用，這樣的后果就是所有人都覺得體驗糟糕透了。

一、限流的核心三要素

在探討“閾值計算”之前，必須確保基礎知識足夠扎實。一切高階的優化都源于對底層原理的深刻理解。限流的知識體系可以歸納為三個核心要素：

(1) 限流算法：用什么方法來限制流量？

(2) 限流對象：限制誰的流量？限制哪個維度的流量？

(3) 限流后的應對策略：被擋住的請求該怎么辦？

簡而言之，限流就是通過主動控制進入系統的流量規模，來保護后端服務不被壓垮。它尤其擅長應對那些意料之外的流量洪峰。無論是來自外部的惡意攻擊，還是內部因異常（如緩存大面積失效）引發的流量激增，限流都是守護系統穩定運行的第一道也是極為重要的防線。

1、核心限流算法

主流的限流算法主要有四種：計數器算法、滑動窗口算法、漏桶算法、令牌桶算法。具體細節會在文章末尾詳細說明。

(1) 計數器算法 (固定窗口)

• 原理： 在一個固定的時間窗口內，記錄請求數量。當請求數超過預設閾值時，后續請求在該窗口剩余時間內會被限流。
• 特點：實現簡單。但存在窗口邊界突發流量問題（窗口開始時涌入大量請求）。

(2) 滑動窗口算法

• 原理： 將時間線劃分為更細粒度的子窗口。隨時間推移，窗口向前滑動。統計當前滑動窗口覆蓋的所有子窗口內的請求總和，如果超過閾值則限流。
• 特點： 對固定窗口算法的改進，能更平滑地處理流量，減少邊界突刺效應。

(3) 漏桶算法

• 原理： 想象一個固定容量的桶，底部有個漏水口以恒定速率漏水（處理請求）。請求到達時像水滴一樣進入桶中。如果桶滿了（超過容量），多余的請求就會溢出被丟棄。
• 特點： 強制以恒定的平均速率處理請求，無論流量多么突發（平滑輸出），突發流量會被丟棄或等待。

(4) 令牌桶算法

• 原理： 想象一個固定容量的桶，系統以恒定速率往桶里放入令牌。請求到達時，需要從桶中拿走一個令牌才能被處理。如果桶中沒有令牌，則請求被限流。令牌桶允許一定量的突發流量（桶里積攢的令牌用完之前）。
• 特點： 既能限制平均速率，又能允許短時間內的突發流量（取決于桶容量），對臨時流量高峰更友好。

2、限流對象

選定了算法，接下來需要清晰地定義限流的作用對象是誰。

從部署維度看

1）單機限流： 限流邏輯僅在單個服務實例內部生效。

• 優點： 實現簡單、無外部依賴、性能開銷低。
• 局限： 無法對整個集群的總流量進行精確控制（每個節點獨立計數）。

2）集群限流： 需要一個中心化的組件來統計整個集群的流量信息。

• 常見實現： Redis（利用其高性能的原子操作，如 INCR/Lua 腳本）。
• 網關集成： 如果限流邏輯部署在 網關層（如 Nginx, Spring Cloud Gateway, Kong, Envoy），網關節點本身就可以充當這個“中心節點”，避免了對外部存儲（如 Redis）的額外依賴。

從業務維度看

• 按用戶身份 (User)： 例如，對 VIP 用戶不限流或放寬限制，對普通用戶的訪問頻率進行嚴格控制。常用于差異化服務。
• 按 IP 地址 (IP)： 經典的防 DDoS 和反爬蟲手段。例如，對登錄、注冊、秒殺等關鍵接口，限制單個 IP 單位時間內的請求次數。通常設置一個合理的上限（如 50 次/秒），能有效過濾掉自動化程序產生的海量請求，同時不影響真實用戶（即便是共享出口 IP）。
• 按業務 ID (Resource)： 例如，針對特定的 userId、productId、orderId 或某個 API 路徑進行限流。防止單個用戶濫用、針對特定商品資源請求過多或熱點 API 被刷爆，確保資源的公平使用和系統穩定性。

3、限流后的應對策略

當一個請求被判斷需要限流時，我們并非只能簡單地返回一個錯誤。

設計恰當的處理策略，同樣能體現系統的健壯性和用戶體驗優化。

1）直接拒絕/友好提示：

最常用、最簡單的策略 是 直接拒絕/友好提示。

直接向客戶端返回一個預設的錯誤碼（如 HTTP 429 Too Many Requests）, 或返回一個 包含友好提示信息的錯誤響應（如“操作過于頻繁，請稍后再試”）。

2）同步阻塞等待：

適用于超出閾值不多的情況（例如，限流 100 QPS，來了 101 個請求）。

讓超出的這個請求等待極短時間（如幾十毫秒），以獲取下一時間窗口/新令牌的機會。

關鍵點： 必須設置嚴格的超時時間！

避免無限期阻塞耗盡服務器線程資源，導致雪崩。

3）同步轉異步（削峰填谷）：

對于被限流的請求，將其處理邏輯轉變為異步。

立即告知用戶“請求已接受，正在排隊處理”（如返回 HTTP 202 Accepted）。

將該請求信息放入消息隊列（如 RabbitMQ, Kafka）持久化。

在系統負載較低時，由后臺消費者從隊列中拉取任務進行處理。這與服務降級中的“異步處理”理念一致。

4）聯動負載均衡：

當某個服務節點頻繁觸發限流，表明該節點可能已負載過高或存在性能問題。

可以將此信號（如通過健康檢查接口、指標上報）反饋給上游的負載均衡器（如 Nginx Upstream, Service Mesh）。

負載均衡器可以據此動態降低該節點的權重，減少后續分配到此節點的流量。

• 注意： 這不是熔斷（熔斷是徹底切斷流量），這是更柔和的、保護性的降級（Degradation）。

二、限流閾值 怎么算？

鋪墊了足夠的基礎知識，現在讓我們直擊核心：當面試官問你“限流閾值怎么定”時，他想考察什么？

他想聽到的，絕不應該是“憑感覺”、“拍腦袋”或者“領導定的數”。

他真正期待的是你是否掌握了一套科學、系統的方法來解決這個至關重要的工程問題。

實踐中，確定閾值主要有四種思路，其準確性和科學性通常依次遞減：壓力測試、觀測監控、參考借鑒、手動估算。

1、單體服務 估算

首先是 單體服務的預估。 手動估算 核心服務 核心路徑的關鍵步驟及平均耗時。

例如一次請求可能包含：

• 1 次 RPC 調用： ~20ms
• 2 次 Redis Get： 每次 ~1ms (2ms)
• 1 次帶索引的 DB 查詢（可能回表）： ~10ms
• 業務邏輯處理 + 序列化/反序列化： ~8ms
• 單次請求總計： ~40ms

據此估算單機理論處理能力：

• 單核 1秒 (1000ms) 處理請求數： 1000ms / 40ms = 25 個請求
• 4核機器理論 QPS： 25 * 4 = 100 QPS

// 簡化的理論容量估算公式 (忽略很多現實因素)

(1000ms / 預估單請求耗時ms) * CPU核心數 = 理論QPS上限

務必強調此方法的嚴重不足：

• 估算模型非常粗糙！忽略了 JVM GC、IO 阻塞、鎖競爭、上下文切換、網絡抖動等大量現實開銷。
• 計算結果必須再乘以一個比較大的折扣系數（如 50% - 60%），得出一個非常保守的初始閾值（如 100 * 60% = 60 QPS）。

這只能是臨時閾值計算方案，后期必須盡快通過壓測或監控數據進行校準！

2、全鏈路 吞吐量 評估

比較關鍵的關鍵的問題來了：

假設你的項目的用戶量有百萬級，然后每天有幾千萬請求，高峰期每秒有好幾千請求。

全鏈路 會有多高的QPS？

按二八定律來看，如果每天 80% 的訪問集中在 20% 的時間里，這 20% 時間就叫做峰值時間。

• 公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS)
• 機器：峰值時間每秒QPS / 單臺機器的QPS = 需要的機器

1、每天300w PV ，全鏈路 吞吐量 評估 是 多少QPS？

( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

2、如果一臺機器的QPS是60 ，需要幾臺機器來支持？

139 / 60 = 3

3、壓力測試（黃金標準）

這是確定服務容量和限流閾值的最可靠方法，是嚴謹工程實踐的體現。

面試時，可以這樣闡述：

科學確定限流閾值的核心方法是壓力測試，目標是找到服務的‘性能拐點’。

首選方式是全鏈路壓測，因為它最接近線上真實復雜的調用鏈路和資源競爭情況，結果最具參考價值。

若條件有限，至少要在預發布環境或與線上配置一致的獨立環境里，對目標服務進行單節點壓測。

緊接著，需要清晰解釋如何分析壓測結果。

建議描述（或手繪/腦補）下方這個經典的性能曲線圖：

“壓測時，我們逐步增加施壓的 QPS（橫軸），同時密切關注三個關鍵指標（縱軸）：響應時間 (Latency)、吞吐量 (Throughput)、資源利用率 (CPU/Memory)。

通常會得到類似上圖的關聯曲線。”

“從曲線中，我們能識別出幾個關鍵點位：”

• A 點（最佳性能點）：在此點之前，響應時間基本穩定或略微上升，系統資源利用率健康。此時請求能被高效處理，用戶體驗最佳。
• C 點（最大吞吐點）：此時系統達到它能處理的絕對峰值請求量 (Throughput Max)。超過此點，由于資源爭搶加劇（如線程、鎖、連接池），吞吐量不增反降。
• B 點（崩潰臨界點）：響應時間急劇飆升，系統資源趨于耗盡（如 CPU 100%），極不穩定，隨時可能徹底宕機。

那么，限流閾值設在哪一點？

這需要根據業務目標做權衡：

• 追求極致用戶體驗（低延遲）： 應選 A 點附近的 QPS 值作為閾值（較保守）。犧牲部分吞吐量，確保每個請求都能快速響應。
• 追求最大吞吐量（如后臺批處理）： 可選 C 點對應的 QPS（較激進）。此時延遲可能較高，但系統處理能力達到極限。
• 大多數常規在線服務： 常在 A 點和 C 點之間選擇平衡點。最常用的是以 C 點 QPS 乘以一個安全系數 (如 80% - 90%) 作為閾值，為系統預留緩沖空間。

告訴面試官， 壓測是保障性能和可用性的基石，是技術成熟的標志。

缺乏壓測數據支撐，容量規劃、性能優化、成本控制都可能失準。

4、線上的 觀測監控

壓測是理想狀態 ，線上 數據 才是 最真實的 。

如果 峰值 QPS 是 1000，且此時資源利用率（如 CPU 70% / Mem 60%）健康，初步可將集群閾值設為 1200（1000 的峰值 + 200 Buffer），為增長和波動留出余量。”

當然， 線上的峰值不等于系統極限！

很可能你的服務實際能承受 3000 QPS，但因業務規模原因沒達到過，導致閾值設得過于保守 (1200)，有可能造成資源浪費。

如果進行 線上的 觀測監控 ， 請參見 尼恩之前的文章：

高頻面題： 你們線上 QPS 多少？你 怎么知道的？

5、限流閾值 的自適應

確定限流閾值 是一個持續迭代的工程活動。

由于平臺 篇幅限制， 此處省略 1000字+

原始的內容，請參考 本文 的 原文 地址

本文 的 原文 地址