web应用负载均衡策略

1.  名词解释

1.  正向代理与反向代理

简单说

我们内网访问facebook用的代理就叫正向代理
从美国访问我们内网需要的代理就叫反向代理
 
多台服务器处于一个内网，而我们要访问这些服务器，中间加一台 反向代理，根据各台服务器的负载，指定访问其中一台。这就叫负载均衡。反向代理一般就是来干这个的。 代理服务器来接受外部的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给外部的请求连接的客户端，此时代理服务器对外就表现为一个服务器。 
 

反向代理一般作用： 

1：减轻源服务器负载 

2：保障源服务器安全 

3：对源服务器进行负载均衡(Load Balance)。

 

2.  几个组件

2.  Apache（web服务器、负载均衡器）

它是Apache软件基金会的一个开放源代码的跨平台的网页服务器，属于老牌的web服务器了，支持基于Ip或者域名的虚拟主机，支持代理服务器，支持安全Socket层(SSL)等等，目前互联网主要使用它做静态资源服务器，也可以做代理服务器转发请求(如：图片链等)或者负载均衡器，结合tomcat等servlet容器处理jsp。
使用web服务器的用途：
l  提升对静态文件的处理性能

l  利用 Web服务器来做负载均衡以及容错

l  无缝的升级应用程序

 

3.  LVS

LVS(Linux Virtual Server,Linux虚拟服务器），是章文嵩博士开发的开放软件，目前已经集成到Linux内核中。是一种虚拟的服务器集群系统。

基于不同的网络技术，LVS支持多种负载均衡机制。包括：VS/NAT（基于网络地址转换技术）、VS/TUN（基于IP隧道技术）和VS/DR（基于直接路由技术）。

1.      VS/NAT

NAT（Network AddressTranslation，网络地址转换）也叫做网络掩蔽或者IP掩蔽，是将IP
数据包头中的IP 地址转换为另一个IP 地址的过程。

NAT能够将私有（保留）地址转化为合法IP地址，通常用于一个公共IP地址和多个内部私有IP地址直接的映射，广泛应用于各种类型Internet接入方式和各种类型的网络中。

通过使用NAT将目的地址转换到多个服务器的方式，可以实现负载均衡，同时能够隐藏并保护内部服务器，避免来自网络外部的攻击。商用负载均衡设备如Cisco的LocalDirector、F5的Big/IP和Alteon的ACEDirector都是基于NAT方法。

VS/NAT(Virtual Server viaNetwork Address Translation)是基于NAT技术实现负载均衡的方法。其架构如下图所示：

客户通过Virtual IP Address（虚拟服务的IP地址）访问网络服务时，请求报文到达调度器
        2. 调度器根据连接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。

       3. 真实的服务器处理请求，并将响应报文发到调度器。

调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口
调度器将修改过的报文发给用户
在VS/NAT的集群系统中，请求和响应的数据报文都需要通过负载调度器，当真实服务器的数目在10台和20台之间时，负载调度器将成为整个集群系统的新瓶颈。大多数Internet服务都有这样的特点：请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理，即在负载调度器中只负责调度请求而响应直接返回给客户，将极大地提高整个集群系统的吞吐量。比如IP隧道技术。

2.      VS/TUN(IP隧道技术)

IP Tunneling(IP隧道)技术，又称为IP封装技术(IP encapsulation)，是一种在网络之间传递数据的方式。可以将一个IP报文封装到另一个IP报文（可能是不同的协议）中，并转发到另一个IP地址。IP隧道主要用于移动主机和虚拟私有网络（Virtual
Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。

VS/TUN（VirtualServer via IP Tunneling）是基于隧道技术实现负载均衡的方法。其架构如下图所示：

VS/TUN与VS/NAT的工作机制大体上相同，区别在于：

1. 调度器转发报文的时候进行了协议的二次封装，真实的服务器接收到请求后先进行解包。过程如下图所示：

2. 响应报文从后端服务器直接返回给客户，不需要经过调度器。

3.      VS/DR

DR(Direct Routing,直接路由), 路由器学习路由的方法之一。路由器对于自己的网络接口所直连的网络之间的通信，可以自动维护路由表，而且不需要进行路由计算。

直接路由通常用在一个三层交换机连接几个VLAN的情况，只要设置直接路由VLAN之间就可以通信，不需要设置其他的路由方式。

VS/DR(Virtual Server via Direct Routing)是基于直接路由实现负载均衡的方法。其架构如下图所示：

1.  跟VS/TUN方法相同，VS/DR利用大多数Internet服务的非对称特点，负载调度器中只负责调度请求，而服务器直接将响应返回给客户，可以极大地提高整个集群系统的吞吐量。

2.  VS/DR要求调度器和服务器组都必须在物理上有一个网卡通过不分段的局域网相连，即通过交换机或者高速的HUB相连，中间没有隔有路由器。VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文；所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。

VS/DR的整个过程与VS/TUN非常类似，不同之处在于调度器不对请求包进行二次封装，只是将目标MAC地址更改为经过调度算法选出的目标服务器的MAC地址。如下图：

 

4.      VS/FULL

如上节所述，前面三种传统的负载均衡机制各自存在一些不足。

VS/FULLNAT是为了解决这些不足而新开发的一种转发模式。VS/FULLNAT的特点是：

调度器和服务器可以跨VLAN通信，不需要配置在同一个网段
请求和应答报文都经过调度器，服务器不需要绑定虚拟IP
VS/FULLNAT这两个特点可以简化网络拓扑，降低运维成本和风险。

5.      比较

VS/NAT

·        优点

对后端服务器的操作系统无要求
只需要一个IP地址配置在调度器上，服务器组可以用私有的IP地址。
支持端口映射

·        缺点

请求和响应报文都需要通过调度器，伸缩能力有限（10+)
要求服务器和调度器在同一个VLAN
需要将服务器的默认网关指向调度器
对于那些将IP地址或者端口号在报文数据中传送的网络服务，需要编写相应的应用模块来转换报文数据中的IP地址或者端口号

