令牌桶更适合大多数php api网关场景,因其支持突发流量、可动态调速且能精准实现匀速补令牌;漏桶仅适用于金融清算等强稳定性要求的极少数链路,因其恒定速率无法利用空闲资源且实现更复杂。

直接说结论:在 PHP 实现 API 网关限流时,令牌桶 更适合大多数业务场景,漏桶 仅在极少数强稳定性要求的链路中值得考虑;两者都必须用 Redis + Lua 原子脚本实现,纯 PHP 内存计数或简单 INCR 会出竞态问题。
为什么不能只用 Redis INCR/DECR 做令牌桶
很多人一上来就写 INCR rate_limit:uid:api + EXPIRE,以为这就叫令牌桶——其实这只是固定窗口计数器,不是令牌桶。它完全没实现“按时间匀速补令牌”这个核心逻辑,会导致两个严重问题:
- 突发流量被一刀切:用户本该允许短时 50 QPS(桶容量 100、填充速率 10/s),但固定窗口会在整点瞬间清零,造成误拒
- 时间漂移误差大:不同请求触发
EXPIRE的时间点不一致,窗口实际长度浮动,尤其在低频请求下可能拉长到几分钟 - 无法支持付费等级差异化:固定窗口没法动态算“已过去多久、该补几个令牌”,而付费用户需要的是
capacity=200, refill_rate=20/s这类参数组合
真正令牌桶必须包含时间戳状态和线性补发逻辑,而这只能靠 Lua 脚本在 Redis 服务端原子执行。
漏桶算法在 PHP 网关里几乎没实用价值
漏桶 听起来很稳,但它的“恒定漏水速率”在真实 API 网关中是反直觉的。比如你配置了“每秒漏 10 个”,那无论当前系统负载是 10% 还是 90%,它都强制只放行 10 个请求——这等于主动放弃空闲资源,还让前端等待队列无限堆积。
- 它无法感知后端真实处理能力,不适合 PHP-FPM 或 Swoole 这类弹性工作进程模型
- Redis 实现时需维护一个有序时间戳列表(
LRANGE+LPUSH+LRIM),比令牌桶多 2 次网络往返,在高并发下延迟更敏感 - 所有开源 PHP 网关插件(如 Kong 的 PHP 日志处理器、Laravel Sanctum 扩展)默认都不提供漏桶选项,文档里也基本不提
除非你在做金融级清算接口,且明确要求“任何情况下每秒最多处理 N 笔、绝不允许抖动”,否则别碰 漏桶。
PHP 调用令牌桶 Lua 脚本的最小可行代码
这是生产环境验证过的精简版,去掉框架封装,直连 Redis 执行:
/* bucket.lua */
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local refill_rate = tonumber(ARGV[2]) -- tokens per second
local now = tonumber(ARGV[3])
<p>local data = redis.call("HMGET", key, "tokens", "last_refill")
local tokens = tonumber(data[1]) or capacity
local last_refill = tonumber(data[2]) or now</p><p>-- 计算应补充令牌数
local elapsed = now - last_refill
local new_tokens = math.floor(elapsed * refill_rate)
tokens = math.min(capacity, tokens + new_tokens)</p><p>-- 尝试消费
if tokens >= 1 then
tokens = tokens - 1
redis.call("HMSET", key, "tokens", tokens, "last_refill", now)
return 1
else
return 0
end</p>
PHP 侧调用:
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$script = file_get_contents('bucket.lua');
$sha = $redis->script('load', $script);
<p>// 用户ID + 接口路径构成唯一键
$key = 'rate_limit:uid_123:POST:/v1/order';
$capacity = 100;
$refill_rate = 10; // 10 tokens/sec
$now = time();</p><p>$result = $redis->evalsha($sha, [$key], [$capacity, $refill_rate, $now]);
if ($result === 0) {
http_response_code(429);
exit('{"error":"rate limited"}');
}</p>
注意:$key 必须带用户标识(如 uid、api_key 或 client_ip),不能只用接口路径,否则变成全局限流,会误伤合法用户。
滑动窗口日志其实是更现实的备选方案
如果你发现 Lua 脚本维护成本高、团队不熟悉,或者限流维度特别细(比如“每个用户每分钟对 /search 接口的前 5 个关键词各限 10 次”),那直接上 Sorted Set 滑动窗口反而更稳:
- 用
ZADD sliding_log:{uid}:{path} {timestamp} {req_id}记录每次请求 - 用
ZCOUNT查now-60到now区间内数量 - 用
ZREMRANGEBYSCORE清理过期项,避免内存膨胀 - 不用算时间差、不依赖 Lua,Redis 原生命令全支持,调试也直观
它比令牌桶多占一点内存,但精度更高、无时间漂移、天然支持任意粒度窗口(如 15 秒、3 分钟),很多中小厂 API 网关实际跑的就是这个。
真正容易被忽略的点是:限流键的设计必须和认证层强绑定。如果认证用的是 JWT 里的 sub 字段,但限流键却用 $_SERVER['REMOTE_ADDR'],那一个代理 IP 下所有用户就会互相拖累——这种错配比算法选型错误更致命。
大量免费API接口:立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游,为数据API应用能力赋能!











