从单机令牌桶到集群限流：一次配额超发的复盘

一、配额 1000 的那天，我们实际发出了 1780

背景：对接的开放平台给了 1000 QPS 的调用配额，我们的服务部署在 8 个实例上。

设计时的算法很简单也很自然：1000 ÷ 8 = 125，每个实例用本地令牌桶限 125。

上线两周相安无事。然后某天上午，开放平台侧开始返回流控错误码，错误集中在订单同步那条链路上。

拉监控出来看，出站请求的峰值是 1780 QPS，不是 1000。

二、算得没错，错在假设

125 × 8 = 1000 这个算术是对的。它成立的前提是流量均匀落到 8 台机器上。

现实是：

3 台机器扛了大部分流量，本地令牌桶各自放满 125，加起来已经超了；
另外 5 台还有余量，但额度不能跨机器调配；
全局视角看，谁也不知道现在一共发了多少。

所以「总配额 ÷ 实例数」这个做法，在流量倾斜时必然失效。问题不在阈值算错，在于每台机器各算各的。

分布式系统里有一类共同的坑：本地计数器、本地锁、本地限速，这三样在单机上都是对的，放大到多实例之后全都不对。判断标准不是「这段代码对不对」，而是「这段代码跑在几个实例上，还对不对」。

三、第一版改造：把桶搬到中心

最直接的改法是集中计数：令牌桶状态放到中心存储里，8 台机器共享同一个桶。

这一版解决了总量失控，但带来了两个新问题。

问题一：中心成了瓶颈。 每个出站请求都要往返一次中心，热路径上多一次网络调用。峰值时中心存储的 QPS 就等于我们的出站 QPS，等于把压力从开放平台门口搬到了自己的存储上。

问题二：读写不是原子的。 第一版实现是「读状态 → 算令牌 → 写回」三段：

scss 复制代码

# 错误写法：三段之间可以插入其他请求
tokens, ts = load_state(key)
tokens = refill(tokens, ts)
if tokens >= 1:
    save_state(key, tokens - 1, now())
    return True
return False

并发下两个请求同时读到「还剩 1 个令牌」，两个都判断通过、都放行。限流组件自己就多放了额度------账面永远对不上。

四、第二版：原子脚本 + 分段预取

4.1 四步放进一段脚本

ini 复制代码

-- KEYS[1] 桶的键；ARGV[1] 速率（个/秒）；ARGV[2] 容量；ARGV[3] 本次要取的个数
local key   = KEYS[1]
local rate  = tonumber(ARGV[1])
local cap   = tonumber(ARGV[2])
local want  = tonumber(ARGV[3])

local t = redis.call('TIME')                 -- 取中心时间，不用本机时钟
local now = tonumber(t[1]) + tonumber(t[2]) / 1000000

local data = redis.call('HMGET', key, 'tokens', 'ts')
local tokens = tonumber(data[1])
local ts = tonumber(data[2])
if tokens == nil then
    tokens = cap
    ts = now
end

local delta = now - ts
if delta > 0 then
    tokens = math.min(cap, tokens + delta * rate)
end

if tokens < want then
    redis.call('HMSET', key, 'tokens', tokens, 'ts', now)
    return 0                                  -- 拒绝
end
redis.call('HMSET', key, 'tokens', tokens - want, 'ts', now)
return want                                   -- 放行

四个要点：

读、补、判、写在一次执行内完成。 中间不会插入其他命令，不存在「两个请求都读到还剩 1 个」的窗口。

时间取中心时间。 用中心的时间而不是应用服务器本地时钟------多机时钟不同步或时钟回拨，会让时间差变成负数，令牌数算出异常值。

不够就拒绝，不排队。 排队会把限流变成延迟放大器，最后一起超时。

容量与速率两个旋钮独立。 速率决定长期配额，容量决定能扛多猛的突发。

4.2 分段预取，把中心压力降下来

每请求都问一次中心，压力扛不住。改成一次领一批：

python 复制代码

import redis

r = redis.Redis(host="127.0.0.1", port=6379, db=0)

class PrefetchLimiter:
    """一次从中心领 batch 个额度，本地发完再去领。"""

    def __init__(self, key, rate, cap, batch=20):
        self.key = key
        self.batch = batch
        self.args = [rate, cap, batch]
        self.left = 0

    def take(self) -> bool:
        if self.left <= 0:
            got = r.eval(LUA_TAKE, 1, self.key, *self.args)
            if not got:
                return False
            self.left = int(got)
        self.left -= 1
        return True

中心压力降到 1/20，代价是最多浪费 20 个额度（实例本地还剩额度但整体已超限）。这个误差和调用总量比可以忽略。

批量大小要和超时预算同量级。 批太大，本地囤着一堆额度慢慢发，中心看到的速率和实际速率偏差变大；批太小，省不下往返。

4.3 中心不可用时的选择

限流组件是保险丝，不是总开关。中心存储故障时，正确做法是放行并记录，不是全部拒绝。

python 复制代码

def take_safe(self) -> bool:
    try:
        return self.take()
    except redis.exceptions.RedisError:
        metrics.incr("limiter.center_down")
        return self.local_fallback.take()   # 退到本地宽松阈值

五、上线顺序

限流器最忌讳的是「上线即误伤」。正确顺序是三步：

只记录不拦截：先跑一周，只记录会拦谁、拦多少，看清楚再开；
按调用方分别开：先给异常调用量最大的那条链路开，观察一天；
保留一键关闭：配置里留开关，出问题能立刻降级为只记录。

六、检查清单

配额是集中计数的，不是「总配额 ÷ 实例数」本地各限一份
读、补、判、写在一段脚本里原子完成
时间差用的是中心时间或单调时钟，不是本机墙上时间
有分段预取，中心压力与出站 QPS 不是一个量级
中心不可用时是放行 + 告警，不是全拒
速率与容量两个参数分别可调，容量按突发幅度定
被拒绝时返回明确的重试等待秒数，不静默丢弃
有一条监控看「限流命中率」，突然飙高说明有调用方在异常重试
对下游依赖单独限制并发，入口限住不代表出口安全
上线顺序是「先记录、后拦截」，且保留一键关闭

七、一句总结

这次超发的根因不是阈值算错，是把「全局共享的额度」当成了「每台机器各自持有的额度」。

分布式系统里的判断标准很简单：这个状态，是我独占的，还是大家共享的？ 答案决定实现方式------共享的状态，就必须在共享的地方算。

相关参考： 跨境电商平台接口与数据服务方案