限流與背压控制
前言
雙十一零點，几億用户同時涌入——服務器扛得住吗？ 任何系统都有處理能力的上限。当請求量超過系统承載能力時，如果不加控制，結果就是所有人都用不了。限流和背压就是保護系统不被"压垮"的兩道防线。
這篇文章會带你學什么？
學完這章後，你将獲得：
- 限流必要性：理解為什么需要主動拒绝部分請求來保護系统
- 限流算法：掌握令牌桶、漏桶、滑動窗口三種核心算法的原理和差异
- 背压機制：理解当上游速度超過下游時的處理策略
- 多層限流：了解從客户端到網關到服務的多層限流架構
- 實戰能力：知道在什么場景下選择什么限流策略
| 章節 | 內容 | 核心概念 |
|---|---|---|
| 第 1 章 | 為什么需要限流 | 雪崩效應、服務保護 |
| 第 2 章 | 限流算法 | 令牌桶、漏桶、滑動窗口 |
| 第 3 章 | 背压控制 | 緩衝區、丟弃策略、弹性擴容 |
| 第 4 章 | 多層限流架構 | 客户端、網關、服務端 |
| 第 5 章 | 實戰與選型 | Nginx、Redis、Sentinel |
0. 全景图：為什么要"拒绝"用户？
這听起來很反直觉——我们不是應該服務好每一个用户吗？但現實是：不拒绝一部分請求，所有請求都會失敗。
想象一个只能坐 100 人的餐厅，突然涌進來 1000 人。如果不限流，結果不是 1000 人都能吃上飯，而是厨房崩溃、服務员瘫痪，1000 人誰都吃不上。正确的做法是在門口排队限流，讓 100 人先進去，其餘人等候。
限流的核心目標
- 保護系统：防止過載導致服務完全不可用
- 公平分配：确保已接受的請求能正常處理
- 優雅降级：被限流的請求收到明确的 429 狀態碼，而不是超時或 500 錯误
1. 限流算法：三種經典方案
限流的核心問题是：在單位時間內，最多允许多少个請求通過？ 不同的算法在精确度、突發流量處理、實現複雜度上各有取舍。
Rate Limiting Algorithm Comparison
Choose an algorithm, then send requests to observe the effect
Passed0
Rejected0
Tokens left5
Token bucket
Adds tokens to the bucket at a fixed rate. Each request consumes one token, and extra tokens are discarded when the bucket is full. It allows bursts when stored tokens are available.
| 算法 | 原理 | 突發流量 | 精确度 | 實現複雜度 |
|---|---|---|---|---|
| 令牌桶 | 固定速率放令牌，請求消耗令牌 | 允许（桶中有存量） | 高 | 中 |
| 漏桶 | 請求排队，固定速率處理 | 不允许（完全平滑） | 高 | 中 |
| 滑動窗口 | 统計窗口內請求數 | 部分允许 | 較高 | 低 |
| 固定窗口 | 按時間窗口計數 | 邊界處可能突發 | 低 | 最低 |
選哪个算法？
- API 限流：令牌桶最常用，允许合理的突發流量
- 流量整形：漏桶適合需要恒定輸出速率的場景
- 简單計數：滑動窗口實現简單，適合大多數 Web 應用
2. 背压控制：当上游比下游快
限流解决的是"外部請求太多"的問题，而背压（Backpressure）解决的是"內部組件速度不匹配"的問题。
当生產者產生數據的速度持續超過消費者處理數據的速度時，中間的緩衝區會不断膨胀，最终導致內存溢出或數據丟失。背压機制就是讓消費者能够"反向通知"生產者减速。
Backpressure Control
What happens when production is faster than consumption?
Produce rate:6/s
Consume rate:3/s
Producer
6/s
Buffer (0/20)
Running normally
Consumer
3/s
Backpressure strategies:
Drop strategy
Drop new data directly when the buffer is full
Example: log collection, real-time metrics
Blocking strategy
Make producers wait when the buffer is full
Example: Go channels, Java BlockingQueue
Sampling strategy
Process only part of the data and skip the rest
Example: downsampling high-frequency sensor data
Elastic scaling
Dynamically increase the number of consumers
Example: Kubernetes HPA autoscaling
背压的四種策略
- 丟弃（Drop）：緩衝區满時丟弃新數據或舊數據，適合實時性要求高但允许丟失的場景
- 阻塞（Block）：讓生產者暂停，等消費者處理完再继續，適合數據不能丟失的場景
- 采样（Sample）：只處理部分數據，適合高频數據流
- 弹性擴容（Scale）：動態增加消費者數量，適合云原生環境
3. 多層限流架構
生產環境中，限流不是在某一个點做就够了，而是需要多層防護，每一層解决不同粒度的問题。
| 層级 | 位置 | 限流粒度 | 工具 |
|---|---|---|---|
| 客户端 | 前端/App | 按钮防抖、請求節流 | lodash.throttle、debounce |
| CDN/WAF | 邊缘節點 | IP 级別、地域级別 | Cloudflare Rate Limiting |
| API 網關 | 入口網關 | 路由级別、用户级別 | Nginx limit_req、Kong |
| 服務端 | 應用內部 | 接口级別、资源级別 | Sentinel、Resilience4j |
| 數據庫 | 存儲層 | 連接數、QPS | 連接池配置、慢查询熔断 |
限流的 HTTP 規范
被限流的請求應該返回 429 Too Many Requests 狀態碼，并在響應頭中包含：
Retry-After: 建议客户端多久後重試（秒數或日期）X-RateLimit-Limit: 限流上限X-RateLimit-Remaining: 剩餘配额X-RateLimit-Reset: 配额重置時間
4. 實戰選型
| 場景 | 推荐方案 | 說明 |
|---|---|---|
| Nginx 入口限流 | limit_req_zone | 基于漏桶算法，配置简單 |
| 分布式限流 | Redis + Lua 脚本 | 令牌桶或滑動窗口，多實例共享計數 |
| Java 微服務 | Sentinel / Resilience4j | 支持熔断、降级、热點限流 |
| Node.js API | express-rate-limit | 简單易用，支持 Redis 存儲 |
| Go 服務 | golang.org/x/time/rate | 標準庫令牌桶實現 |
總結
限流和背压是保護系统穩定性的兩道關鍵防线。限流控制外部流量的涌入速度，背压協調內部組件的處理速度。
回顧本章的關鍵要點：
- 限流的必要性：不拒绝部分請求，所有請求都會失敗
- 三種核心算法：令牌桶（允许突發）、漏桶（完全平滑）、滑動窗口（简單精确）
- 背压機制：丟弃、阻塞、采样、擴容四種策略
- 多層防護：從客户端到數據庫，每層解决不同粒度的問题
- 429 規范：被限流時返回標準狀態碼和限流頭信息
延伸阅讀
- Stripe 的限流實踐 - 支付系统的限流設計
- Nginx limit_req 文檔 - Nginx 限流模塊
- Alibaba Sentinel - 面向分布式服務的流量控制組件
- Resilience4j - Java 輕量级容錯庫
- Token Bucket 算法詳解 - 令牌桶算法的數學原理