VS/TUN

·        优点

不需要调度应答报文，性能高
服务器和调度器可以不在同一个VLAN
支持广域负载均衡

·        缺点

所有的服务器必须支持“IP Tunneling”协议，要安装内核模块（比如IPIP等），配置复杂
有建立IP隧道的开销
服务器上直接绑定虚拟IP(Virtaul IP)，风险很大
服务器需要联通外网
不支持端口映射

VS/DR

·        优点

与VS/TUN相比，没有IP隧道的开销，性能最好

·        缺点

要求调度器与服务器都有一块网卡连在同一物理网段（同一个VLAN）上
要求服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上
服务器上直接绑定虚拟IP(Virtaul IP)，风险很大
不支持端口映射

6.      选择方法

1.  如果人少钱多，不在乎性能的损耗愿意多买服务器，同时希望最大程度较少运维的工作量，可以选择FULLNAT
2.  很大众的方式是用DR，没有太多的优点但也没有太多的缺点
3.  如果要搞广域网负载均衡，那就用TUN吧
4.  个人感觉NAT不是为了互联网用的。小并发的实验性应用或者用在非web场合，比如mysql集群等。当然，如果需要端口映射，必须使用NAT
 

3.  Ngnix（web服务器、反向代理服务器、负载均衡器）

 俄罗斯人开发的一个高性能的HTTP和反向代理服务器。由于Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为Web服务器的网站也越来越多，其中包括新浪博客、新浪播客、网易新闻、腾讯网、搜狐博客等门户网站频道等，在3w以上的高并发环境下，ngnix处理能力相当于apache的10倍。

     参考：apache和tomcat的性能分析和对比(http://blog.s135.com/nginx_php_v6/)

4. Tengine（taobao开发的Nginx升级版）

Tengine是由淘宝网发起的Web服务器项目。它在Nginx的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。Tengine的性能和稳定性已经在大型的网站如淘宝网，天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。

从2011年12月开始，Tengine成为一个开源项目，Tengine团队在积极地开发和维护着它。

5.  HAProxy（高可用、负载均衡）

 HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点， 这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的web服务器不被暴露到网络上.

6.  Keepalived（故障转移，备机，linux环境下的组件）

  这里说的keepalived不是apache或者tomcat等某个组件上的属性字段，它也是一个组件，可以实现web服务器的高可用(HA highavailably)。它可以检测web服务器的工作状态，如果该服务器出现故障被检测到，将其剔除服务器群中，直至正常工作后，keepalive会自动检测到并加入到服务器群里面。实现主备服务器发生故障时ip瞬时无缝交接。它是LVS集群节点健康检测的一个用户空间守护进程，也是LVS的引导故障转移模块（director
failover）。Keepalived守护进程可以检查LVS池的状态。如果LVS服务器池当中的某一个服务器宕机了。keepalived会通过一 个setsockopt呼叫通知内核将这个节点从LVS拓扑图中移除。

7. Memcached（分布式内存对象缓存系统，实现内存级别的session共享）

     —— 它是一个高性能分布式内存对象缓存系统。当初是Danga Interactive为了LiveJournal快速发展开发的系统，用于对业务查询数据缓存，减轻数据库的负载。其守护进程(daemon)是用C写的，但是客户端支持几乎所有语言(客户端基本上有3种版本[memcacheclient for java;spymemcached;xMecache])，服务端和客户端通过简单的协议通信；在memcached里面缓存的数据必须序列化。

8. Terracotta（java集群平台）

  是一款由美国Terracotta公司开发的著名开源Java集群平台。它在JVM与Java应用之间实现了一个专门处理集群功能的抽象层，允许用户在不改变系统代码的情况下实现java应用的集群。支持数据的持久化、session的复制以及高可用(HA)。详细参考：http://topmanopensource.iteye.com/blog/1911679

3.  负载均衡需要解决的问题

1. 负载均衡器(用web服务器实现)

1)       Apache

