欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

记录:解决后端server因一个timeout导致的雪崩

程序员文章站 2022-03-07 12:28:54
...

问题描述

相关组件:

1. WebService:对外提供web接口服务,这里启动了5个(端口分别为:9001-9005)

2. nginx:反向代理5个webService做负载均衡(nginx对外提供9999端口服务)

3. httpclient:调用nginx的9999端口访问webService提供的http接口

 

timeout设置:

nginx:proxy_read_timeout 设置成了100s

httpclient:timeout默认20s

 

业务逻辑:

1. httpclient通过nginx的9999端口,调用webservice提供的接口,获取返回的结果,并进行处理。

2. httpclient发生超时时,会自动进行retry,再次调用webService接口。

3. httpclient有多个,用于不同的外部服务

 

问题复现:

1. 其中一个httpclient调用了webService的一个查询接口(假设对1000万条记录进行全表扫描),执行这个查询的时间远大于30s

2. httpclient在20s时没有收到webService的返回,发生timeout,进行自动retry,再次调用webservice的接口

3. 每次retry被nginx分发到不同的webservice(9001-9005)上去执行,每个webService都被全表扫描阻塞。多次retry后,直接导致所有的webService因为这个请求而阻塞,所有httpclient发送来的请求都超时、retry,陷入恶性循环,雪崩发生。

4. httpclient的超时设置是20s,但是nginx设置的 proxy_read_timeout 为100s,假设 webservice在40s的时候完成查询,并通过nginx返回了结果。但是此时httpclient已经在20s的时候就超时结束了,导致webservice返回的结果并没有收到。

 

问题分析

这里有三个问题:

1. httpclient超时后,一直retry,nginx会把请求分发到后端的所有webservice里,导致所有webservice全都       去执行全表扫描,无法再对外服务。

2. httpclient的超时设置和nginx的超时设置不一致,导致nginx返回了结果,但是httpclient却始终无法接收      到。

3. webservice被一个全表扫描的请求阻塞时,并没有被nginx的upstream策略剔除,会有新的请求分配到这个webservice,导致新的请求也timeout。

 

 

问题解决

对于三个问题,分别的解决方式如下:

 

1. 对于可能执行全表扫描这种危险操作的请求,通过添加索引等方式进行优化,缩短查询时间,并且禁止进行retry。

 

2. 将proxy_read_timeout设置成19秒(也就是小于等于httpclient的超时时间),保证超时的统一性。避免httpclient超时,而nginx还没有超时的情况。

 

3. nginx有max_fails和fail_timeout两个设置,max_fails=1 fail_timeout=120s; 表示server如果在120s内发生一次失败(超时或者拒绝连接)则将该server剔除出去,不再向其分发请求,120秒后再恢复服务。

如下例子:

upstream webService {
server 127.0.0.1:9001 max_fails=1 fail_timeout=120s;
server 127.0.0.1:9002 max_fails=1 fail_timeout=120s;
server 127.0.0.1:9003 max_fails=1 fail_timeout=120s;
}

 这表示,如果webservice中的server发生一次超时,就停止服务2分钟。2分钟以后再恢复服务。