haproxy健康检查（haproxy健康检查错开）
本文目录一览：
LVS 和 Nginx 和 HAproxy 的区别
Nginx的优点是：
1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。
2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会；
3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。
3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。
4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。
5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。
6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。
7、Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比Nginx的就只有lighttpd了，不过lighttpd目前还没有做到Nginx完全的功能，配置也不那么清晰易读，社区资料也远远没Nginx活跃。
8、Nginx也可作为静态网页和图片服务器，这方面的性能也无对手。还有Nginx社区非常活跃，第三方模块也很多。
Nginx的缺点是：
1、Nginx仅能支持http、https和Email协议，这样就在适用范围上面小些，这个是它的缺点。
2、对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。不支持Session的直接保持，但能通过ip_hash来解决。
LVS
LVS：使用Linux内核集群实现一个高性能、高可用的负载均衡服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。
LVS的优点是：
1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。
2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。
3、工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。
4、无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会收到大流量的影响。
5、应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。
LVS的缺点是：
1、软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
2、如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows
Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。
HAProxy
HAProxy的特点是：
1、HAProxy也是支持虚拟主机的。
2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。
3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。
4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。
5、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请求。
本人博客自己写的 blog.jxhs.me
haproxy dns缓存机制
haproxy dns缓存机制如下：
1.Haproxy支持http反向代理。
2.aproxy支持动态程序的反向代理。
3.Haproxy支持基于数据库的反向代理。
HAProxy是法国人Willy Tarreau开发的一款可应对客户端10000以上的同时连接的高性能的TCP和HTTP负载均衡器。由于其丰富强大的功能在国内备受推崇，是目前主流的负载均衡器。Haproxy是一个开源的高性能的反向代理或者说是负载均衡服务软件之一，它支持双机热备、虚拟主机、基于TCP和HTTP应用代理等功能。其配置简单，而且拥有很好的对服务器节点的健康检查功能（相当于keepalived健康检查），当其代理的后端服务器出现故障时，Haproxy会自动的将该故障服务器摘除，当服务器的故障恢复后haproxy还会自动重新添加回服务器主机。
Haproxy实现了一种事件驱动、单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space)实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么必须对其进行优化以使每个CPU时间片(Cycle)做更多的工作。
Haproxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。haproxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进当前架构中，同时可以保护web服务器不被暴露到网络上。
Haproxy软件引入了frontend，backend的功能，frontend（acl规则匹配）可以根据任意HTTP请求头做规则匹配，然后把请求定向到相关的backend（server pools等待前端把请求转过来的服务器组）。通过frontend和backend，可以很容易的实现Haproxy的7层负载均衡代理功能。
Haproxy是一种高效、可靠、免费的高可用及负载均衡解决方案，非常适合于高负载站点的七层数据请求。客户端通过Haproxy代理服务器获得站点页面，而代理服务器收到客户请求后根据负载均衡的规则将请求数据转发给后端真实服务器。
同一客户端访问服务器，Haproxy保持回话的三种方案：
1) Haproxy将客户端ip进行Hash计算并保存，由此确保相同IP访问时被转发到同一真实服务器上。
2) Haproxy依靠真实服务器发送给客户端的cookie信息进行回话保持。
3) Haproxy保存真实服务器的session及服务器标识，实现会话保持功能。
apache haproxy 怎么样
一、lvs的优势：1、抗负载能力强，因为lvs工作方式的逻辑是非常之简单，而且工作在网络4层仅做请求分发之用，没有流量，所以在效率上基本不需要太过考虑。在我手里的 lvs，仅仅出过一次问题：在并发最高的一小段时间内均衡器出现丢包现象，据分析为网络问题，即网卡或linux2.4内核的承载能力已到上限，内存和 cpu方面基本无消耗。2、配置性低，这通常是一大劣势，但同时也是一大优势，因为没有太多可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。3、工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。4、无流量，上面已经有所提及了。lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。5、基本上能支持所有应用，因为lvs工作在4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等等。另：lvs也不是完全能判别节点故障的，譬如在wlc分配方式下，集群里有一个节点没有配置VIP，会使整个集群不能使用，这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。所以，用lvs也得多多当心为妙。二、nginx和lvs作对比的结果1、nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具备这样的功能，所以 nginx单凭这点可利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰触碰，由lvs的第2条优点 看，触碰多了，人为出问题的几率也就会大。2、nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的 节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。另 外注意，lvs需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。3、nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间了，因为同上所述，lvs对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。4、nginx也同样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险较大，单机上的事情全都很难说。5、nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前lvs中 ldirectd也能支持针对服务器内部的情况来监控，但lvs的原理使其不能重发请求。重发请求这点，譬如用户正在上传一个文件，而处理该上传的节点刚 好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能 会因此而恼火。6、nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个nginx做apache代理的话，这些窄带链接会被nginx挡住，apache上就不会堆积过多的请求，这样就减少了相 当多的内存占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。lvs没有这些功能，也就无法能 比较。7、nginx能支持http和email（email的功能估计比较少人用），lvs所支持的应用在这点上会比nginx更多。在使用上，一般最前端所采取的策略应是lvs，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。重要的ip地址，最好交由lvs托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。nginx可作为lvs节点机器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所逊色于nginx。nginx也可作为中层代理使用，这一层面nginx基本上无对手，唯一可以撼动nginx的就只有lighttpd了，不过lighttpd目前还没有 能做到nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和lvs是最完美的方案了。nginx也可作为网页静态服务器，不过超出了本文讨论的范畴，简单提一下。具体的应用还得具体分析，如果是比较小的网站（日PV1000万），用nginx就完全可以了，如果机器也不少，可以用DNS轮询，lvs所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用lvs。 **************************************************************************************************************** Nginx的优点: 性能好，可以负载超过1万的并发。 功能多，除了负载均衡，还能作Web服务器，而且可以通过Geo模块来实现流量分配。 社区活跃，第三方补丁和模块很多 支持gzip proxy 缺点: 不支持session保持。 对后端realserver的健康检查功能效果不好。而且只支持通过端口来检测，不支持通过url来检测。 nginx对big request header的支持不是很好，如果client_header_buffer_size设置的比较小，就会返回400bad request页面。 Haproxy的优点: 它的优点正好可以补充nginx的缺点。支持session保持，同时支持通过获取指定的url来检测后端服务器的状态。 支持tcp模式的负载均衡。比如可以给mysql的从服务器集群和邮件服务器做负载均衡。 缺点： 不支持虚拟主机(这个很傻啊) 目前没有nagios和cacti的性能监控模板 LVS的优点: 性能好，接近硬件设备的网络吞吐和连接负载能力。 LVS的DR模式，支持通过广域网进行负载均衡。这个其他任何负载均衡软件目前都不具备。 缺点： 比较重型。另外社区不如nginx活跃。 *************************************************************************************现在网络中常见的的负载均衡主要分为两种：一种是通过硬件来进行进行，常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器，也有类似于LVS、Nginx、HAproxy的基于Linux的开源的负载均衡策略, 商用负载均衡里面NetScaler从效果上比F5的效率上更高。对于负载均衡器来说，不过商用负载均衡由于可以建立在四~七层协议之上，因此适用 面更广所以有其不可替代性，他的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用。 另一种负载均衡的方式是通过软件：比较常见的有LVS、Nginx、HAproxy等，其中LVS是建立在四层协议上面的，而另外Nginx和HAproxy是建立在七层协议之上的，下面分别介绍关于 LVS：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。 LVS的特点是： 1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生； 2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率； 3、工作稳定，自身有完整的双机热备方案； 4、无流量，保证了均衡器IO的性能不会收到大流量的影响； 5、应用范围比较广，可以对所有应用做负载均衡； 6、LVS需要向IDC多申请一个IP来做Visual IP，因此需要一定的网络知识，所以对操作人的要求比较高。 Nginx的特点是： 1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构； 2、Nginx对网络的依赖比较小； 3、Nginx安装和配置比较简单，测试起来比较方便； 4、也可以承担高的负载压力且稳定，一般能支撑超过1万次的并发； 5、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测； 6、Nginx对请求的异步处理可以帮助节点服务器减轻负载； 7、Nginx能支持http和Email，这样就在适用范围上面小很多； 8、不支持Session的保持、对Big request header的支持不是很好，另外默认的只有Round-robin和IP-hash两种负载均衡算法。 HAProxy的特点是： 1、HAProxy是工作在网络7层之上。 2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作 3、支持url检测后端的服务器出问题的检测会有很好的帮助。 4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现 5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。 6、HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。 ***********************************************************************************************现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术： 第一阶段：利用Nginx或者HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是 仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或者HAproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就可以。这时是第一选择 第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用F5就是首要选择，Nginx此时就作为LVS或者 F5的节点来使用，具体LVS或者F5的是选择是根据公司规模，人才以及资金能力来选择的，这里也不做详谈，但是一般来说这阶段相关人才跟不上业务的提 升，所以购买商业负载均衡已经成为了必经之路。 第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。 最终形成比较理想的状态为：F5/LVS—Haproxy—Squid/Varnish—AppServer。
如何在Linux上使用HAProxy配置HTTP负载均衡系统
TTP负载均衡简介
HTTP负载均衡是一种网络解决方案，负责在托管相同应用内容的几台服务器之间分配进入的HTTP或HTTPS流量。由于在多台可用服务器之间均衡了应用请求，负载均衡系统就能防止任何应用服务器变成单一故障点，因而提高了整体的应用可用性和响应能力。它还让你可以随着不断变化的工作负载，轻松地缩小/扩大部署的应用系统的规模，只需添加或删除额外的应用服务器。
哪里使用负载均衡、何时使用haproxy健康检查？
由于负载均衡系统改进了服务器的利用率，最大限度地提高了可用性，只要你的服务器开始面临繁重负载，或者正为一个较庞大的项目规划架构，就应该使用它。事先规划好负载均衡系统的用途是个好习惯。那样，未来你需要扩展环境规模时，它会证明其用途。
HAProxy是什么东东？
HAProxy是一种流行的开源负载均衡和代理系统，面向GNU/Linux平台上的TCP/HTTP服务器。HAProxy采用了单一线程的事件驱动型架构而设计，它能够轻松地处理10G网卡线路速度，现广泛应用于许多生产环境中。其功能特性包括：自动检查健康状况、可定制的负载均衡算法、支持HTTPS/SSL以及会话速率限制等。
我们在本教程中要达到什么样的目的？
在本教程中，我们将逐步介绍为HTTP网站服务器配置基于HAProxy的负载均衡系统这个过程。
前提条件
你至少需要一台（最好是两台）网站服务器来证实所搭建负载均衡系统的功能。我们假设，后端HTTP网站服务器已经搭建并运行起来。
将HAProxy安装到Linux上
就大多数发行版而言，我们可以使用你所用发行版的软件包管理器来安装HAProxy。
将HAProxy安装到Debian上
在Debian中，我们需要为Wheezy添加向后移植功能。为此，请在/etc/apt/sources.list.d中创建一个名为“backports.list”的新文件，其内容如下：
deb wheezybackports main
更新你的软件库数据，并安装HAProxy。
# apt get update
# apt get install haproxy
将HAProxy安装到Ubuntu上
# apt get install haproxy
将HAProxy安装到CentOS和RHEL上
# yum install haproxy
配置HAProxy
在本教程中，我们假设有两台HTTP网站服务器已搭建并运行起来，其IP地址分别为192.168.100.2和192.168.100.3。我们还假设，负载均衡系统将在IP地址为192.168.100.4的那台服务器处进行配置。
为了让HAProxy发挥功用，你需要更改/etc/haproxy/haproxy.cfg中的几个项目。这些变更在本章节中予以描述。万一某个配置对不同的GNU/Linux发行版而言有所不同，会在相应段落中加以注明。
1. 配置日志功能
你首先要做的工作之一就是，为你的HAProxy建立合适的日志功能，这对将来进行调试大有用处。日志配置内容位于/etc/haproxy/haproxy.cfg的global部分。下面这些是针对特定发行版的指令，用于为HAProxy配置日志。
CentOS或RHEL：
要想在CentOS/RHEL上启用日志功能，把：
log 127.0.0.1 local2
换成：
log 127.0.0.1 local0
下一步，在/var/log中为HAProxy创建单独的日志文件。为此，我们需要改动当前的rsyslog配置。为了让配置简单而清楚，我们将在/etc/rsyslog.d/中创建一个名为haproxy.conf的新文件，其内容如下。
$ModLoad imudp
$UDPServerRun 514
$template Haproxy,"%msg%\n"
local0.=info /var/log/haproxy.log;Haproxy
local0.notice /var/log/haproxystatus.log;Haproxy
local0.* ~
该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在，重启rsyslog，让变更内容生效。
# service rsyslog restart
Debian或Ubuntu：
要想在Debian或Ubuntu上为HAProxy启用日志功能，把：
log /dev/log local0
log /dev/log local1 notice
换成：
log 127.0.0.1 local0
下一步，为HAProxy配置单独的日志文件，编辑/etc/rsyslog.d/中一个名为haproxy.conf的文件（或者Debian中的49-haproxy.conf），其内容如下。
$ModLoad imudp
$UDPServerRun 514
$template Haproxy,"%msg%\n"
local0.=info /var/log/haproxy.log;Haproxy
local0.notice /var/log/haproxystatus.log;Haproxy
local0.* ~
该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在，重启rsyslog，让变更内容生效。
# service rsyslog restart
2. 设置默认值
下一步是为HAProxy设置默认变量。找到/etc/haproxy/haproxy.cfg中的defaults部分，把它换成下列配置。
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 20000
contimeout 5000
clitimeout 50000
srvtimeout 50000
上述配置推荐HTTP负载均衡器使用，但可能不是最适合你环境的解决方案。如果那样，请参阅HAProxy参考手册页，进行适当的改动和调整。
3. 网站服务器集群的配置
网站服务器集群（Webfarm）的配置定义了可用的HTTP服务器集群。我们所建负载均衡系统的大部分设置都将放在这里。现在，我们将创建一些基本的配置，我们的节点将在这里加以定义。把从frontend部分到文件末尾的所有配置换成下列代码：
listen webfarm *:80
mode http
stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth haproxy:stats
balance roundrobin
cookie LBN insert indirect nocache
option httpclose
option forwardfor
server web01 192.168.100.2:80 cookie node1 check
server web02 192.168.100.3:80 cookie node2 check
“listen webfarm *:80”这一行定义了我们的负载均衡系统将侦听哪些接口。出于本教程的需要，我将该值设为“*”，这让负载均衡系统侦听我们的所有接口。在实际场景下，这可能不合意，应该换成可从互联网来访问的某个接口。
stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth haproxy:stats
上述设置声明，可以在;load-balancer-IP/haproxy?stats处访问负载均衡系统的统计数字。这种访问由简单的HTTP验证以及登录名“haproxy”和密码“stats”来确保安全。这些设置应该换成你自己的登录信息。如果你不想让这些统计数字被人看到，那么可以完全禁用它们。
下面是HAProxy统计数字的一个例子。
“balance roundrobin”这一行定义了我们将使用哪种类型的负载均衡。在本教程中，我们将使用简单的轮叫调度算法，这对HTTP负载均衡来说完全绰绰有余。HAProxy还提供了其haproxy健康检查他类型的负载均衡：
•leastconn：连接数最少的服务器优先接收连接。
•source：对源IP地址进行哈希处理，用运行中服务器的总权重除以哈希值，即可决定哪台服务器将接收请求。
•uri：URI的左边部分（问号前面）经哈希处理，用运行中服务器的总权重除以哈希值。所得结果决定哪台服务器将接收请求。
•url_param：变量中指定的URL参数将在每个HTTP GET请求的查询串中进行查询。你基本上可以将使用蓄意制作的URL（crafted URL）的请求锁定于特定的负载均衡节点。
•hdr(name)：HTTP头name 将在每个HTTP请求中进行查询，被定向到特定节点。
“cookie LBN insert indirect nocache”这一行让我们的负载均衡系统存储持久性cookie，这让我们得以准确查明集群中的哪个节点用于某一个会话。这些节点cookie将与指定的名称一并存储起来。在我们这个例子中，我使用了“LBN”，但你可以指定自己喜欢的任意名称。节点将为该cookie把字符串作为一个值而存储起来。
server web01 192.168.100.2:80 cookie node1 check
server web02 192.168.100.3:80 cookie node2 check
上述部分对网站服务器节点集群进行了定义。每台服务器都用内部名称（比如web01和web02）、IP地址和独特的cookie串来表示。cookie串可以定义为你需要的任何名称。我使用了简单的node1、node2 ... node(n)。
启动HAProxy
你完成了配置工作后，可以启动HAProxy，验证一切按预期运行。
在Centos/RHEL上启动HAProxy
使用下列指令，让HAProxy能够在系统启动后启动，并打开它：
# chkconfig haproxy on
# service haproxy start
当然，别忘了启用防火墙中的端口80，如下所示。
CentOS/RHEL 7上的防火墙：
# firewallcmd permanent zone=public addport=80/tcp
# firewallcmd reload
CentOS/RHEL 6上的防火墙：
把下面这一行添加到/etc/sysconfig/iptables中的这部分“:OUTPUT ACCEPT”：
A INPUT m state state NEW m tcp p tcp dport 80 j ACCEPT
然后重启iptables：
# service iptables restart
在Debian上启动HAProxy
使用下列指令启动HAProxy：
# service haproxy start
别忘了启用防火墙中的端口80，为此把下面这一行添加到/etc/iptables.up.rules：
A INPUT p tcp dport 80 j ACCEPT
在Ubuntu上启动HAProxy
让HAProxy能够在系统启动后启动，只要在/etc/default/haproxy中将“ENABLED”选项设为“1”：
ENABLED=1
启动HAProxy：
# service haproxy start
然后启用防火墙中的端口80：
# ufw allow 80
测试HAProxy
为了检查HAproxy是否在正常工作，我们可以执行下列步骤：
首先，用下列内容准备好test.php文件：
?php
header('Content-Type: text/plain');
echo "Server IP: ".$_SERVER['SERVER_ADDR'];
echo "\nX-Forwarded-for: ".$_SERVER['HTTP_X_FORWARDED_FOR'];
?
该PHP文件将告诉我们哪台服务器（即负载均衡系统）转发请求，哪台后端网站服务器实际处理请求。
把该PHP文件放到这两台后端网站服务器的根目录下。现在，使用curl命令，从负载均衡系统（192.168.100.4）提取这个PHP文件。
$ curl
我们多次运行这个命令时，应该会看到下面两个输出交替出现（由于轮叫调度算法）。
Server IP: 192.168.100.2
X-Forwarded-for: 192.168.100.4
Server IP: 192.168.100.3
X-Forwarded-for: 192.168.100.4
如果我们停止这两台后端网站服务器中的其中一台，curl命令应该仍会执行，将请求定向到另一台可用的网站服务器。
结束语
至此，你应该有了一套完全实用的负载均衡系统，能够在轮叫循环模式下为你的网站节点提供请求。与往常一样，你可以随意更改配置，让它更适合自己的基础设施。希望本教程帮助你让自己的网站项目具有更强的抗压力和更高的可用性。
正如大家已经注意到的那样，本教程所含的设置适用于仅仅一套负载均衡系统。这意味着，我们把一个单一故障点换成了另一个单一故障点。在实际场景下，你应该部署至少两套或三套负载均衡系统，以防范可能出现的任何故障，但这不在本教程的讨论范围之内。
