PHP API限流实现方法详解

本文深入解析了PHP API限流的实战方案，重点对比并详解了基于Redis的滑动窗口（高并发、分布式首选）与基于APCu的令牌桶（无Redis场景下的可靠替代）两种核心实现，直击开发者常踩的原子性缺失、key设计错误、时间切片偏差、多层限流冲突等痛点，并给出可直接落地的代码逻辑、键名规范、时间精度控制（强制使用microtime(true)而非$_SERVER['REQUEST_TIME_FLOAT']）及运维建议，助你构建既精准又健壮的API流量防线。

PHP中用Redis实现滑动窗口限流

直接用 redis 实现滑动窗口是 PHP API 限流最可控的方式，比基于时间戳文件或数据库计数快得多，也比 apcu 更适合分布式部署。关键不是“能不能做”，而是窗口粒度、键名设计和原子性怎么保。

常见错误是把整个请求路径当 key，导致不同用户共用计数；或者用 INCR + EXPIRE 两步操作，中间可能被并发打断。

• 用用户标识（如 $userId 或 $ip）+ 接口路径 + 时间戳区间拼接 key，例如 "rate:uid_123:/api/v1/orders:2024052014"
• 用 redis->eval() 执行 Lua 脚本，保证 INCR 和 EXPIRE 原子执行，脚本里判断是否超限并返回当前计数
• 窗口粒度建议按分钟或15秒切分，避免 KEYS 扫描——不要依赖过期自动清理，而是在 incr 前先用 SCAN 清理陈旧 key（低频维护任务）

用PHP内置函数实现简单令牌桶（无Redis场景）

没有 Redis 时，apcu 是唯一靠谱的本地缓存选择。opcache 不支持 TTL，file_put_contents 并发写会丢数据，别碰。

令牌桶逻辑本身不难，但 PHP-FPM 下每个 worker 进程独立内存，apcu 是进程间共享的，这点常被忽略，导致限流失效。

• 桶容量、填充速率、上次填充时间都存进 apcu，key 命名为 "token_bucket:{$ip}:{$endpoint}"
• 每次请求先读取当前状态，计算应补充的令牌数：min($capacity, $current + ($now - $last_fill) * $rate)
• 检查是否够用，够则扣减并更新 apcu；不够就拒绝，返回 429 和 Retry-After 头
• 注意 apcu_enabled() 必须为 true，且 apc.enable_cli=1（如果跑在 CLI 模式下测试）

为什么不要用 $_SERVER['REQUEST_TIME_FLOAT'] 做滑动窗口时间切片

$_SERVER['REQUEST_TIME_FLOAT'] 看似方便，但它依赖系统时钟，NTP 同步或虚拟机休眠会导致跳变，造成窗口错位甚至计数归零。

更糟的是，在 FPM 模式下，这个值是请求进入 FPM 队列的时间，不是真正到达 PHP 的时刻，误差可能达几十毫秒——对 1 秒级限流就是致命偏差。

• 一律改用 microtime(true) 获取当前精确时间
• 时间切片用向下取整：例如 15 秒窗口就用 floor(microtime(true) / 15)，而不是四舍五入
• 如果用 Redis，把时间戳作为 key 的一部分（如上文），不要存成 value 再比较，避免时区/精度转换问题

FastCGI / Nginx 层前置限流的坑

Nginx 的 limit_req 只能按 IP 或变量限流，没法区分登录用户；而且它在 PHP 执行前就拦截，无法结合业务逻辑（比如 VIP 用户放宽限制）。

更隐蔽的问题是：如果 PHP 层自己也限流，而 Nginx 把超限请求直接 503，PHP 根本收不到，日志里就看不到真实触发点，排查时会误判为“没生效”。

• 生产环境建议只选一层限流：Nginx 做粗粒度防护（防爬虫扫库），PHP 做细粒度控制（按用户角色、接口优先级）
• 若必须双层，让 Nginx 的 burst 设大些，把真正决策权交给 PHP，并在 PHP 中记录原始 Nginx 限流头（如 X-RateLimit-Limit）用于对齐
• 确认 fastcgi_ignore_client_abort off，否则客户端断连时 PHP 还在计数，导致后续请求被误拒

今天关于《PHP API限流实现方法详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！