4. 限流算法：令牌桶、漏桶、滑动窗口、计数器

限流这个话题，说白了就是控制流量别把系统冲垮。我在生产环境摸爬滚打这些年，踩过不少坑，今天把这四种主流算法掰开揉碎讲清楚。

4.1 计数器算法

计数器是最朴素的限流方式。想象一个计数器，每来一个请求就加1，到时间窗口末尾清零。如果计数超过阈值，直接拒绝。

// 伪代码：固定窗口计数器
val count = atomicIncrement()
if (count > THRESHOLD) {
    if (currentTime - windowStart > WINDOW_SIZE) {
        // 重置窗口
        windowStart = currentTime
        count = 1
    } else {
        return REJECT
    }
}
return ACCEPT

适用场景：对精度要求不高、流量均匀的场景，比如简单的API调用频率控制。

4.2 滑动窗口算法

滑动窗口把时间窗口切成多个小格子，每个格子独立计数。移动窗口时，丢弃旧格子，累加当前格子和之前几个格子的计数。这样就解决了计数器“临界问题”。

适用场景：需要较精确限流，能接受一定内存开销的场景，比如接口防刷。

4.3 漏桶算法

漏桶像一个有底部小洞的水桶。请求像水一样倒进去，桶容量有限，多出来的溢出丢弃。桶底以恒定速率流出请求。说白了，漏桶强制“出水”速率恒定，不管进水有多猛。

我见过一个案例：某团队用漏桶保护Redis写入，结果业务高峰期大量请求被丢弃，用户反馈数据丢失。原因是漏桶不能处理突发——即使用户短时间内发10个请求，只要超过桶容量，直接丢掉9个。这可能是业务无法接受的。

适用场景：对流量整形要求严格、不允许突发的场景。

4.4 令牌桶算法

令牌桶是另一种思路。系统以恒定速率往桶里放令牌，每个请求需要拿走一个令牌才能通过。桶里可以积累一些令牌，允许一定程度的突发。我最初选型时就偏爱令牌桶，因为它既能平滑流量，又能应对短期峰值。

// 令牌桶关键参数（Guava RateLimiter风格）
rate = 10        // 每秒产生令牌数
burst = 20       // 桶容量，最多允许20个突发请求
tokens = 0       // 当前令牌数
lastRefillTime = now()

def acquire():
    refill()
    if tokens >= 1:
        tokens -= 1
        return true
    else:
        return false

def refill():
    now = currentTime()
    elapsed = now - lastRefillTime
    tokens = min(burst, tokens + elapsed * rate)
    lastRefillTime = now

适用场景：需要允许短时间突发，又能平滑整体流量的场景，如API网关、秒杀系统。

4.5 适用场景对比

把四种算法摆在一起看，差别就清楚了。我直接画个图，你再对照下面的表格理解。

看明白了吗？我再给你一张表，把关键差异列清楚。

实际选型时，我一般这样判断：如果下游能力稳定，选漏桶；如果有突发但要求平滑，选令牌桶；如果只是简单防刷，滑动窗口或计数器够用。别一上来就上复杂算法，先想清楚你的业务到底需要什么。