真实线上限流必须用滑动窗口+可信IP提取+Lua原子脚本:固定窗口会在整点突增流量导致计数失效;REMOTE_ADDR易被代理污染,需按X-Real-IP/X-Forwarded-For顺序校验;Redis多命令非原子,须用Lua封装ZSET滑动窗口逻辑。

PHP API 限流不能只靠 $_SERVER['REMOTE_ADDR'] + Redis::incr() 就完事——高并发下会丢计数、IP 会被代理头污染、固定窗口会在整点突增流量,真实线上必须用滑动窗口 + 可信 IP 提取 + Lua 原子脚本。
为什么固定窗口限流在生产环境容易失效
固定窗口(比如“每分钟最多 60 次”)看似简单,但实际会在时间边界处放大风险:用户在第 59 秒发起 60 次请求,又在第 0 秒发起 60 次,等于瞬间 120 次。后端没感知到压力突变,数据库连接池直接打满。
常见错误现象包括:
- 监控显示 QPS 突增一倍,但 Redis 计数器没超阈值
- 同一 IP 下多个登录用户互相干扰(
rate_limit:1.2.3.4键太粗) - 限流日志里大量
429出现在整点前后,非业务高峰时段
解决方案是改用滑动窗口,核心是用 ZSET 存时间戳,每次请求执行 ZCOUNT 统计当前窗口内请求数。但注意:ZADD 和 ZREMRANGEBYSCORE 必须原子执行,否则并发时可能漏删旧数据——必须封装进 Lua 脚本。
如何正确提取客户端真实 IP
$_SERVER['REMOTE_ADDR'] 在有 Nginx、CDN 或负载均衡的架构下,几乎总是内网地址(如 10.0.1.5 或 127.0.0.1),直接拿它限流等于失效。
必须按顺序检查可信代理头:
- 优先读
$_SERVER['HTTP_X_REAL_IP'](需 Nginx 配置proxy_set_header X-Real-IP $remote_addr;) - fallback 到
$_SERVER['HTTP_X_FORWARDED_FOR']的第一个非私有地址(过滤掉127.0.0.1、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) - 绝不能信任未校验的
X-Forwarded-For—— 攻击者可伪造为任意 IP
示例判断逻辑(不依赖第三方库):
$ip = $_SERVER['REMOTE_ADDR'];
if (!empty($_SERVER['HTTP_X_REAL_IP'])) {
$ip = $_SERVER['HTTP_X_REAL_IP'];
} elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
$ips = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
foreach ($ips as $candidate) {
$candidate = trim($candidate);
if (!filter_var($candidate, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
continue;
}
$ip = $candidate;
break;
}
}
Redis 滑动窗口必须用 Lua 脚本保证原子性
PHP Redis 扩展的 zAdd() + zRemRangeByScore() + zCard() 是三个独立命令,中间可能被其他请求插入,导致计数偏高或过期清理失败。
正确做法是把整个滑动窗口逻辑写进 Lua 脚本,通过 EVAL 一次性提交。例如限制「最近 60 秒最多 100 次」:
local key = KEYS[1]
local window = tonumber(ARGV[1])
local max = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
<p>-- 清理过期时间戳
redis.call('zremrangebyscore', key, 0, now - window)
-- 添加当前时间戳
redis.call('zadd', key, now, now)
-- 设置过期(防止 key 永久残留)
redis.call('expire', key, window + 10)
-- 获取当前窗口内请求数
local count = redis.call('zcard', key)</p><p>if count > max then
return {0, count}
else
return {1, count}
end</p>
PHP 中调用:
$result = $redis->eval($lua_script, 1, $key, $window, $max_requests, time());
list($allowed, $current_count) = $result;
if (!$allowed) {
http_response_code(429);
header('Retry-After: 1');
echo json_encode(['error' => 'Too many requests']);
exit;
}
限流响应要带 Retry-After 且异步记录日志
返回 429 Too Many Requests 时,必须设置 Retry-After 响应头,告诉客户端多久后可重试。固定窗口可设为窗口剩余秒数;滑动窗口建议统一设为 1 秒(因窗口是滚动的,精确值难算)。
更关键的是日志记录:别在限流判断后、echo 前直接 file_put_contents(),I/O 会拖慢所有放行请求。正确姿势是:
- 限流检查(Redis 操作)必须同步完成,决定是否放行
- 放行后立即调用
fastcgi_finish_request(),让 Web Server 关闭连接 - 再执行日志写入、监控上报等耗时操作,不影响用户响应时间
容易被忽略的一点:限流键名设计要支持多级维度。例如 rate_limit:uid_123:api_v1_orders,而不是笼统的 rate_limit:1.2.3.4 —— 否则一个 IP 登录多个账号会互相锁死,VIP 用户也无法单独提额。
大量免费API接口:立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游,为数据API应用能力赋能!











