前言

去年夏天某個凌晨，我接到某金融平臺報警：支付接口錯誤率飆升至35%。

趕到機房時，發(fā)現(xiàn)數(shù)據(jù)庫連接池耗盡，大量請求堆積成山——這就是典型的未做限流防護的災(zāi)難現(xiàn)場。

就像高速公路不設(shè)收費站，高峰期必然堵成停車場。

限流的本質(zhì)不是拒絕服務(wù)，而是用可控的犧牲保護核心鏈路。

某電商大促時，他們用令牌桶算法將秒殺接口QPS限制在5萬，雖然流失了20%的突發(fā)流量，但保住了99%的核心交易成功率。

1 常用限流方案

1.1 固定窗口計數(shù)器

核心原理：以固定時間窗口（如1秒）為周期，統(tǒng)計周期內(nèi)請求數(shù)，超過閾值則拒絕后續(xù)請求。

圖片

具體代碼實現(xiàn)如下：

// 線程安全實現(xiàn)（AtomicLong優(yōu)化版）
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;
    }
}

致命缺陷：假設(shè)設(shè)置1秒100次限制，0.9秒時突發(fā)100次請求，下一秒0.1秒又放行100次，實際兩秒內(nèi)通過200次。

就像紅綠燈切換時車輛搶行，容易引發(fā)"臨界點突刺"。

適用場景：日志采集、非關(guān)鍵性接口的粗粒度限流

1.2 滑動窗口

核心原理：將時間窗口細分為更小的時間片（如10秒），統(tǒng)計最近N個時間片的請求總和。

圖片

基于Redis的Lua腳本如下：

// Redis Lua實現(xiàn)滑動窗口（精確到毫秒）
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
    """;

技術(shù)亮點：某證券交易系統(tǒng)采用滑動窗口后，將API異常率從5%壓降至0.3%。

通過Redis ZSET實現(xiàn)時間切片，誤差控制在±10ms內(nèi)。

優(yōu)勢對比

2.3 漏桶算法

核心原理：請求像水流一樣進入漏桶，系統(tǒng)以固定速率處理請求。

桶滿時新請求被丟棄。

圖片

具體實現(xiàn)如下：

// 漏桶動態(tài)實現(xiàn)（Semaphore優(yōu)化版）
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();
    }
}

技術(shù)痛點：某智能家居平臺用此方案，確保即使10萬臺設(shè)備同時上報數(shù)據(jù)，系統(tǒng)仍按500條/秒的速率穩(wěn)定處理。

但突發(fā)流量會導(dǎo)致隊列積壓，就像用漏斗倒奶茶——珍珠容易卡住。

適用場景：IoT設(shè)備控制指令下發(fā)、支付渠道限額等需要嚴格恒定速率的場景

1.4 令牌桶算法

核心原理：以固定速率生成令牌，請求需獲取令牌才能執(zhí)行。

突發(fā)流量可消耗桶內(nèi)積攢的令牌。

圖片

具體實現(xiàn)如下：

// Guava RateLimiter高級用法
RateLimiter limiter = RateLimiter.create(10.0, 1, TimeUnit.SECONDS); // 初始預(yù)熱
limiter.acquire(5); // 嘗試獲取5個令牌

// 動態(tài)調(diào)整速率（需反射實現(xiàn)）
Field field = RateLimiter.class.getDeclaredField("tokens");
field.setAccessible(true);
AtomicDouble tokens = (AtomicDouble) field.get(limiter);
tokens.set(20); // 突發(fā)時注入20個令牌

實戰(zhàn)案例：某視頻平臺用此方案應(yīng)對熱點事件：平時限制10萬QPS，突發(fā)時允許3秒內(nèi)超限50%，既防雪崩又保用戶體驗。

動態(tài)特性

• 正常時限制QPS
• 突發(fā)時允許透支
• 持續(xù)突發(fā)會耗盡令牌

2 生產(chǎn)環(huán)境實戰(zhàn)

2.1 網(wǎng)關(guān)層分布式限流

某電商雙11方案：通過Redis+Lua實現(xiàn)分布式計數(shù)，配合Nginx本地緩存，在網(wǎng)關(guān)層攔截了83%的惡意請求。

圖片

2.2 自適應(yīng)熔斷機制

我們還需要自適應(yīng)熔斷機制。

某社交平臺用此方案，在突發(fā)流量時自動將限流閾值從5萬降到3萬，等系統(tǒng)恢復(fù)后再逐步提升。

圖片

3 避坑指南與性能優(yōu)化

3.1 致命誤區(qū)

在數(shù)據(jù)庫連接池前做限流！

某公司曾因此導(dǎo)致連接泄漏，最終撐爆數(shù)據(jù)庫。

正確做法應(yīng)遵循熔斷三原則：

1. 快速失?。涸谌肟趯訑r截無效請求
2. 動態(tài)降級：核心服務(wù)保留最小資源
3. 自動恢復(fù)：熔斷后漸進式放量

3.2 性能優(yōu)化

某金融系統(tǒng)通過JMH測試發(fā)現(xiàn)，使用LongAdder替代AtomicLong，限流吞吐量提升220%。

圖片

性能優(yōu)化手段：減少CAS競爭 和 分段鎖基座。

圖片

總結(jié)

上面列舉了工作中最常用的4種限流方案。

對于不同的業(yè)務(wù)場景，我們需要選擇不同的限流方案。

圖片

限流的黃金法則如下：

圖片

記?。汉玫南蘖鞣桨妇拖窀哞F閘機——既保證通行效率，又守住安全底線。