openresty 回源频率如何控制

hsl4235

我在使用openresty做的proxycache，但是经常遇到一种情况，当后端源站的带宽拥堵的时候，下载速率下降，openresty会不断的向后端源站发起请求，随着链接后端的个数越来越多，带宽也越来越大，直到把源站打死，我觉得应该是nginx的回源机制导致的这种情况，请问下我的判断正确吗？

hsl4235

proxy_next_upstream_tries ;

Limits the number of possible tries for passing a request to the next server. The 0 value turns off this limitation.

我一开始的理解是这个配置默认是0 也就是取消限制的意思，如果在prxoy_read timeout 来临之前，会不断的重试后端，从而造成这种下游的血崩，但是在跟春哥沟通过程中，他指出其实跟这个参数没有太大关系。

所以我这里有个疑问，应该如何做后端的频控和并发控制呢？尤其是像做CDN 的方向。

先谢谢各位的关注了。

在 2017年6月14日星期三 UTC+8上午1:39:38，韩世林写道：

我在使用openresty做的proxycache，但是经常遇到一种情况，当后端源站的带宽拥堵的时候，下载速率下降，openresty会不断的向后端源站发起请求，随着链接后端的个数越来越多，带宽也越来越大，直到把源站打死，我觉得应该是nginx的回源机制导致的这种情况，请问下我的判断正确吗？

hsl4235

从现象上来看，当源站带宽拥堵，下载速率下降到很低的时候，同一个文件回源请求，会被不停的向源站发起重复的请求。

在 2017年6月14日星期三 UTC+8上午1:44:13，韩世林写道：

proxy_next_upstream_tries number;
Limits the number of possible tries for passing a request to the next server. The 0 value turns off this limitation.

我一开始的理解是这个配置默认是0 也就是取消限制的意思，如果在prxoy_read timeout 来临之前，会不断的重试后端，从而造成这种下游的血崩，但是在跟春哥沟通过程中，他指出其实跟这个参数没有太大关系。
所以我这里有个疑问，应该如何做后端的频控和并发控制呢？尤其是像做CDN 的方向。
先谢谢各位的关注了。

在 2017年6月14日星期三 UTC+8上午1:39:38，韩世林写道：
我在使用openresty做的proxycache，但是经常遇到一种情况，当后端源站的带宽拥堵的时候，下载速率下降，openresty会不断的向后端源站发起请求，随着链接后端的个数越来越多，带宽也越来越大，直到把源站打死，我觉得应该是nginx的回源机制导致的这种情况，请问下我的判断正确吗？