谷歌把這功能藏了15年，開發者發現后集體破防

每秒10萬個請求砸過來，你的服務器能撐幾秒？2023年某頭部電商大促期間，一個未設限的支付接口在47秒內被刷爆，直接損失3400萬訂單。這不是攻擊，是正常用戶+爬蟲+羊毛黨的混合流量——沒有限流（Rate Limiting），現代系統就像沒有閘門的泄洪道。

限流的本質很簡單：規定"Y時間內最多X次請求"。但簡單的規則背后，藏著一整套生存哲學。

Token Bucket：允許你"透支"，但得還

想象一個不斷往里投幣的存錢罐。罐子的容量是100枚，每秒自動補充10枚。你可以一口氣花光100枚買個大件，但之后每秒只能花10枚——這就是Token Bucket（令牌桶）的工作邏輯。

它聰明在"彈性"。某視頻平臺用這套算法處理上傳請求：普通用戶突傳10條4K視頻，系統放行；但想持續刷量？門兒沒有。令牌耗盡后，第11條視頻直接排隊或拒絕。

具體參數怎么設？原文給出的典型配置是：桶容量100， refill rate（補充速率）10/秒。這意味著用戶瞬間爆發100請求被允許，但長期平均必須壓在10/秒以下。這種"先松后緊"的策略，比一刀切更符合真實業務場景。

Leaky Bucket：勻速排隊，拒絕插隊

與Token Bucket的彈性相反，Leaky Bucket（漏桶）像個紀律嚴明的流水線。請求進來先排隊，以固定速率"漏"出去處理。桶滿了？新來的直接溢出丟棄。

某金融交易系統選了這個方案。理由很現實：他們不能容忍任何突發，哪怕犧牲一點響應速度，也要保證每秒處理量絕對平穩。漏桶的缺陷也明顯——它無法應對合法流量激增，大促時容易誤殺。

兩種算法沒有優劣，只有場景適配。Token Bucket適合"偶爾浪一下可以"的業務，Leaky Bucket適合"必須穩如老狗"的場景。

分布式限流：單機思維死在微服務時代

當你的服務部署在12個可用區、800臺實例上，單機的限流計數器就成了笑話。用戶A的請求被負載均衡隨機打到實例1和實例2，兩臺機器各自計數，限流閾值直接翻倍失效。

解決方案是集中式存儲。Redis成了行業標配：每次請求先查Redis計數器，原子性遞增，超過閾值即拒。但這里藏著延遲陷阱——網絡往返多了幾十毫秒，高頻場景下Redis本身可能成為瓶頸。

更激進的方案是本地緩存+異步同步。每臺機器先用自己的內存計數器快速決策，定期把消耗量上報中心。犧牲一點精度，換回十倍性能。某云廠商的內部數據顯示，這種"最終一致"方案把限流延遲從15ms壓到了0.3ms。

限流的反噬：誤殺與用戶體驗

2022年某社交App上線新限流策略，把驗證碼接口壓到1/分鐘。本意是防羊毛黨，結果正常用戶注冊時被反復攔截，次日留存率暴跌23%。技術團隊復盤時發現：他們沒區分"同一設備"和"同一IP"，網吧用戶集體中招。

精細化的維度設計成了新戰場。現代限流系統至少支持四層維度：用戶ID、設備指紋、IP地址、業務類型。某頭部云服務的控制臺顯示，其企業客戶平均配置11.7條限流規則，最復雜的游戲客戶有340條。

返回什么錯誤也講究。直接拋503？用戶以為服務掛了。好的實踐是429狀態碼（Too Many Requests）+ Retry-After頭，告訴客戶端"多久后再試"。某出行App把這個時間窗口動態化：高峰期提示"60秒后重試"，平峰期"5秒即可"，用戶投訴率下降67%。

從防御到博弈：限流的進化

早期限流是"擋子彈"，現在成了"做生意"。某內容平臺的推薦接口，對不同用戶等級實施差異化限流：免費用戶100/天，會員1000/天，企業客戶無上限。限流閾值直接寫進了定價策略。

更隱蔽的是"柔性限流"。不直接拒絕，而是降級——返回緩存數據、簡化計算邏輯、關閉非核心功能。某搜索引擎在流量洪峰時，會把結果排序的機器學習模型切換為輕量規則引擎，查詢延遲從120ms降到40ms，用戶幾乎無感知。

這種設計哲學延伸到架構層面。Netflix的Chaos Engineering（混沌工程）團隊定期模擬限流失效，驗證系統在極端情況下的降級路徑。他們的內部文檔寫道："我們不測試限流是否工作，測試的是限流失效后系統會不會優雅地爛掉。"

回到開頭那個電商事故。事后復盤顯示，他們的支付接口確實配置了限流，但閾值設得太高——5000/秒，而單實例實際承載只有800/秒。限流成了擺設，災難如期而至。

你的系統限流閾值，是基于壓測數據，還是拍腦袋定的？上次驗證這個閾值的有效性，是什么時候？