2)       Nginx/Tenginx

2. Session共享（粘连不是一个完备的方法）

1)       Tomcat自带的session复制技术(tomcat数量大于4时，组播会导致网络堵塞，不建议使用)

2)       Memcached实现内存级别的session共享

通过memcached-session-manager（msm）插件，通过tomcat上一定的配置，即可实现把session存储到memcached服务器上。注意：tomcat支持tomcat6+，并且memcached可以支持分布式内存，msm同时支持黏性session（stickysessions）或者非黏性session（non-stickysessions）两种模式，在memcached内存中共享的对象需要序列化。

3)       Terracotta实现JVM级别的session共享

它基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点，并且共享的数据对象不需要序列化。

3. 故障转移

使用Keepalive实现

4.  几种方式

1.  DNS轮询

DNS轮询是最简单的负载均衡方式。以域名作为访问入口，通过配置多条DNS记录使得请求可以分配到不同的服务器。

DNS轮询没有快速的健康检查机制，而且只支持WRR的调度策略导致负载很难“均衡”，通常用于要求不高的场景。并且DNS轮询方式直接将服务器的真实地址暴露给用户，不利于服务器安全。

2.  CDN

CDN（ContentDelivery Network，内容分发网络）。通过发布机制将内容同步到大量的缓存节点，并在DNS服务器上进行扩展，找到里用户最近的缓存节点作为服务提供节点。

因为很难自建大量的缓存节点，所以通常使用CDN运营商的服务。目前国内的服务商很少，而且按流量计费，价格也比较昂贵。

3.  IP负载均衡

IP负载均衡是基于特定的TCP/IP技术实现的负载均衡。比如NAT、DR、Turning等。是最经常使用的方式。

IP负载均衡可以使用硬件设备，也可以使用软件实现。硬件设备的主要产品是F5-BIG-IP-GTM（简称F5)，软件产品主要有LVS、HAProxy、NginX。其中LVS、HAProxy可以工作在4-7层，NginX工作在7层。关于三者的简单对比，可以参考这里。

硬件负载均衡设备可以将核心部分做成芯片，性能和稳定性更好，而且商用产品的可管理性、文档和服务都比较好。唯一的问题就是价格。

软件负载均衡通常是开源软件。自由度较高，但学习成本和管理成本会比较大。

1.  Apache+tomcat(过时的方法)

1.  结构

1、     他们之间的通信有三种方式：ajp_proxy、mod_jk链接器、http_proxy。具体参考：http://www.ibm.com/developerworks/cn/opensource/os-lo-apache-tomcat/
2、     apache的分发策略有4种。权重(默认)、流量(bytraffic)、请求次数(byRequests)、繁忙程度(byBusyness根据活跃请求数的多少)
2.  apache与tomcat的通信方式
l  jk（在apache中配置）

这是最常见的方式，你可以在网上找到很多关于配置JK的网页，当然最全的还是其官方所提供的文档。JK本身有两个版本分别是
1和 2，目前 1最新的版本是 1.2.19，而版本
2早已经废弃了，以后不再有新版本的推出了，所以建议你采用版本 1。JK是通过 AJP
协议与 Tomcat
服务器进行通讯的，Tomcat
默认的 AJP Connector
的端口是 8009。

