瞧瞧別人家的限流，那叫一個優雅！
前言
去年夏天某個凌晨，我接到某金融平臺報警：支付接口錯誤率飆升至35%。
趕到機房時，發現數據庫連接池耗盡，大量請求堆積成山——這就是典型的未做限流防護的災難現場。
就像高速公路不設收費站，高峰期必然堵成停車場。
限流的本質不是拒絕服務，而是用可控的犧牲保護核心鏈路。
某電商大促時，他們用令牌桶算法將秒殺接口QPS限制在5萬，雖然流失了20%的突發流量，但保住了99%的核心交易成功率。
1 常用限流方案
1.1 固定窗口計數器
核心原理：以固定時間窗口（如1秒）為周期，統計周期內請求數，超過閾值則拒絕后續請求。
圖片
具體代碼實現如下：
// 線程安全實現（AtomicLong優化版）
publicclass FixedWindowCounter {
privatefinal AtomicLong counter = new AtomicLong(0);
privatevolatilelong windowStart = System.currentTimeMillis();
privatefinalint maxRequests;
privatefinallong windowMillis;
public boolean tryAcquire() {
long now = System.currentTimeMillis();
if (now - windowStart > windowMillis) {
if (counter.compareAndSet(counter.get(), 0)) {
windowStart = now;
}
}
return counter.incrementAndGet() <= maxRequests;
}
}致命缺陷：假設設置1秒100次限制，0.9秒時突發100次請求，下一秒0.1秒又放行100次，實際兩秒內通過200次。
就像紅綠燈切換時車輛搶行，容易引發"臨界點突刺"。
適用場景：日志采集、非關鍵性接口的粗粒度限流
1.2 滑動窗口
核心原理：將時間窗口細分為更小的時間片（如10秒），統計最近N個時間片的請求總和。
圖片
基于Redis的Lua腳本如下：
// Redis Lua實現滑動窗口（精確到毫秒）
String lua = """
local now = tonumber(ARGV
local window = tonumber(ARGV
local key = KEYS[1]
redis.call('ZREMRANGEBYSCORE', key, '-inf', now - window)
local count = redis.call('ZCARD', key)
if count < tonumber(ARGV then
redis.call('ZADD', key, now, now)
redis.call('EXPIRE', key, window/1000)
return 1
end
return 0
""";技術亮點：某證券交易系統采用滑動窗口后，將API異常率從5%壓降至0.3%。
通過Redis ZSET實現時間切片，誤差控制在±10ms內。
優勢對比
指標 | 固定窗口 | 滑動窗口 |
時間精度 | 1秒 | 100ms |
臨界突刺問題 | 存在 | 消除 |
實現復雜度 | 簡單 | 中等 |
2.3 漏桶算法
核心原理：請求像水流一樣進入漏桶，系統以固定速率處理請求。
桶滿時新請求被丟棄。
圖片
具體實現如下：
// 漏桶動態實現（Semaphore優化版）
publicclass LeakyBucket {
privatefinal Semaphore permits;
privatefinal ScheduledExecutorService scheduler;
public LeakyBucket(int rate) {
this.permits = new Semaphore(rate);
this.scheduler = Executors.newScheduledThreadPool(1);
scheduler.scheduleAtFixedRate(() -> permits.release(rate), 1, 1, TimeUnit.SECONDS);
}
public boolean tryAcquire() {
return permits.tryAcquire();
}
}技術痛點：某智能家居平臺用此方案，確保即使10萬臺設備同時上報數據，系統仍按500條/秒的速率穩定處理。
但突發流量會導致隊列積壓，就像用漏斗倒奶茶——珍珠容易卡住。
適用場景：IoT設備控制指令下發、支付渠道限額等需要嚴格恒定速率的場景
1.4 令牌桶算法
核心原理：以固定速率生成令牌，請求需獲取令牌才能執行。
突發流量可消耗桶內積攢的令牌。
圖片
具體實現如下：
// Guava RateLimiter高級用法
RateLimiter limiter = RateLimiter.create(10.0, 1, TimeUnit.SECONDS); // 初始預熱
limiter.acquire(5); // 嘗試獲取5個令牌
// 動態調整速率（需反射實現）
Field field = RateLimiter.class.getDeclaredField("tokens");
field.setAccessible(true);
AtomicDouble tokens = (AtomicDouble) field.get(limiter);
tokens.set(20); // 突發時注入20個令牌實戰案例：某視頻平臺用此方案應對熱點事件：平時限制10萬QPS，突發時允許3秒內超限50%，既防雪崩又保用戶體驗。
動態特性
- 正常時限制QPS
- 突發時允許透支
- 持續突發會耗盡令牌
2 生產環境實戰
2.1 網關層分布式限流
某電商雙11方案：通過Redis+Lua實現分布式計數，配合Nginx本地緩存，在網關層攔截了83%的惡意請求。
圖片
2.2 自適應熔斷機制
我們還需要自適應熔斷機制。
某社交平臺用此方案，在突發流量時自動將限流閾值從5萬降到3萬，等系統恢復后再逐步提升。
圖片
3 避坑指南與性能優化
3.1 致命誤區
在數據庫連接池前做限流！
某公司曾因此導致連接泄漏，最終撐爆數據庫。
正確做法應遵循熔斷三原則：
- 快速失敗：在入口層攔截無效請求
- 動態降級：核心服務保留最小資源
- 自動恢復：熔斷后漸進式放量
3.2 性能優化
某金融系統通過JMH測試發現，使用LongAdder替代AtomicLong，限流吞吐量提升220%。
圖片
性能優化手段：減少CAS競爭 和 分段鎖基座。
圖片
總結
上面列舉了工作中最常用的4種限流方案。
對于不同的業務場景，我們需要選擇不同的限流方案。
圖片
限流的黃金法則如下：
圖片
記住：好的限流方案就像高鐵閘機——既保證通行效率，又守住安全底線。
