Node.js限流踩坑：3種算法讓服務器少崩80%事故

凌晨2點，/auth/login被刷了5萬次，數據庫直接躺平。這不是段子，是生產環境每周都在上演的劇本。express-rate-limit（Express框架的速率限制中間件）裝了嗎？裝了。Redis配了嗎？配了。為什么還是崩？問題出在算法選型和分布式部署的細節盲區。

固定窗口、滑動窗口、滑動日志——三種算法在內存占用和精度之間做了完全不同的取舍，而大多數人直到出事故才意識到選錯了。

固定窗口：省內存，但邊界爆破

把時間切成固定桶，比如每分鐘100請求。實現簡單，內存只要一個計數器。00:00-01:00收了95個，01:00-02:00收了100個，看起來都在限額內。

但00:59發100個，01:01再發100個，兩秒內200請求擊穿防線。這叫邊界突發（burst at window boundaries），是固定窗口的原生缺陷。適合內部工具、低優先級接口，絕不建議用在登錄、支付這類敏感端點。

滑動日志：精確到毫秒，內存爆炸

給每個請求打時間戳，只統計最近N秒內的數量。精度100%，但內存隨請求量線性增長。一個IP一分鐘1000請求，就要存1000個時間戳。多實例部署時還要跨進程同步，延遲和復雜度雙雙起飛。

除非你的QPS極低且對精度有強迫癥，否則生產環境很少直接用這個。

滑動窗口：90%精度的甜蜜點

存兩個數：上一窗口計數、當前窗口計數。按時間進度加權估算：

estimated_count = prev_count × (1 - elapsed_ratio) + curr_count

內存O(1)，精度足夠，express-rate-limit的Redis存儲默認就是這個算法。Redis（遠程字典服務，內存數據庫）在這里的角色不是緩存，而是分布式狀態同步器——多實例Node.js服務共享同一份計數，避免單機限流變成單機各自為政。

npm install express-rate-limit之后，真正的工作才開始。

配置里的魔鬼細節

standardHeaders: 'draft-7' 這行必須開。它返回RateLimit-Limit、RateLimit-Remaining、RateLimit-Reset三個頭，符合RFC 6585標準?？蛻舳四軗俗鲋笖低吮埽╡xponential backoff），而不是瞎猜多久后重試。

legacyHeaders: false 建議關。X-RateLimit-*是老規范，現在的新客戶端不認，留著徒增噪音。

keyGenerator默認按IP限流。登錄接口要改成按用戶ID或API Key，否則同一NAT出口的用戶互相誤傷，攻擊者換IP就能繞過。

handler函數里務必返回429狀態碼和Retry-After頭。很多開發者圖省事只拋個錯誤，結果客戶端拿到500，以為是自己代碼問題，瘋狂重試把服務埋得更深。

分布式部署的隱藏陷阱

單實例用內存存儲沒問題，水平擴展后必須切Redis。但Redis也有坑：網絡抖動時計數延遲，限流失效；Redis掛了，限流策略是降級放行還是拒絕服務？這個決策要在配置里顯式聲明，不能留給運行時隨機。

多區域部署更麻煩。美東和亞太各有一組Node.js實例，共用一套Redis還是各玩各的？共用有跨洋延遲，分治有全局限流漏洞。沒有標準答案，只有業務權衡。

per-route策略常被忽略。/health-check給1000/min，/auth/login給10/min，/webhook給50/min——不同端點的成本模型完全不同，一刀切是懶惰。

API Key分級是另一個戰場。免費用戶100/天，Pro用戶10000/天，Enterprise不限量但走單獨集群。keyGenerator里要解析Key的tier字段，路由到不同的Redis key前綴，否則計費邏輯和限流邏輯打架。

最后檢查清單：算法選對了嗎？Redis配了嗎？keyGenerator覆蓋認證場景了嗎？429響應帶Retry-After了嗎？多實例共享狀態了嗎？