一、限流的核心价值与典型场景

在微服务架构下，网关作为流量入口承担着关键防护职责。当系统面临突发流量（如秒杀活动）、恶意攻击（DDoS）或依赖服务过载时，限流机制能有效保障系统稳定性。某电商平台在”双11”期间通过网关限流，将核心支付接口的QPS控制在2万/秒，成功避免数据库崩溃，这就是限流价值的典型体现。

限流策略需考虑三个维度：阈值设定（如每秒1000请求）、降级策略（返回503或排队等待）、动态调整（基于实时监控数据）。合理的限流设计应兼顾系统保护与用户体验，避免”一刀切”式的拒绝服务。

二、经典限流算法深度解析

1. 令牌桶算法（Token Bucket）

该算法通过固定速率生成令牌，请求到达时需获取令牌方可处理。实现要点包括：

• 桶容量（burst size）决定突发流量承受能力
• 令牌生成速率（rate）控制平均流量
• 分布式环境下需使用Redis等集中式存储

Java示例代码：

public class TokenBucket {
    private final AtomicLong tokens;
    private final long capacity;
    private final long refillRate; // tokens per millisecond
    private long lastRefillTime;
    public TokenBucket(long capacity, long refillRate) {
        this.capacity = capacity;
        this.refillRate = refillRate;
        this.tokens = new AtomicLong(capacity);
        this.lastRefillTime = System.currentTimeMillis();
    }
    public boolean tryAcquire() {
        refill();
        long currentTokens = tokens.get();
        if (currentTokens > 0) {
            if (tokens.compareAndSet(currentTokens, currentTokens - 1)) {
                return true;
            }
        }
        return false;
    }
    private void refill() {
        long now = System.currentTimeMillis();
        long elapsed = now - lastRefillTime;
        long newTokens = elapsed * refillRate;
        if (newTokens > 0) {
            tokens.updateAndGet(current -> Math.min(capacity, current + newTokens));
            lastRefillTime = now;
        }
    }
}

2. 漏桶算法（Leaky Bucket）

与令牌桶相反，漏桶以固定速率处理请求，超出容量的请求排队等待。适用于需要严格速率限制的场景，如API调用频率控制。

3. 计数器算法（Fixed Window）

最简单的实现方式，将时间划分为固定窗口（如1秒），每个窗口独立计数。存在问题：窗口边界处可能出现两倍阈值的突发流量。

4. 滑动窗口计数器（Sliding Window）

改进的计数器算法，维护多个子窗口统计，有效平滑流量。例如将1秒窗口划分为10个100ms的子窗口，统计最近10个子窗口的请求总数。

三、分布式环境下的限流实现

在集群部署场景中，单机限流无法满足需求，需采用分布式协调方案：

1. Redis实现方案

-- Redis Lua脚本实现滑动窗口
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local clearBefore = now - window
redis.call('ZREMRANGEBYSCORE', key, 0, clearBefore)
local current = redis.call('ZCARD', key)
if current < limit then
    redis.call('ZADD', key, now, now)
    redis.call('EXPIRE', key, window)
    return 1
else
    return 0
end

该方案利用Redis的有序集合（ZSET）存储请求时间戳，通过ZREMRANGEBYSCORE清理过期数据，实现精确的滑动窗口计数。

2. Sentinel + Redis集群方案

对于超大规模系统，可采用Sentinel作为协调器，结合Redis集群实现分区限流。每个服务实例向Sentinel注册限流规则，Sentinel通过Redis集群同步全局计数器。

四、工程化实践建议

1. 多维度限流：结合用户ID、IP、API接口等多维度设置限流规则
2. 动态阈值调整：基于历史数据和实时监控动态调整限流阈值
3. 熔断降级：与Hystrix等熔断器配合使用，形成完整防护体系
4. 监控告警：实时展示限流触发次数、拒绝请求数等关键指标
5. 灰度发布：新接口上线时采用更严格的限流策略，逐步放开

某金融系统实践案例：通过网关实现三级限流策略

• 第一级：IP维度，每分钟100请求
• 第二级：用户维度，每秒5请求
• 第三级：接口维度，QPS阈值动态调整
  该方案使系统可用性提升至99.99%，同时保证了90%以上请求的成功率。

五、性能优化方向

1. 本地缓存：在网关本地维护最近请求的计数器，减少Redis访问
2. 原子操作优化：使用Redis的INCR、EXPIRE等原子命令替代Lua脚本
3. 数据分片：将不同接口的计数器分散到不同Redis节点
4. 异步统计：非关键路径的统计数据采用异步方式上报

限流策略的选择需平衡精确性、性能和实现复杂度。对于大多数互联网应用，滑动窗口+Redis的方案在性能和准确性间取得了良好平衡。开发者应根据具体业务场景，通过压测确定最优参数配置，并建立完善的监控体系持续优化限流策略。