本文介绍nginx做reverse proxy时遇到的一个upstream round robin select logic的bug及解决办法。
我们用那个nginx做reverse proxy，一直有一个upstream round robin select logic的bug, 以前在maillist提过http://forum.nginx.org/read.php?2,220415,220440#msg-220440 大神说已经有人提过了，trac在这：http://trac.nginx.org/nginx/ticket/64
总的来说就是，问题发生的场景是n-1台server不可用(n>=3)，理论上应该只是影响请求的延迟，而不应该直接返回502或503的(因为有一台backend server是处于正常状态的).
我测试的版本: 1.0.XXX, 1.1.XXX, 1.2.XXX
os platform : centos 5.X, UBUNTU 11.10 or 12.04
按Maxim Dounin大神的说法，此bug在1.1.XX即1.2.XX版本虽然还存在，不过出现几率得到缓解了.
比较简单的解决办法是，可以通过增加后台web server和同时提高MAX_FAIL来减少n-1同时出现问题的可能性，就能避免出现上述问题. 关于nginx upstream种的max_fails和timeout文档，请参照官方:http://nginx.org/en/docs/http/ngx_http_upstream_module.html，我们遇到的问题是在对待容错要求较严格的服务时，增加max_fails的代价就是在增加在backend server出故障时所影响到的请求数量(请求会有一定延迟，具体延迟多少依照你的settings)，所以在面对一个容错要求很严格，此问题会变得比较棘手，一方面max_fails不能太大，一方面max_fails如果太小在backend server做服务起停时容易触发此bug.
有什么办法，没办法，就经常google，然后看maillist，是否有其他同学也遇到这么变态的需求，偶然看到Tengine发布的changelog里有upstream_check 模块，才知道自己是孤陋寡闻了，接下来就是自己测试，验证之.
此模块的github地址: https://github.com/yaoweibin/nginx_upstream_check_module
这个模块支持tcp，ssl，http的方式对backend server做存活检测，具体feature在README里都说的很清楚了，在此不再做重复描述.
淘宝哥们写的，蛮靠谱. 开源就是各种好，拿来就用。
有碰到此bug，或对backend server的存活检测有较严格需求的，可以使用此办法。