如何通过Nginx与Redis协同,在集群中实施高效的全局访问频率控制?
- 内容介绍
- 文章标签
- 相关推荐
本文共计993个文字,预计阅读时间需要4分钟。
使用Nginx自带的limit_req模块无法在集群环境下实现全局频率限制,因为它依赖于本地的共享内存(zone)。各节点计数统计彼此隔离。
要跨多台Nginx实现统一IP的请求频率限制,必须引入外部集中式存储——最常用且可靠的选择是Redis。
核心思路是:
关键组件准备
确保以下三项已就绪:
-
Nginx + OpenResty:需编译或安装
ngx_http_lua_module,推荐使用 OpenResty(已集成 Lua 和常用库); - Redis 集群或高可用实例:建议使用 Redis Sentinel 或 Redis Cluster,避免单点故障;若流量不大,单节点 Redis 也可起步;
-
Lua Redis 客户端:使用
resty.redis(OpenResty 内置),支持连接池、超时控制和 keepalive,不建议用阻塞式 redis.lua。
Redis 数据结构设计
采用轻量、高效、可过期的 key-value 结构,避免复杂命令影响性能:
-
访问计数 key:
req:ip:${binary_remote_addr},值为整数(如12),设置 TTL(如 60 秒); -
黑名单 key:
block:ip:${binary_remote_addr},值为1,TTL 设为封禁时长(如 300 秒); - 不使用有序集合(ZSET)或哈希(HASH),除非需按时间窗口滑动统计(如“最近 60 秒内请求数”),那会增加 Redis 压力和 Lua 复杂度。
Lua 脚本逻辑要点
脚本应放在 access_by_lua_file 阶段(即 access 阶段),确保在请求被代理前完成鉴权判断。典型流程如下:
- 先查
block:ip:xxx,命中则直接ngx.exit(403); - 再对
req:ip:xxx执行INCR,若返回值为 1,立即EXPIRE设置过期时间; - 若 INCR 后值 > 阈值(如 100),则
SET黑名单 key 并设 TTL,再退出; - 务必调用
set_keepalive归还连接到连接池,防止连接耗尽; - 所有 Redis 错误(连接失败、超时)应降级处理(如记录 error 日志但放行),避免因 Redis 不可用导致全站 500。
Nginx 配置示例
在 http 块中声明 Lua 路径和日志级别:
lua_package_path "/usr/local/openresty/lualib/?.lua;;";
lua_shared_dict ip_limit_cache 10m;
error_log /usr/local/openresty/nginx/logs/access_limit.log warn;
在 location 中启用脚本:
location /api/ {
access_by_lua_file /usr/local/openresty/nginx/lua/ip_rate_limit.lua;
proxy_pass http://backend;
}
注意:不要在 server 级别全局启用,应按业务路径精细化控制(如仅限 /login、/sms 等敏感接口)。
生产环境注意事项
真实部署时容易忽略但影响极大的细节:
-
IP 获取准确性:务必用
$binary_remote_addr(二进制格式节省内存),并配合real_ip_header和set_real_ip_from正确识别经由 CDN 或 LB 转发的真实客户端 IP; -
连接池配置:在 Lua 脚本中设置合理的
set_keepalive(max_idle_time, pool_size),例如10000, 100,避免频繁建连; -
阈值分级:可结合
map指令区分普通用户、爬虫、内部系统,分配不同限频策略,例如:
map $http_user_agent $rate_limit_key {
default $binary_remote_addr;
~*curl $binary_remote_addr"_curl";
~*bot $binary_remote_addr"_bot";
} -
监控与告警:定期从 Redis 抽取高频 IP(
KEYS req:ip:*+GET)生成报表,或用redis-cli --scan --pattern "req:ip:*" | xargs -n 1 redis-cli get快速排查;对封禁量突增设置 Prometheus + Alertmanager 告警。
本文共计993个文字,预计阅读时间需要4分钟。
使用Nginx自带的limit_req模块无法在集群环境下实现全局频率限制,因为它依赖于本地的共享内存(zone)。各节点计数统计彼此隔离。
要跨多台Nginx实现统一IP的请求频率限制,必须引入外部集中式存储——最常用且可靠的选择是Redis。
核心思路是:
关键组件准备
确保以下三项已就绪:
-
Nginx + OpenResty:需编译或安装
ngx_http_lua_module,推荐使用 OpenResty(已集成 Lua 和常用库); - Redis 集群或高可用实例:建议使用 Redis Sentinel 或 Redis Cluster,避免单点故障;若流量不大,单节点 Redis 也可起步;
-
Lua Redis 客户端:使用
resty.redis(OpenResty 内置),支持连接池、超时控制和 keepalive,不建议用阻塞式 redis.lua。
Redis 数据结构设计
采用轻量、高效、可过期的 key-value 结构,避免复杂命令影响性能:
-
访问计数 key:
req:ip:${binary_remote_addr},值为整数(如12),设置 TTL(如 60 秒); -
黑名单 key:
block:ip:${binary_remote_addr},值为1,TTL 设为封禁时长(如 300 秒); - 不使用有序集合(ZSET)或哈希(HASH),除非需按时间窗口滑动统计(如“最近 60 秒内请求数”),那会增加 Redis 压力和 Lua 复杂度。
Lua 脚本逻辑要点
脚本应放在 access_by_lua_file 阶段(即 access 阶段),确保在请求被代理前完成鉴权判断。典型流程如下:
- 先查
block:ip:xxx,命中则直接ngx.exit(403); - 再对
req:ip:xxx执行INCR,若返回值为 1,立即EXPIRE设置过期时间; - 若 INCR 后值 > 阈值(如 100),则
SET黑名单 key 并设 TTL,再退出; - 务必调用
set_keepalive归还连接到连接池,防止连接耗尽; - 所有 Redis 错误(连接失败、超时)应降级处理(如记录 error 日志但放行),避免因 Redis 不可用导致全站 500。
Nginx 配置示例
在 http 块中声明 Lua 路径和日志级别:
lua_package_path "/usr/local/openresty/lualib/?.lua;;";
lua_shared_dict ip_limit_cache 10m;
error_log /usr/local/openresty/nginx/logs/access_limit.log warn;
在 location 中启用脚本:
location /api/ {
access_by_lua_file /usr/local/openresty/nginx/lua/ip_rate_limit.lua;
proxy_pass http://backend;
}
注意:不要在 server 级别全局启用,应按业务路径精细化控制(如仅限 /login、/sms 等敏感接口)。
生产环境注意事项
真实部署时容易忽略但影响极大的细节:
-
IP 获取准确性:务必用
$binary_remote_addr(二进制格式节省内存),并配合real_ip_header和set_real_ip_from正确识别经由 CDN 或 LB 转发的真实客户端 IP; -
连接池配置:在 Lua 脚本中设置合理的
set_keepalive(max_idle_time, pool_size),例如10000, 100,避免频繁建连; -
阈值分级:可结合
map指令区分普通用户、爬虫、内部系统,分配不同限频策略,例如:
map $http_user_agent $rate_limit_key {
default $binary_remote_addr;
~*curl $binary_remote_addr"_curl";
~*bot $binary_remote_addr"_bot";
} -
监控与告警:定期从 Redis 抽取高频 IP(
KEYS req:ip:*+GET)生成报表,或用redis-cli --scan --pattern "req:ip:*" | xargs -n 1 redis-cli get快速排查;对封禁量突增设置 Prometheus + Alertmanager 告警。

