欢迎访问我的博客,你的支持,是我最大的动力!

nginx知识点:限流与重试策略、健康检查、长连接

Linux 小马奔腾 100℃ 评论
目录:
[显示]

记录日常工作中遇到的坑~~

ngx_http_limit_req_module 限流

nginx做为网关,限流能力是一项必备的能力,在面对突发大流量时,为保护后端服务和DB不被突然出现的流量洪峰冲垮,对请求实施限流,可能是一项有效的止血方案。限流对业务是有损的,因为它意味着丢弃部分请求,而只允许请求以允许的速率请求到后端,所以,通常情况下,限流只做为一项应急处置手段来使用。

限流通常会和降级配合使用,在微服务中这一块现在比较热,不过nginx做为网关层,会简单粗暴得多,nginx的限流通常直接返回特定的状态码,比如429,没有优雅的降级,降级则由客户端来处理了。

ngx_http_limt_req_module 的文档地址:http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req

使用比较简单,但也有需要注意的坑。

对uri实施限流

官方文档中的配置示例是对特定来源的ip进行访问限流的

limit_req_zone $binary_remote_addr zone=perip:10m rate=1r/s;

在实际使用中,往往不会对来源ip进行限速,一个是若有多层网关,来源的ip并不能代表用户的真实ip,另外,就是也不太适合精确控制应用的总请求速率,所以,采用$uri来做为限速。

重要的 burst

使用limit_req限速时,一定要加上burst参数,否则会产生误差,实际值会低于目标值,且没有规率性

如果是不使用burst时的限流效果:

可以看到,实际的限流效果会有较大的偏差,并且,随着限流流量的加大,偏差也越来越大。解决办法就是需要使用burst参数,在网上找到一段话,大致说出了原因:

Yes, the module is limited by millisecond timer resolution, but using so high rate values without the burst parameter is meaningless.

上面这段话来自:https://www.ruby-forum.com/t/possible-limitation-of-ngx-http-limit-req-module/241917

配置示例

nginx ngx_http_limit_req_module 讲解
https://www.freecodecamp.org/news/nginx-rate-limiting-in-a-nutshell-128fe9e0126c/
https://www.nginx.com/blog/rate-limiting-nginx/

proxy_next_upstream 重试机制

ngx_http_proxy_module 是nginx的核心模块,里面有个指令是 proxy_next_upstream 一般如果没有显式配置过的话,它会有一个默认值:

proxy_next_upstream error timeout;

这个指令的意思是,在发生连接错误(建立连接、传递请求或者在读响应头)时,或者在后端超时时,会发起重试请求。

这个默认行为可能并不是我们期望的,特别是超时重试这个,在遇到比较慢的后端时,会造成同一个请求多次请求到后端,这就会有两个后果,一个是如果接口不是幂等的,会产生脏数据,影响到数据的准确性;产生超时一般就是后端响应太慢,间接说明该请求非常消耗资源,这时,在第一个请求还没有计算出结果时,又重复发起第二个相同的请求,势必造成后端压力,在极端情况下,因为请求放大,甚至后端会被打挂

所以,必须关闭超时时产生的重试,发生错误时产生的重试往往可以保留,它有一定的益处。还需要注意一点,就是,如果是多级代理,在设置每一层的超时时间时,必须要有梯度,如果都设置成相同的超时时间,如600秒(proxy_read_timeout 600;),那么必然会产生重试。

建议的配置:

既然网关重试不是我们所希望的结果,那么如何从日志中发现当前网关是否发生过重试呢?
实际上,如下日志片段 ,upstream_addr中会出现多个后端ip(一个请求的最大重试次数小于等于upstream中的server数),request_time异常大,upstream_response_time中也会有每次重试的响应时间

# 发生重试的日志片段
"upstream_addr":"172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80, 172.16.xx.xxx:80",
"request_time":"5100.769",
"upstream_response_time":"300.001, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 300.000, 0.769",

upstream server 的主动健康检查和被动健康检查

在配置upstream时,server里面有一个参数 max_fails 用于控制被动健康检查,max_fails的默认值是1,即被动健康检查默认是开启的。如果需要关闭,需要显试的设置其值为0。

当在fail_timeout(默认为10秒)时间内,如果标识server unavailable的请求次数达到max_fails的值,那么后端服务会暂时从upstream中下掉,即会下线服务节点。而被认可为fails的请求是由 proxy_next_upstream这类指令配置的,proxy_next_upstream默认是 error和timeout,注意这个timeout,也就是说,在后端某个接口响应非常慢的情况下,会会导致该后端server从upstream中下线,情况严重一点会使整个upstream中服务器全部下掉!这就非常严重了,相当于可以由一个特别慢的接口拉挂整个服务。如果这个服务是单个服务还好,如果upstream里是下一层网关,那后果就更加严重,相当于整个代理全挂。

所以可靠的作法就是关闭被动健康检查,即设置max_fails=0,但这又会导致某个节点异常下线,无法被nginx感知到,那么解法是再配合主动健康检查

主动健康检查就是周期性的由nginx发起探针请求到后端,通过请求结果判断后端是否是存活的,这需要用到模块 ngx_http_upstream_check_module 文档在此
这是tengine里面的一个模块,还是很有用的,语法如下:

keepalive 后端长连接

最后说一下keepalive,后端服务使用长连接可以减少频繁创建连接,增加性能,但需要注意,长链接需要相应的在location中配置 proxy_http_version 1.1; 和 proxy_set_header Connection ""; 才会生效,而如果有10个location是到这个upstream的,必须这10个location全部配置才有用,因为长连接会被打断,即在连接的复用过程中,只要有一个请求来至于没有配置前面那两个指令,这个请求结果后,这个长连接也就被释放了,通过抓包可以很清楚的看到这一点。其他倒还好

 

 

 

转载请注明:轻风博客 » nginx知识点:限流与重试策略、健康检查、长连接

喜欢 (3)or分享 (0)