nginx_限流配置(redis实现限流)

生活 0 530

Nginx来限制访问控制的方法有多种,nginx主要有2个模块控制,但是那些不支持自定义,非常死,在大多数场景下并不实用。今天分享一个:利用openresty+lua+redis 实现封杀频繁恶意访问IP地址,当然这个方式也是有弊端的,那就是不断试用代理 IP之类的,但是作用还是有的,起码提高了恶意的成本。

nginx的版本有淘宝nginx,还有春哥的 openresty,但是openresty打包了 nginx 的时候,集成了很多的有用的扩展,特别是 lua,一个小巧的编程语言。本文就是:openresty最新稳定版本+lua Lua +redis最新稳定版本 。

具体环境我就不安装了,大家可以使用宝塔面板啥的安装openresty,如果你的原生态的nginx就需要手动安装,网上教程都是有的,也比较简单。

nginx_限流配置(redis实现限流)

lua脚本

ip_bind_time =3600 --封禁IP多长时间,单位秒

ip_time_out = 2 --指定统计ip访问频率时间范围,秒

connect_count = 5 --指定ip访问频率计数最大值,秒

--上面的意思就是2秒内访问超过5次,自动封 IP 60分钟。

--连接redis

local redis = require "resty.redis"

local cache = redis.new()

local ok , err = cache.connect(cache,"127.0.0.1","6379")

cache:set_timeout(60000)

cache:auth("1234") -- redis密码

--如果连接失败,跳转到脚本结尾

if not ok then

goto Lastend

--查询ip是否在封禁段内,若在则返回403错误代码

--因封禁时间会大于ip记录时间,故此处不对ip时间key和计数key做处理

local is_bind , err = cache:get("bind_"..ngx.var.remote_addr)

if is_bind == '1' then

ngx.exit(ngx.HTTP_FORBIDDEN)

-- 或者 ngx.exit(403)

-- 当然,你也可以返回500错误啥的,搞一个500页面,提示,亲您访问太频繁啥的。

goto Lastend

local start_time , err = cache:get("time_"..ngx.var.remote_addr)

local ip_count , err = cache:get("count_"..ngx.var.remote_addr)

--如果ip记录时间大于指定时间间隔或者记录时间或者不存在ip时间key则重置时间key和计数key

--如果ip时间key小于时间间隔,则ip计数+1,且如果ip计数大于ip频率计数,则设置ip的封禁key为1

--同时设置封禁key的过期时间为封禁ip的时间

if start_time == ngx.null or os.time() - start_time > ip_time_out then

res , err = cache:set("time_"..ngx.var.remote_addr , os.time())

res , err = cache:set("count_"..ngx.var.remote_addr , 1)

res , err = cache:expire("time_"..ngx.var.remote_addr,ip_bind_time)

res , err = cache:expire("count_"..ngx.var.remote_addr,ip_bind_time)

ip_count = ip_count + 1

res , err = cache:incr("count_"..ngx.var.remote_addr)

if ip_count >= connect_count then

res , err = cache:set("bind_"..ngx.var.remote_addr,1)

res , err = cache:expire("bind_"..ngx.var.remote_addr,ip_bind_time) --fix keys

local ok, err = cache:close()

::Lastend::

openresty nginx配置:

做了个简单的反向代理, 本机8888端口下发login请求,转发到项目实际登录接口

access_by_lua_file配置导入lua脚本

效果:刷新五次后403并封IP, 频率和时间都是在脚本中设置

redis数据: 局限性

限流组件保证了高可用,牺牲了性能,增加了一层 IO 环节的开销,单机限流在本地,分布式限流还要通过网络协议。限流组件保证了高可用,牺牲了一致性,在大流量的情况下,请求的处理会出现延迟的情况,这种场景便无法保证强一致性。特殊情况下,还无法保证最终一致性,部分请求直接被抛弃。限流组件拥有流控权,若限流组件挂了,会引起雪崩效应,导致请求与业务的大批量失败。

引入限流组件,增加系统的复杂程度,开发难度增加,限流中间件的设计本身就是一个复杂的体系,需要综合业务与技术去思考与权衡,同时还要确保限流组件本身的高可用与性能,极大增加工作量,甚至需要一个团队去专门开发。

相关推荐: