限流算法选型从计数器到令牌桶的实践对比

限流是分布式系统应对高并发访问的必备手段，但选错限流算法会让系统陷入更危险的境地。核心观点：没有一种限流算法能适用于所有场景，必须根据业务特点选择最适合的算法，并配合熔断降级机制才能构建真正的高可用系统。

计数器算法实现简单但存在临界突发问题

计数器算法是限流中最直观的实现方式。它通过维护一个固定时间窗口内的请求计数，当计数超过阈值时拒绝后续请求。实现代码通常如下：

package main

import "time"

type CounterLimiter struct {
    limit    int
    interval time.Duration
    count    int
    lastTime time.Time
}

func (c *CounterLimiter) Allow() bool {
    now := time.Now()
    if now.Sub(c.lastTime) >= c.interval {
        c.count = 0
        c.lastTime = now
    }
    if c.count < c.limit {
        c.count++
        return true
    }
    return false
}

这段代码在大多数场景下能正常工作，但有一个致命缺陷：临界突发问题。例如，设置每秒10个请求，在第一个窗口的最后10ms内来了10个请求，紧接着第二个窗口的开始10ms内又来了10个请求，系统在20ms内承受了20个请求，远超阈值。

这种问题在秒杀、抢红包等场景中尤为突出。据某电商平台生产事故复盘，双十一零点瞬间，由于计数器限流的边界效应，导致下游数据库连接池瞬间被打满，引发长达5分钟的级联故障。解决方法是改用滑动窗口算法或令牌桶算法。

滑动窗口算法解决临界问题但误差仍存在

滑动窗口算法将时间窗口细分为多个小格子，每个格子记录请求数，每次请求时滑动窗口，计算整个窗口内的总请求数。这种方法能有效平滑边界突发，但实现复杂度增加，且仍然存在窗口精度带来的误差。格子越细，精度越高，但内存占用也越大。

对比表格如下：

据《分布式系统设计》一书中的案例，某电商平台在双十一活动中使用计数器限流，导致系统在整点切换时瞬间压垮，后改用滑动窗口后问题解决。这说明滑动窗口在大多数业务场景下是计数器算法的有效替代。但需要注意的是，滑动窗口的格子大小选择需要权衡，例如10秒窗口分成10个1秒格子，精度较高但内存占用为计数器方案的10倍。

漏桶算法适合平滑流量但无法应对突发

漏桶算法将请求看作水滴，以恒定速率流出，桶满则溢出拒绝。它强制流量平滑，适合需要严格控制出口速率的场景，如数据库写入限流。但缺点是无法应对突发请求，即使系统空闲，也不允许瞬时爆发。

import time

class LeakyBucket:
    def __init__(self, capacity, rate):
        self.capacity = capacity
        self.rate = rate  # 每秒流出数量
        self.water = 0
        self.last_time = time.time()
    
    def allow(self):
        now = time.time()
        elapsed = now - self.last_time
        self.water = max(0, self.water - elapsed * self.rate)
        self.last_time = now
        if self.water < self.capacity:
            self.water += 1
            return True
        return False

漏桶算法的典型应用是Nginx的limit_req模块，它使用漏桶思想实现请求限流，效果稳定。但实际生产中发现，如果对API接口使用漏桶，会导致用户请求响应时间波动较大，因为漏桶强制排队，即使系统有富余资源也无法利用。因此漏桶更适合对流量平滑性要求极高的场景，比如视频流码率控制或数据库写入限流。

令牌桶算法平衡突发与平滑但需合理配置参数

令牌桶算法以固定速率向桶中添加令牌，请求需要消耗令牌才能通过。桶内可积累令牌，允许一定量的突发。Google Guava的RateLimiter就是基于令牌桶实现，但增加了预热功能。关键参数是令牌生成速率和桶容量。容量太大失去限流意义，容量太小无法应对合理突发。

据Guava官方文档，RateLimiter的平滑突发模式（SmoothBursty）允许桶内积累最多1秒的令牌数，即突发量等于平均速率。而预热模式（SmoothWarmingUp）则让令牌生成速率逐渐加速，避免冷启动时的瞬时压力。实际使用中，需要根据业务容忍度调整桶容量，例如允许突发2倍平均速率，则容量设为速率的两倍。

RateLimiter limiter = RateLimiter.create(10.0); // 每秒10个令牌
while (true) {
    limiter.acquire(); // 阻塞等待
    // 处理请求
}

令牌桶算法在微服务网关中广泛使用，如Spring Cloud Gateway的RequestRateLimiter过滤器，底层基于Redis实现分布式令牌桶。但需要注意，分布式环境下令牌桶的同步开销较大，需要谨慎设计桶的粒度。

分布式限流需要引入中间件如Redis或Sentinel

单机限流在集群环境下无法保证全局限制，必须引入分布式协调组件。常见的方案有基于Redis的Lua脚本实现令牌桶，或者使用阿里开源的Sentinel。Sentinel不仅支持限流，还集成了熔断降级、系统自适应保护等功能，是微服务架构的首选。

基于Redis的限流示例（Lua脚本）：

local key = KEYS[1]
local limit = tonumber(ARGV[1])
local interval = tonumber(ARGV[2])
local current = redis.call('INCR', key)
if current == 1 then
    redis.call('EXPIRE', key, interval)
end
if current > limit then
    return 0
else
    return 1
end

注意，这种简单计数器同样存在临界问题，分布式环境下建议使用滑动窗口算法（如Redis的Sorted Set实现）。Sentinel则提供了更高级的限流策略，包括基于调用关系的限流、基于热点参数的限流，并且支持动态规则配置，不需要重启应用。

对比不同中间件的限流能力：

限流与熔断降级配合才能构建高可用系统

限流只是第一道防线，当限流被触发时，系统需要优雅降级，而不是直接拒绝。熔断机制则是在连续失败达到阈值时快速切断链路，防止雪崩。三者配合：限流拒绝请求后，降级返回友好提示；熔断在检测到下游故障时自动断开，避免无效调用。

例如，在微服务调用链中，如果A服务调用B服务，B服务出现故障，A服务应该先尝试限流，如果B频繁超时，则触发熔断，不再调用B，直接降级。这种组合策略在Hystrix和Sentinel中都有成熟实现。据Netflix官方博客，Hystrix的熔断阈值默认设为50%的失败率，但需要根据业务调整。Sentinel则提供了更细粒度的指标统计，如秒级RT、异常比例等。

总结：限流算法的选择不是简单的技术选型，而是对业务场景的深刻理解。计数器简单但危险，漏桶和令牌桶各有取舍，分布式场景下必须依赖中间件。建议开发者在项目初期就做好限流设计，并配合熔断降级，以应对不可预知的流量高峰。同时，限流参数需要动态调整，结合监控数据（如QPS、响应时间、CPU使用率）进行自适应优化，才能真正发挥限流的作用。