dyn resolver 的超时问题

[taoyuanyuan]

学习了哥的代码实现. 发现如果dns服务器出现问题, 每次请求都要等resolver_timeout超时, 并且如果是 proxy_pass www.xxx.com dynamic_resolve; 这种形式, 就会导致服务失败了. 不知道理解的对不

我加了一个 proxy_dyn_resolve_fail_timeout 的变量, 在dns失败之后,这段时间就走原来的逻辑, 直接用启动时获取的ip地址, 这样在dns出问题的时候可以尽量提供服务..
哥帮忙review看下, 是否SEnginx加入类似容错机制
taoyuanyuan/tengine@1b801de

thx

[taoyuanyuan]

哥的测试用例太威武了!

[cfsego]

同上，非常佩服。

[InfoHunter]

Hello, github上没开邮件提醒，才看见这个issue，sorry.

我认为这是两个问题：

第一，proxy_dyn_resolve_fail_timeout的想法很好，但nginx的resolver是有对类似情况的处理的，它的做法是第一个request来了之后加红黑树结点，发dns包，加超时定时器。之后第二个request来了的时候如果在树上查到了结点，就会把ctx挂到结点的waiting队列上(rn->waiting)，而不会再发dns包和加定时器。如果第一个请求引发的dns包有应答了，则所有在waiting队列上的ctx一并处理。但是它这个实现会导致waiting队列上的ctx不会再有超时（因为timeout只处理了加定时器的那个请求），加上dns resend的机制，如果dns server挂了，则nginx会每隔5秒resend之前的dns查询，直到和客户端的连接关闭，我之前在SEnginx中处理了反向查找的问题，参考这次提交：0003ecf ，所以我想是否按照这个方法再处理一下正向查找就可以了呢？这样就不用在resolver的使用者这个环节进行超时的处理了，否则以后每次遇到类似的场景的时候可能都得额外处理一下。
整体期望达成的效果就是：在resolver_timeout时间内来的请求只发一次dns，加一次resolver_timeout长度的定时器，然后后续所有的请求都进入waiting队列等待，因此不会每个请求都发dns查询，所有在waiting队列上的请求都一起超时，所以也不会每个请求都等待resolver_timeout这么长的时间。不知到是否合理，可以继续讨论讨论。
也可能是我理解的不对，可能proxy_dyn_resolve_fail_timeout的应用场景是这样？就是例如把resolver_timeout设置成3秒，把proxy_dyn_resolve_fail_timeout设置成10秒，然后第一个3秒超时后希望之后7秒都不用再查dns了

第二，查询失败之后的行为，这个我感觉做个开关可能比较合理，让用户设置一下dns查询失败之后fall back的行为，可以是直接finalize request，也可以走next upstream的流程，还可以connect到之前的ip地址上。因为有些场景，比如域名指向一个云计算的instance，可能频繁的terminate和launch，那ip地址可能一直在变化，所以启动时解析的ip就没多大意义，所以是否是让用户根据实际需要来设置会比较好呢？

[InfoHunter]

正向查询DNS时ctx超时处理的修改：ddc6bc7

[taoyuanyuan]

最近有点忙, 才看到.
是的, proxy_dyn_resolve_fail_timeout 这个参数的作用就是你后面说的那样.
就跟 upstream 里面server的 fail_timeout一个意思.
"把resolver_timeout设置成3秒，把proxy_dyn_resolve_fail_timeout设置成10秒，然后第一个3秒超时后希望之后7秒都不用再查dns了"
proxy_dyn_resolve_fail_timeout 可以尽量设置的长一些. 比如 60s.
在使用dynreslove的时候, dns服务器就是一个强依赖了
个人觉得这样可以在dns出问题的时候大比例的让请求可用, 而不是全挂掉.
特别这种 proxy_pass www.xxx.com; 或者 upstream里面全是域名的情况, next_upstream也没用了.

[InfoHunter]

Hi，这样的话，因为在fail_time时间段里没有dns查询，即使dns又活了也不知道，所以这段时间里的行为就很关键，所以问题又变成了dns挂了之后怎么办的问题：）。你现在的做法就是直接fall back到启时获取的那个ip上，这个可能就和应用场景以及需求有关系了，绝大部分情况下可能是没问题的，但实际上我们这边的需求来源和这个人遇到的问题很类似：http://www.jethrocarr.com/2013/11/02/nginx-reverse-proxies-and-dns-resolution/

大致是这种：
"This works perfectly 95% of the time, but Amazon ELBs (even internal) have a tendency to change their IP addresses. Normally this doesn’t matter, since you never reference ELBs via their IP address and use their DNS name instead ...

This leads to a situation where the Amazon ELB IP address changes, Amazon update the DNS record, but Nginx never re-resolves the DNS record and stays pointing at the old IP address. Subsequently requests to the backend start failing once Amazon drops services from the old IP address."

这样的话即使fall back到启动时的ip上，也并不能最大比例的提供服务，因为这期间ip不知道变了多少次了。那在这种情况下，走next upstream找一个backup的server（用IP地址定义，不用域名），或者是fall back到最后一次dns成功解析的ip地址上，可能都比直接fall back到启动时的ip上让请求可用的概率要大。所以我之前的想法是是否能做成选项，让用户根据自己的场景来选择最合适的，而不是固定死这个行为。

[cfsego]

这个讨论非常好。taoyuanyuan引出了一个DNS失效后如何处理的问题，然后试图通过使用原始配置的server列表来解决这个问题。而InfoHunter让我们了解了在开放云平台上，这种设计可能是不起作用的。如你所说，在DNS服务器无法工作的情况下，使用stale的DNS数据比使用original的数据具有更大的概率使请求可用。现在的关键问题是，如何才能保存下来一份stale的数据。就目前nginx的逻辑来看，一条DNS结果一旦需要验证失效，他就立即被清除了。

[InfoHunter]

可否直接更新peers呢？查询成功的结果去更新启动时解析的配置。这样的话就需要考虑一个域名返回多个IP地址的情况，不能像现在只处理第一个IP。更麻烦的是peers的大小是在init upstream的main conf的时候就固定死了，如果同一个域名在启动时解析的IP数量和动态解析的时候数量不一样（比如多了），那就得重新做一轮init_upsream的工作。

你们好像有一个动态配置upstream的模块吧，更新peers这块的流程似乎和动态配置upstream能合上啊

[taoyuanyuan]

是啊 确实用最后一次解析的ip 比 原始的更靠谱.
https://github.com/yzprofile/ngx_http_dyups_module
@yzprofile 元哥哥的这个模块貌似可以合上来.