l  http_proxy

这是利用 Apache
自带的 mod_proxy
模块使用代理技术来连接 Tomcat。在配置之前请确保是否使用的是 2.2.x版本的 Apache
服务器。因为 2.2.x
版本对这个模块进行了重写，大大的增强了其功能和稳定性。

http_proxy 模式是基于 HTTP协议的代理，因此它要求 Tomcat必须提供
HTTP 服务，也就是说必须启用 Tomcat的 HTTP Connector。

l  ajp_proxy

ajp_proxy 连接方式其实跟 http_proxy方式一样，都是由 mod_proxy所提供的功能。配置也是一样，只需要把 http://换成 ajp://，同时连接的是 Tomcat的
AJP Connector所在的端口。

比较：

相对于 JK的连接方式，后两种在配置上是比较简单的，灵活性方面也一点都不逊色。但就稳定性而言就不像 JK这样久经考验，毕竟
Apache 2.2.3推出的时间并不长，采用这种连接方式的网站还不多，因此，如果是应用于关键的互联网网站，还是建议采用 JK的连接方式。

3.  apache分发策略
权重

轮询

 

4.  session问题
1、     粘性session（在apache中配置）：apache支持stickysession(粘性session)，即为：访问用户访问了A-tomcat，那么他的所有请求都会转发到A-tomcat，而不会到B-tomcat。[这样的负载均衡效果不好，适用于小型网站，
2、      Session复制（在tomcat中配置）：在访问系统的会话过程中，用户登录系统后，不管访问系统的任何资源地址都不需要重复登录，这里面servlet容易保存了该用户的会话(session)。如果两个tomcat(A、B)提供集群服务时候，用户在A-tomcat上登录，接下来的请求web服务器根据策略分发到B-tomcat，因为B-tomcat没有保存用户的会话(session)信息，不知道其登录，会跳转到登录界面。这时候我们需要让B-tomcat也保存有A-tomcat的会话，我们可以使用tomcat的session复制实现或者通过其他手段让session共享。
5.  缺陷
1、     只有一个web服务器，明显的单点故障。如果该apache出现问题，整个网站就会瘫痪。
2、     当tomcat节点数达到4个以上时候，集群性能呈线性下滑；另外当用户访问量大到一定程度，会话内容随之增多，tomcat节点相互之间通信产生大量的网络消耗，产生网络阻塞，整个集群的吞吐量不能再上升。

2.  nginx+Keepalived+tomcat（解决单点故障和性能问题，session存在缺陷）

1.       结构

1.  Nginx作为web服务器和负载均衡器，独立部署，并配置代理目标的地址。用户访问时是访问的nginx的地址，而不是tomcat的地址。为提高效率，可以在nginx中配置将tomcat中的静态文件（js，css，html等）缓存到nginx中以提高访问效率

2.  Keepalive作为故障转移组件

 

3.  Tomcat作为应用服务器

2.       nginx配置
1.        Server{}段的参数说明：（一个server段代表了nginx代理的一个url。可配置多个server）

l  listen：表示当前的代理服务器监听的端口，默认的是监听80端口。注意，如果我们配置了多个server，这个listen要配置不一样，不然就不能确定转到哪里去了。

l  server_name：nginx服务器的地址或者域名,可配置多个

l  location：表示匹配的路径，配置了/表示所有请求都被匹配到这里

         root：里面配置了root这时表示当匹配这个请求的路径时，将会在这个文件夹内寻找相应的文件，这里对我们之后的静态文件伺服很有用。

         index：当没有指定主页时，默认会选择这个指定的文件，它可以有多个，并按顺序来加载，如果第一个不存在，则找第二个，依此类推。

 

2.         

3.       SESSION解决方法
1.    使用tomcat自带的cluster方式，多个tomcat见自动实时复制session信息，配置起来很简单。但这个方案的效率比较低，在大并发下表现并不好。

2.    利用nginx的基于访问ip的hash路由策略，保证访问的ip始终被路由到同一个tomcat上，这个配置更简单。但是我们的应用很可能是某一个局域网大量用户同时登录，这样负载均衡就没什么作用了。

4.       负载均衡策略（分发策略）
负载均衡策略是通过upstream属性来设置的。

upstream tomcat_loadbalanace{ 

    ip_hash;#这个值是个示例

    server192.168.0.112:8080; 

    server192.168.0.123:8080;

}

 

   server {

        listen       80;#nginx服务器监听对本服务器80端口的访问

       #server_name  192.168.0.112;

        location /command/{ #增加项目名， 避免路径不对引起文件无法访问

           # root   html;

           # index  index.html index.htm;

             proxy_passhttp://tomcat_loadbalanace/command/; #地址写全，不然会发生重定向问题

        }

      }

 

实际的访问地址是proxy_pass中非ip部分与upstream中的sever部分的值的组合

 

 

    upstream tomcat_loadbalanace{ 

    ip_hash;

    server192.168.0.112:8080; 

    server192.168.0.123:8080;

    }

 

 

 

1、轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

upstream backserver {

server 192.168.0.14;

server 192.168.0.15;

}

2、weight

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

upstream backserver {

server 192.168.0.14 weight=10;

server 192.168.0.15 weight=10;

}

3、ip_hash

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstream backserver {

ip_hash;

server 192.168.0.14:88;

server 192.168.0.15:80;

}

4、fair（第三方，慎用）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream backserver {

server server1;

server server2;

fair;

}

5、url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

upstream backserver {

server squid1:3128;

server squid2:3128;

hash $request_uri;

hash_method crc32;

}

 

5.       缺陷
1.        Session共享仅能用tomcat自带的session复制功能，性能低下

2.        如果用nginx自带的ip_hash分发策略，则同一个请求都被转到固定的应用服务器，一旦挂机则无法恢复。

 

3.  nginx +Keepalive+ tomcat+ memcached（解决session复制问题）

haproxy+

 

haproxy+

 

5.  比较（nginx、haproxy、lvs，keepalived和session共享是必须的）

目前流行的方式是

Web前端：nginx/haproxy+keepalived

数据库：一主多从，读写分离，lvs+keepalived

 

 

方式	优点	缺陷	适用环境
Nginx（负载均衡和web服务器）	n  工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。  n  Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会；  n  Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。  n  可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。  l  Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。  l  Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。  l  Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。  l  Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比Nginx的就只有 lighttpd了，不过 lighttpd目前还没有做到Nginx完全的功能，配置也不那么清晰易读，社区资料也远远没Nginx活跃。  l  Nginx也可作为静态网页和图片服务器，这方面的性能也无对手。还有Nginx社区非常活跃，第三方模块也很多。	n   Nginx仅能支持http、https和Email协议，这样就在适用范围上面小些，这个是它的缺点。 n  对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。 n  不支持Session的直接保持，但能通过ip_hash来解决(使得同一ip访问同一应用服务器，有缺陷的方法)。(通过第三方来解决，如memcached) n  负载度和稳定度差LVS还有几个等级：Nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的。	中小型网站，如日PV小于1000万
Lvs（负载均衡软件）	l  抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。  l   配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。  l  工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。  l  无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会受到大流量的影响。  l  应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。	l  软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。  l  如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有 Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。
Haproxy（负载均衡软件）	l  HAProxy也是支持虚拟主机的。 l   HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导； l  同时支持通过获取指定的url来检测后端服务器的状态。  l  HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。  l  HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。  l  HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种：  ① roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；  ② static-rr，表示根据权重，建议关注；  ③ leastconn，表示最少连接者先处理，建议关注；  ④ source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；  ⑤ ri，表示根据请求的URI；  ⑥ rl_param，表示根据请求的URl参数’balance url_param’ requires an URL parameter name；  ⑦ hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；  ⑧ rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。

 

 

6.  选型方法

1.      第一阶段：利用Nginx或HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或HAproxy就是第一选择，此时这些东西上手快，配置容易，在七层之上利用HTTP协议就可以。这时是第一选择。

2.      第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用Array就是首要选择，Nginx此时就作为LVS或者Array的节点来使用，具体LVS或Array的是选择是根据公司规模和预算来选择，Array的应用交付功能非常强大，本人在某项目中使用过，性价比也远高于F5，商用首选，但是一般来说这阶段相关人才跟不上业务的提升，所以购买商业负载均衡已经成为了必经之路。

3.      第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。    

4.      最终形成比较理想的基本架构为：Array/LVS — Nginx/Haproxy —Squid/Varnish — AppServer。