相关组件：
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表示server如果发生一次失败（超时或者拒绝连接）则将该server剔除出去，不再向其分发请求。fail_timeout表示多少秒后恢复服务。
如下例子：
?这表示，如果webservice中的server发生一次超时，就停止服务2分钟。2分钟以后再恢复服务。
?
原文：http://yunjianfei.iteye.com/blog/2265918