API限流算法与HTTP 429状态码实战指南

1. API限流的核心价值与业务痛点

在分布式系统架构中，API限流就像城市交通的信号灯控制系统。我经历过一次惨痛的线上事故：某核心接口被突发流量打垮，导致整个订单系统雪崩。这正是缺乏有效限流机制导致的典型问题。

HTTP 429状态码（Too Many Requests）就是服务端对客户端的礼貌拒绝。当客户端在单位时间内发送过多请求时，服务端返回429响应码并附带Retry-After头部，告知客户端何时可以重试。这种机制比直接返回500错误更优雅，既保护了后端服务，又给客户端明确的恢复指引。

2. 主流限流算法实现与选型

2.1 令牌桶算法实战

令牌桶算法就像游乐园的快速通行证发放机。我们用Redis实现了一个生产级方案：

python复制def is_allowed(user_id):
    key = f"rate_limit:{user_id}"
    # 每秒补充10个令牌，桶容量20个
    rate = 10
    capacity = 20
    now = time.time()
    pipeline = redis.pipeline()
    pipeline.hsetnx(key, 'last_time', now)
    pipeline.hgetall(key)
    last_time, tokens = pipeline.execute()[1].values()
    
    elapsed = now - float(last_time)
    new_tokens = elapsed * rate
    tokens = min(float(tokens) + new_tokens, capacity)
    
    if tokens >= 1:
        pipeline.hset(key, 'last_time', now)
        pipeline.hset(key, 'tokens', tokens - 1)
        pipeline.execute()
        return True
    return False

关键细节：使用Redis管道保证原子性操作，避免并发问题。时间戳用浮点数存储确保精度。

2.2 漏桶算法优化实践

漏桶算法更适合平滑突发流量。我们在网关层用Go实现了这样的控制：

go复制type LeakyBucket struct {
    capacity  int64
    remaining int64
    rate      time.Duration
    last      time.Time
    mutex     sync.Mutex
}

func (b *LeakyBucket) Allow() bool {
    b.mutex.Lock()
    defer b.mutex.Unlock()
    
    now := time.Now()
    elapsed := now.Sub(b.last)
    b.last = now
    
    b.remaining += int64(elapsed / b.rate)
    if b.remaining > b.capacity {
        b.remaining = b.capacity
    }
    
    if b.remaining > 0 {
        b.remaining--
        return true
    }
    return false
}

实测对比：令牌桶允许突发但有限制，漏桶则严格按固定速率处理，选择取决于业务场景。

3. HTTP 429状态码的工程实践

3.1 响应头部的正确设置

规范的429响应应该包含这些头部：

http复制HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1669852800

{
    "code": 429,
    "message": "Rate limit exceeded",
    "retry_after": 60
}

踩坑记录：曾经忘记设置Retry-After导致客户端无限制重试，反而加剧了服务压力。

3.2 客户端处理的最佳实践

前端应该这样处理429响应：

javascript复制async function fetchWithRetry(url, options = {}, retries = 3) {
    try {
        const response = await fetch(url, options);
        if (response.status === 429) {
            const retryAfter = response.headers.get('Retry-After') || 1;
            await new Promise(resolve => 
                setTimeout(resolve, retryAfter * 1000));
            return fetchWithRetry(url, options, retries - 1);
        }
        return response;
    } catch (error) {
        if (retries <= 0) throw error;
        return fetchWithRetry(url, options, retries - 1);
    }
}

移动端还需要考虑网络切换时的补偿机制，避免重复计数。

4. 分布式环境下的限流架构

4.1 Redis+Lua的分布式方案

我们使用这个Lua脚本保证集群限流的原子性：

lua复制local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current = redis.call('GET', key)
local now = tonumber(ARGV[3])

if current == false then
    redis.call('SET', key, 1, 'EX', window)
    return 1
end

if tonumber(current) >= limit then
    return 0
end

redis.call('INCR', key)
return 1

调用示例：

bash复制redis-cli --eval rate_limiter.lua api_limit:user123 , 100 60 $(date +%s)

4.2 自适应限流策略

基于系统负载的动态限流算法：

python复制def adaptive_rate_limit():
    cpu_load = get_cpu_usage()
    mem_usage = get_memory_usage()
    
    base_rate = 1000  # 基准QPS
    if cpu_load > 0.8 or mem_usage > 0.8:
        return base_rate * 0.5
    elif cpu_load > 0.6:
        return base_rate * 0.8
    else:
        return base_rate

结合Prometheus指标实现动态调整，这是我们线上环境的黄金配置。

5. 生产环境避坑指南

5.1 监控埋点必须包含的指标

• 限流触发次数（按用户/接口维度）
• 平均等待重试时间
• 被拒绝请求的业务类型分布
• 限流导致的业务损失估算

我们用的Grafana监控面板配置：

sql复制sum(rate(api_429_total{service="$service"}[5m])) by (endpoint)

5.2 突发流量处理技巧

1. 预热机制：新上线服务逐步放开限流阈值
2. 分级降级：核心接口与非核心接口区别对待
3. 流量整形：使用消息队列缓冲突发请求
4. 客户端缓存：对429响应实现自动退避算法

曾经有个电商大促场景，通过动态调整不同品类接口的限流阈值，在保证核心交易链路的同时，平稳度过了流量高峰。