设为首页收藏本站

LinuxTone | 运维专家网论坛 - 最棒的Linux运维与开源架构技术交流社区!

 找回密码
 注册

QQ登录

只需一步,快速开始

#公告#抱歉,网站将关闭,不再开放。由于PC时代已远逝 。在这个后移动互联网时代,我们继续携手前行,保持对技术的热情。共同构建linuxtone知识星球欢迎加入,一起讨论技术、招聘人才、分享资源。请新老linuxtone人 扫码移步到 知识星球:linuxtone

学习是一种信仰!分享是一种快乐!能力= 心态 * 沟通 * 知识 (你的每一天需要正能量!)

 网站的发展需要你贡献一份力量!希望你能每天坚持看贴1小时,并回答网友的问题!祝你在浏览论坛的过程中取得进步!谢谢!linuxtone加油!大家加油! 友情提示: 你今天学习了吗?你今天进步了吗?少一点抱怨!多一点进步!Life is short ! Why not linuxtone ?  

网站的发展、感谢每位坛友的努力!

查看: 9796|回复: 0

[nginx 反向代理] 关于nginx的重试机制的疑问 [复制链接]

Rank: 6Rank: 6

签到
156
注册时间
2011-2-22
最后登录
2017-4-27
在线时间
161 小时
阅读权限
70
积分
9147
帖子
293
主题
121
精华
0
UID
12099
发表于 2016-2-1 23:22:01 |显示全部楼层
本帖最后由 qiuzugen 于 2016-2-1 23:24 编辑

我负责的服务,架构如下:http服务通过nginx(n台服务器)代理到后台的若干个cgi(n台服务器), 其中,某个cgi(这里我命名为A)又调用了底层的某个服务B。

近日,服务B变更引起大量失败,返回给A,A报错,也返回大量失败,返回500和502给nginx层,同时cgi层的服务器负载彪的很高,影响了机器上其他的cgi,顿时服务逐渐不可用,用户投诉过来了。

分析:故障时,cgi的机器负载直接飙到了接近200,cpu近100%,查看是A耗cpu导致,而且前面一层的nginx机器有被负载均衡踢掉的告警,我们把矛头指向了nginx的重试机制,因为我们的配置是:
upstream server_upstream{
                server 10.111.111.111:8080 weight=10 max_fails=3 fail_timeout=3s;
                server 10.222.222.222:8080 weight=10 max_fails=3 fail_timeout=3s;
                server 10.333.333.333:8080 weight=10 max_fails=3 fail_timeout=3s;
                server 10.444.444.444:8080 weight=10 max_fails=3 fail_timeout=3s;
                ...
}(一共32台机器)
同时,没有配置proxy_next_upstream_tries参数。这样的话,意思是(大家看我理解的对不对):由于proxy_next_upstream_tries默认值是0,表示对重试不做限制,所以这里会一直重试下去,在底层服务不可用的情况下,重试到cgi层,把cgi机器搞死。

然后,就着手改进配置,准备对配置做2点改进:
1.配置proxy_next_upstream_tries 1,即只重试一次
2. max_fails这个到底该怎么配置,我纠结了,不明白了(详细困惑见下文)。

于是乎,查nginx官方文档:
对max_fails和fail_timeout的解释如下:
max_fails=number
sets the number of unsuccessful attempts to communicate with the server that should happen in the duration set by the fail_timeout parameter to consider the server unavailable for a duration also set by the fail_timeout parameter. By default, the number of unsuccessful attempts is set to 1. The zero value disables the accounting of attempts. What is considered an unsuccessful attempt is defined by the proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, and memcached_next_upstream directives.
fail_timeout=time
sets
1)the time during which the specified number of unsuccessful attempts to communicate with the server should happen to consider the server unavailable;
2)and the period of time the server will be considered unavailable.
By default, the parameter is set to 10 seconds.

对proxy_next_upstream_tries 的解释如下:
Syntax:        proxy_next_upstream_tries number;
Default:       
proxy_next_upstream_tries 0;
Context:        stream, server
Limits the number of possible tries for passing a connection to the next server. The 0 value turns off this limitation.

这里细细推敲之后,我的疑问是:
1.按照官网的解释,"sets the number of unsuccessful attempts to communicate with the server",max_fails也是重试的意思吗?我的服务在短时间内每台都去重试了3次导致负载升高吗?
2.重试proxy_next_upstream_tries和attempts到底有什么区别,我咋感觉max_fails也是活生生的重试呢?这里我到底有没有必要把max_fails去掉?(默认是1)
3.按照官网的解释,proxy_next_upstream_tries 配置成1的话,是每台都去重试一次呢还是从所有的upstream里面随机的选择一台去重试一次?如果是配置成3的话,是每台都重试3次呢还是选3台进行重试(这句话我越读越觉得是每台都会重试3次:Limits the number of possible tries for passing a connection to the next server,因为它说是the next server啊!),如果是选3台的话,每台也是重试3次?
4.跟同事讨论了下,这里max_fails的attempts和重试可能不一样:attempts是正常请求,是用来自用户的正常请求来探测后端服务可不可用(每次的请求不一样),而重试是用同样的请求去访问后端服务,进一步来想:当nginx选到某台机器进行重试的时候,到达这台机器的请求肯定是重试的请求吧,正常的请求肯定是排在这个重试请求的后面,这样一来,看来max_fails还是挺危险的,还是得把max_fails参数去掉或改成1?

这两个参数折腾我好几天了,睡不好觉,哪位nginx高手帮忙解答下我的疑问,谢谢~

附:nginx官网对以上2个参数的解释:
http://nginx.org/en/docs/stream/ ... proxy_next_upstream
http://nginx.org/en/docs/http/ng ... odule.html#upstream

该贴已经同步到 qiuzugen的微博
您需要登录后才可以回帖 登录 | 注册

IT运维专家网感谢您的支持

合作联系: QQ:67888954/MSN:cnseek@msn.com/mail:netseek@linuxtone.org

Archiver|手机版|感谢所有关心和支持过LinuxTone的朋友们 转载本站内容请注明原作者名及出处 ( 京ICP备08103151 )   |

GMT+8, 2019-8-24 13:39 , Processed in 0.021057 second(s), 14 queries , Apc On.

Powered by Discuz! X2 Licensed

© 2001-2011 Comsenz Inc.

回顶部