令牌桶更适合大多数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免费学习笔记（深入）”；
- 它无法感知后端真实处理能力，不适合 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
endPHP 侧调用：
$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"}');
}注意：$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 下所有用户就会互相拖累——这种错配比算法选型错误更致命。
