Nginx与HAProxy在web应用中的比较

浏览数：30 / 时间：2015年06月09日

这几天我对Nginx和HAProxy做了比较，得出了令人吃惊的结果。

首先，介绍一些背景情况。在很长的一段时间里，我们在Bengler把Nginx作为我们项目的主要web服务器，就像在Mongrel下代理Rails运行一样。Nginx是一个非常好的小开源软件，它占用空间小、有合理的配置语言、功能先进而且速度快。然而，我们却很快发现nginx中代理的负载均衡特性却不尽如人意。

这其中最核心的问题是代理负载均衡算法。Nginx仅仅自带轮循和源ip哈希两种负载均衡器；而只有前者是我们感兴趣的,因为我们的对象是将负载均匀地分散到一群Mongrel后端服务器上。轮循负载均衡（round-robin）在这种情况下是可以被接受的：如果每个请求都是在几毫秒之内结束，那么没问题。

但是，如果一个页面在加载时花费时间稍长，Nginx将会把请求发送至正在处理请求的后端服务器中--这将导致，一些后端服务器会排队处理请求，而另一些服务器却仍处于空闲状态。也就是说，你得到的负载没有被均匀分配，而这种不平均会随着负载的增加而加剧。

所以当Gzegorz Nosek在 EngineYard的支持下声明他公平的负载平衡器模块时，我们自然会抨击它。Gzegorz的模块将请求分发至拥有最少未处理请求的后端服务器上，这种做法很大程度上提高的性能。

不幸的是，Gzegorz的补丁不完全稳定，而且成为我们稳定性问题的主要来源。而且有时它会在后端服务器空闲的状态下停止分发请求，并且堆积请求，或者更糟，会变的混乱还会拒绝服务请求；而对于这种情况唯一的解救方案是重启Nginx。然而，即使实在正常情况下，该模块也会经常会将多个请求发送到同一台后端服务器上，尽管其他有些服务器还是空闲的，因为我们每台后端服务器都没有限制可接收连接数的数量。

自从阅读了HAProxy后，我急切的想亲自尝试下这个产品。HAProxy有一些非常吸引人的特性：

它是一个代理--而且只是一个代理。它不能提供文件，例如：代理就是它唯一做的事情。
它可以代理任何基于TCP的东西--而不仅仅是HTTP。
非常多的负载均衡算法，包括“最少连接数（least connections）”策略，将后端服务器和最少连接数关联起来；而这，也正是我们想要的。
后端可以通过URL被只能的做有效性检测用来避免将请求发送至有问题的后端服务器上。（它甚至可以调整检查时机以避开峰值。）
提供专用的状态页来告诉你后端服务器的状态、运行时间以及很多齐全的指标。还有一个方法是从Unix域套接字读取指标。
请求可以通过各种各样的东西发送：cookies、URL字符串、客户端IP，等等。

我非常喜欢HAProxy如此专一的方法。经验告诉我,简单、专一,在复杂的专用应用程序是可取的,灵活的放之四海而皆准的应用程序；Varnish 和Memcached就是两个很好的例子。

为了确定HAProxy是否达标，我不得不做一个简单的压力测试。它们不一定非常科学，但是我觉得这已经够用了。

安装：专门的测试机器（四核AMD64 2.4GHz, 4GB内存），3个mongrel每个下面跑一个真实的基于Rails1.2的app。我使用Apache ab作为压力测试工具（许多人更倾向于httperf,但我们从未见过心有灵犀），而且我在各种并发情况下各跑1000个请求；被测试的页面是通过一个小的控制器action来做一个数据库调用、一次Memcached查找以及渲染一个空页面；这总共话花费20ms左右。

我已经在Nginx下配置了Gzegorz的公平负载均衡补丁。这个配置除了为Mongrel提供代理外不会做任何事情。

同是我配置HAProxy为“最小连接数（leastconns）”算法，而且每个Mongrel的最大连接数（maxconn）为1。这是故意配置的不公平--但我们的对象不是比较HAProxy和Nginx在每个配置相同时的情况；相反，我想观察的是通过HAProxy的小尝试可以获得什么样的性能情况。

“maxconns”配置是非常有意义的--由于Mongrel在同一时刻只能处理一个单独的请求，这意味着等待客户端请求在HAProxy内部空闲--而不是在Mongrel中。随后，当一个后端空闲下来时，下一个请求将排成线被分配到空闲的后端。当然，没有这个限制的话，请求将被分发到繁忙中的Mongrel，而且即使有可能有其他后端处于空闲状态也仍然会在这台后端服务器中等待。

Nginx使用公平负载均衡补丁，行为将相同，但是偶尔会重复请求,因为它没有限制每个后端可以接收的连接数量。

因此，一下这些数据、图展示了每个请求的响应时间。