常见负载均衡的优势和缺点对比（Nginx、HAProxy、LVS）

1、Nginx优势：

一、工做在网络7层之上，可针对http应用作一些分流的策略，如针对域名、目录结构，它的正规规则比HAProxy更为强大和灵活，因此，目前为止普遍流行。

二、Nginx对网络稳定性的依赖很是小，理论上能ping通就能进行负载功能。

三、Nginx安装与配置比较简单，测试也比较方便，基本能把错误日志打印出来。

四、能够承担高负载压力且稳定，硬件不差的状况下通常能支撑几万次的并发量，负载度比LVS小。

五、Nginx能够经过端口检测到服务器内部的故障，如根据服务器处理网页返回的状态码、超时等，并会把返回错误的请求从新提交到另外一个节点。

六、不只仅是优秀的负载均衡器/反向代理软件，同时也是强大的Web应用服务器。LNMP也是近些年很是流行的Web架构，在高流量环境中稳定性也很好。

七、可做为中层反向代理使用。

八、可做为静态网页和图片服务器。

九、Nginx社区活跃，第三方模块很是多。

Nginx常规的和HTTP请求和相应流程图：

 

 

Nginx缺点：

一、适应范围较小，仅能支持http、https、Email协议。

二、对后端服务器的健康检查，只支持经过端口检测，不支持url来检测。好比用户正在上传一个文件，而处理该上传的节点恰好在上传过程当中出现故障，Nginx会把上传切到另外一台服务器从新处理，而LVS就直接断掉了，若是是上传一个很大的文件或者很重要的文件的话，用户可能会所以而不满。

三、 不支持Session的直接保持，但能经过ip_hash来解决，对Big request header的支持不是很好

 

2、LVS优势：

一、抗负载能力强、是工做在网络4层之上仅做分发之用，没有流量的产生，这个特色也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。

二、配置性比较低，这是一个缺点也是一个优势，由于没有可太多配置的东西，因此并不须要太多接触，大大减小了人为出错的概率。

三、工做稳定，由于其自己抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过咱们在项目实施中用得最多的仍是LVS/DR+Keepalived。

四、无流量，LVS只分发请求，而流量并不从它自己出去，这点保证了均衡器IO的性能不会收到大流量的影响。

五、应用范围比较广，由于LVS工做在4层，因此它几乎能够对全部应用作负载均衡，包括http、数据库、在线聊天室等等。

六、支持多种负载均衡算法：rr（轮询），wrr（带权轮询）、lc（最小链接）、wlc（带权最小链接）

七、LVS工做模式有4种：

     （1）nat地址转换

     （2）dr直接路由

     （3）tun隧道

     （4）full-nat

LVS DR(Direct Routing)模式的网络流程图：

 

LVS的缺点：

一、软件自己不支持正则表达式处理，不能作动静分离；而如今许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优点所在。

二、若是是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，若是实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。

 

3、HAProxy优势：

一、HAProxy是支持虚拟主机的，能够工做在四、7层(支持多网段)

二、HAProxy的优势可以补充Nginx的一些缺点，好比支持Session的保持，Cookie的引导；同时支持经过获取指定的url来检测后端服务器的状态。

三、HAProxy跟LVS相似，自己就只是一款负载均衡软件；单纯从效率上来说HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。

四、HAProxy支持TCP协议的负载均衡转发，能够对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，你们能够用LVS+Keepalived对MySQL主从作负载均衡。

五、HAProxy负载均衡策略很是多，HAProxy的负载均衡算法如今具体有以下8种

①　roundrobin

表示简单的轮询，每一个服务器根据权重轮流使用，在服务器的处理时间平均分配的状况下这是最流畅和公平的算法。该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。最大支持4095个后端主机；

②　leastconn

链接数最少的服务器优先接收链接。leastconn建议用于长会话服务，例如LDAP、SQL、TSE等，而不适合短会话协议。如HTTP.该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。

③　static-rr

每一个服务器根据权重轮流使用，相似roundrobin，但它是静态的，意味着运行时修改权限是无效的。另外，它对服务器的数量没有限制。该算法通常不用；

④　source

对请求源IP地址进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个客户端IP地址老是访问同一个服务器。若是哈希的结果随可用服务器数量而变化，那么客户端会定向到不一样的服务器；该算法通常用于不能插入cookie的Tcp模式。它还能够用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连；该算法默认是静态的，因此运行时修改服务器的权重是无效的，可是算法会根据“hash-type”的变化作调整。

⑤　uri

表示根据请求的URI左端（问号以前）进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个URI地址老是访问同一个服务器。通常用于代理缓存和反病毒代理，以最大限度的提升缓存的命中率。该算法只能用于HTTP后端；该算法通常用于后端是缓存服务器；该算法默认是静态的，因此运行时修改服务器的权重是无效的，可是算法会根据“hash-type”的变化作调整。

⑥　url_param

在HTTP GET请求的查询串中查找<param>中指定的URL参数，基本上能够锁定使用特制的URL到特定的负载均衡器节点的要求；该算法通常用于将同一个用户的信息发送到同一个后端服务器；该算法默认是静态的，因此运行时修改服务器的权重是无效的，可是算法会根据“hash-type”的变化作调整。

⑦　hdr(name)

在每一个HTTP请求中查找HTTP头<name>，HTTP头<name>将被看做在每一个HTTP请求，并针对特定的节点；若是缺乏头或者头没有任何值，则用roundrobin代替；该算法默认是静态的，因此运行时修改服务器的权重是无效的，可是算法会根据“hash-type”的变化作调整。

⑧　rdp-cookie（name）

为每一个进来的TCP请求查询并哈希RDP cookie<name>；该机制用于退化的持久模式，可使同一个用户或者同一个会话ID老是发送给同一台服务器。若是没有cookie，则使用roundrobin算法代替；该算法默认是静态的，因此运行时修改服务器的权重是无效的，可是算法会根据“hash-type”的变化作调整。

haproxy的工做模型图：

 

HAPorxy缺点：

1. 不支持POP/SMTP协议

2. 不支持SPDY协议

3. 不支持HTTP cache功能。如今很多开源的lb项目，都或多或少具有HTTP cache功能。

4. 重载配置的功能须要重启进程，虽然也是soft restart，但没有Nginx的reaload更为平滑和友好。

5. 多进程模式支持不够好

6. 不能作Web服务器即Cache

 

4、三大主流软件负载均衡器适用的生产场景：

1.网站建设初期，能够选用Nginx、HAproxy做为反向代理负载均衡（流量不大时能够选择不用负载均衡）由于其配置简单，性能也能知足通常业务场景。若是考虑到负载均衡器是有单点失败问题，能够采用Nginx+Keepalived避免负载均衡器自身单点问题。

2.网站并发达到必定程度后，为了提升稳定性和转发效率，可使用LVS，毕竟LVS比Nginx/HAproxy要更稳定，转发效率也高。