haproxy nginx 性能对比 nginx和haproxy哪个好

Nginx和Haproxy负载均衡小结

Nginx

Nginx是俄罗斯人编写的十分轻量级的HTTP服务器，是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP 代理服务器。Nginx以事件驱动的方式编写，所以有非常好的性能，同时也是一个非常高效的反向代理、负载平衡。

Nginx因为它的稳定性、丰富的模块库、灵活的配置和低系统资源的消耗而闻名。业界一致认为它是Apache2.2＋mod_proxy_balancer的轻量级代替者，不仅是因为响应静态页面的速度非常快，而且它的模块数量达到Apache的近2/3。对proxy和rewrite模块的支持很彻底，还支持mod_fcgi、ssl、vhosts ，适合用来做mongrel clusters的前端HTTP响应。

Nginx专为性能优化而开发，可以支持高并发连接。性能是其最重要的考量，实现上非常注重效率，处理响应请求很快 。它支持内核Poll模型，能经受高负载的考验,有报告表明能支持高达 50,000个并发连接数。

Nginx具有很高的稳定性。其它HTTP服务器，当遇到访问的峰值，或者有人恶意发起慢速连接时，也很可能会导致服务器物理内存耗尽频繁交换，失去响应，只能重启服务器。例如当前apache一旦上到200个以上进程，web响应速度就明显非常缓慢了。而Nginx采取了分阶段资源分配技术，使得它的CPU与内存占用率非常低。nginx官方表示保持10,000个没有活动的连接，它只占2.5M内存，所以类似DOS这样的攻击对nginx来说基本上是毫无用处的。

Nginx支持热部署。它的启动特别容易, 并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动。你还能够在不间断服务的情况下，对软件版本进行进行升级。

Nginx配置简单，只需要修改conf下的nginx.conf文件就行，也就几十行配置，简单的十几行就能搞定。

安装、启动和停止Nginx

1. 安装一些插件
yum -y install gcc
yum install -y pcre pcre-devel
yum install -y zlib zlib-devel
yum install -y openssl openssl-devel
2. 下载和安装Nginx
wget http://nginx.org/download/nginx-1.9.9.tar.gz  
tar -zxvf  nginx-1.9.9.tar.gz
cd nginx-1.9.9/
./configure
make
make install

• 启动Nginx：./nginx
• 停止Nginx：nginx -s stop
• 修改配置后重启：nginx -s reload

Nginx配置文件解析

在conf/nginx.conf文件中进行Nginx服务器配置，这是一个demo用作解释配置用法

########### 每个指令必须有分号结束。#################
#user administrator administrators;  #配置用户或者组，默认为nobody nobody。
#worker_processes 2;  #允许生成的进程数，默认为1
#pid /nginx/pid/nginx.pid;   #指定nginx进程运行文件存放地址
error_log log/error.log debug;  #制定日志路径，级别。这个设置可以放入全局块，http块，server块，级别以此为：debug|info|notice|warn|error|crit|alert|emerg
events {
    accept_mutex on;   #设置网路连接序列化，防止惊群现象发生，默认为on
    multi_accept on;  #设置一个进程是否同时接受多个网络连接，默认为off
    #use epoll;      #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport
    worker_connections  1024;    #最大连接数，默认为512
}
http {
    include       mime.types;   #文件扩展名与文件类型映射表
    default_type  application/octet-stream; #默认文件类型，默认为text/plain
    #access_log off; #取消服务日志    
    log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定义格式
    access_log log/access.log myFormat;  #combined为日志格式的默认值
    sendfile on;   #允许sendfile方式传输文件，默认为off，可以在http块，server块，location块。
    sendfile_max_chunk 100k;  #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限。
    keepalive_timeout 65;  #连接超时时间，默认为75s，可以在http，server，location块。

    upstream mysvr {   
      server 127.0.0.1:7878;
      server 192.168.10.121:3333 backup;  #热备
    }
	
    error_page 404 https://www.baidu.com; #错误页
    server {
        keepalive_requests 120; #单连接请求上限次数。
        listen       4545;   #监听端口
        server_name  127.0.0.1;   #监听地址       
        location  ~*^.+$ {       #请求的url过滤，正则匹配，~为区分大小写，~*为不区分大小写。
           #root path;  #根目录
           #index vv.txt;  #设置默认页
           proxy_pass  http://mysvr;  #请求转向mysvr 定义的服务器列表
           deny 127.0.0.1;  #拒绝的ip
           allow 172.18.5.54; #允许的ip           
        } 
    }
}

Nginx的负载均衡配置

以下例子中的IP在使用时换上自己需要进行轮询分配的服务器IP

• 轮询（默认）

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

有以下参数可以配合一起使用

参数名	说明
fail_timeout	与max_fails结合使用。
max_fails	设置在fail_timeout参数设置的时间内最大失败次数，如果在这个时间内，所有针对该服务器的请求都失败了，那么认为该服务器会被认为是停机了。
fail_time	服务器会被认为停机的时间长度,默认为10s。
backup	标记该服务器为备用服务器。当主服务器停止时，请求会被发送到它这里。
down	标记服务器永久停机了。

例子：

upstream backserver { 
    server 192.168.0.14 max_fails=3 fail_timeout=20s; 
	server 192.168.0.15 down; 
    server 192.168.0.16 backup; 
}

• 指定权重

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

weight参数用于指定轮询几率，weight的默认值为1，权重越高分配到需要处理的请求越多

upstream backserver { 
    server 192.168.0.14; 
    server 192.168.0.15 weight=10; 
}

• IP绑定 ip_hash

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

ip_hash不能与backup同时使用，当有服务器需要剔除，必须手动down掉。

upstream backserver { 
    ip_hash; 
    server 192.168.0.14:80; 
    server 192.168.0.15:80; 
}

• least_conn

把请求转发给连接数较少的后端服务器，解决轮询算法是把请求平均的转发给各个后端从而会导致有些请求占用的时间很长负载较高的问题。这种策略适合请求处理时间长短不一造成服务器过载的情况。

upstream backserver {
    least_conn;
    server 192.168.0.14:80; 
    server 192.168.0.15:80; 
}

• fair

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

upstream backserver { 
    server server1; 
    server server2; 
    fair; 
}

• url_hash

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

upstream backserver { 
    server squid1:3128; 
    server squid2:3128; 
    hash $request_uri; 
    hash_method crc32; 
}

Nginx的反向代理配置

#其他页面反向代理到tomcat容器
server {     
    location  ~*^.+$ {       #请求的url过滤，正则匹配，~为区分大小写，~*为不区分大小写。
        #root path;  #根目录
        #index vv.txt;  #设置默认页
        proxy_pass http://backserver/;  #请求转向backserver定义的服务器列表
        deny 127.0.0.1;  #拒绝的ip
        allow 0.0.0.0; #允许的ip   
        index index.jsp index.html;
    } 
}
upstream backserver{ 
    ip_hash; 
    server 127.0.0.1:9090 down; (down 表示当前的server暂时不参与负载) 
    server 127.0.0.1:8080 weight=2; (weight 默认为1.weight越大，负载的权重就越大) 
    server 127.0.0.1:6060; 
    server 127.0.0.1:7070 backup; (其它所有的非backup机器down或者忙的时候，请求backup机器) 
}

Haproxy

HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。根据官方数据，其最高极限支持10G的并发。

HAProxy特别适用于那些负载特大的web站点， 这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。

HAProxy支持从4层至7层的网络交换，即覆盖所有的TCP协议。就是说，Haproxy还支持 Mysql的均衡负载。

**功能上的相同点：**Haproxy 通过反向代理方式实现 WEB均衡负载，和 Nginx，ApacheProxy，Cheroke 等一样。

**功能上的不同点：**Haproxy 并不是 web 服务器。以上提到所有带反向代理均衡负载的产品，都是 WEB 服务器。简单说，就是他们能处理解析页面的。而Haproxy 仅仅是一款的用于均衡负载的应用代理，自身并不能提供web服务。但其配置简单，拥有非常不错的服务器健康检查功能还有专门的系统状态监控页面，当其代理的后端服务器出现故障，HAProxy会自动将该服务器摘除，故障恢复后再自动将该服务器加入。

Haproxy的一些特点

• 支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；
• 能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作
• 支持url检测后端的服务器出问题的检测会有很好的帮助。
• 和Nginx相比，还有更多的负载均衡策略：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)
• 从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
• HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。
• 不能做Web服务器即Cache。

解释一下四层负载均衡和七层负载均衡

四层负载均衡

以常见的 TCP 应用为例，负载均衡器在接收到第一个来自客户端的 SYN 请求时，会通过设定的负载均衡算法选择一个最佳的后端服务器，同时将报文中目标 IP 地址修改为后端服务器 IP，然后直接转发给该后端服务器，这样一个负载均衡请求就完成了。从这个过程来看，一个 TCP 连接是客户端和服务器直接建立的，而负载均衡器只不过完成了一个类似路由器的转发动作。在某些负载均衡策略中，为保证后端服务器返回的报文可以正确传递给负载均衡器，在转发报文的同时可能还会对报文原来的源地址进行修改。

七层负载均衡

这里仍以常见的 TCP 应用为例，由于负载均衡器要获取到报文的内容，因此只能先代替后端服务器和客户端建立连接，接着，才能收到客户端发送过来的报文内容，然后再根据该报文中特定字段加上负载均衡器中设置的负载均衡算法来决定最终选择的内部服务器。纵观整个过程，七层负载均衡器在这种情况下类似于一个代理服务器。

对比

对比四层负载均衡和七层负载均衡运行的整个过程，可以看出，在七层负载均衡模式下， 负载均衡器与客户端及后端的服务器会分别建立一次 TCP 连接，而在四层负载均衡模式下， 仅建立一次 TCP 连接。由此可知，七层负载均衡对负载均衡设备的要求更高，而七层负载均衡的处理能力也必然低于四层模式的负载均衡。

Haproxy安装、启动

1. 官网下载，需要f墙，不多做说明
2. 安装
tar zxvf haproxy-1.8.13.tar.gz
cd haproxy-1.8.13/
make TARGET=linux31   
说明：这里需要使用uname -r查看系统版本centos6.X需要使用TARGET=linux26  centos7.x使用linux31
uname -r   #查询系统内核版本
make install PREFIX=/usr/local/haproxy
mkdir /usr/local/haproxy/conf
cp examples/option-http_proxy.cfg /usr/local/haproxy/conf/haproxy.cfg
3. 启动
/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg

Haproxy的负载均衡算法

• roundrobin：表示简单的轮询，这个不多说，这个是负载均衡基本都具备的
• static-rr：表示根据权重
• leastconn：表示最少连接者先处理
• source：表示根据请求源IP，这个跟Nginx的IP_hash机制类似，作为解决session问题的一种方法
• uri：表示根据请求的URI
• url_param：表示根据请求的URl参数
• hdr(name)：表示根据HTTP请求头来锁定每一次HTTP请求
• rdp-cookie(name)：表示根据cookie(name)来锁定并哈希每一次TCP请求

Haproxy配置文件

以下是Haproxy的核心配置文件，每个版本的格式存在部分差异，按需配置，谨慎复制

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    log    127.0.0.1 local2          ###[err warning info debug] 
    chroot  /usr/local/haproxy
    pidfile  /var/run/haproxy.pid   ###haproxy的pid存放路径,启动进程的用户必须有权限访问此文件 
    maxconn  4000                   ###最大连接数，默认4000
    user   haproxy
    group   haproxy
    daemon                          ###创建1个进程进入deamon模式运行。此参数要求将运行模式设置为"daemon"
 
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will 
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode   http             ###默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK
    log    global           ###采用全局定义的日志
    option  dontlognull     ###不记录健康检查的日志信息
    option  httpclose       ###每次请求完毕后主动关闭http通道 
    option  httplog         ###日志类别http日志格式 
    option  forwardfor      ###如果后端服务器需要获得客户端真实ip需要配置的参数，可以从Http Header中获得客户端ip  
    option  redispatch      ###serverId对应的服务器挂掉后,强制定向到其他健康的服务器
    timeout connect 10000   #default 10 second timeout if a backend is not found
    timeout client 300000   ###客户端连接超时
    timeout server 300000   ###服务器连接超时
    maxconn     60000       ###最大连接数
    retries     3           ###3次连接失败就认为服务不可用，也可以通过后面设置 
####################################################################
listen stats
        bind 0.0.0.0:1080           #监听端口  
        stats refresh 30s           #统计页面自动刷新时间  
        stats uri /stats            #统计页面url  
        stats realm Haproxy Manager #统计页面密码框上提示文本  
        stats auth admin:admin      #统计页面用户名和密码设置  
        #stats hide-version         #隐藏统计页面上Haproxy的版本信息
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend main
    bind 0.0.0.0:80
    acl url_static path_beg    -i /static /images /javascript /stylesheets
    acl url_static path_end    -i .jpg .gif .png .css .js
 
    use_backend static if url_static     ###满足策略要求，则响应策略定义的backend页面
    default_backend   dynamic            ###不满足则响应backend的默认页面
 
#---------------------------------------------------------------------
# static backend for serving up images, stylesheets and such
#---------------------------------------------------------------------
 
backend static
    balance     roundrobin                 ###负载均衡模式轮询
    server      static 127.0.0.1:80 check ###后端服务器定义
     
backend dynamic
    balance    roundrobin
    server         websrv1 10.252.97.106:80 check maxconn 2000
    server         websrv2 10.117.8.20:80 check maxconn 2000
 
#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
#errorloc  503  http://www.osyunwei.com/404.html
errorfile 403 /etc/haproxy/errorfiles/403.http
errorfile 500 /etc/haproxy/errorfiles/500.http
errorfile 502 /etc/haproxy/errorfiles/502.http
errorfile 503 /etc/haproxy/errorfiles/503.http
errorfile 504 /etc/haproxy/errorfiles/504.http

Haproxy 配置文件根据功能和用途，主要有 5 个部分组成，但有些部分并不是必须的， 可以根据需要选择相应的部分进行配置。

global 部分

用来设定全局配置参数，属于进程级的配置，通常和操作系统配置有关。

• log：全局的日志配置，local0 是日志设备，info 表示日志级别。其中日志级别有err、warning、info、debug 四种可选。这个配置表示使用 127.0.0.1 上的 rsyslog 服务中的local0 日志设备，记录日志等级为info。
• maxconn：设定每个 haproxy 进程可接受的最大并发连接数，此选项等同于 Linux命令行选项“ulimit -n”。
• user/ group：设置运行 haproxy 进程的用户和组，也可使用用户和组的 uid 和gid 值来替代。
• daemon：设置 Haproxy 进程进入后台运行。这是推荐的运行模式。
• nbproc：设置 Haproxy 启动时可创建的进程数，此参数要求将Haproxy 运行模式设置为“daemon”，默认只启动一个进程。根据使用经验，该值的设置应该小于服务器的 CPU 核数。创建多个进程，能够减少每个进程的任务队列，但是过多的进程可能会导致进程的崩溃。
• pidfile：指定 Haproxy 进程的 pid 文件。启动进程的用户必须有访问此文件的权限。

defaults 部分

默认参数的配置部分。在此部分设置的参数值，默认会自动被引用到下面的 frontend、backend 和 listen 部分中，因此，如果某些参数属于公用的配置，只需在 defaults 部分添加一次即可。而如果在 frontend、backend 和 listen 部分中也配置了与 defaults 部分一样的参数，那么defaults 部分参数对应的值自动被覆盖。

• mode：设置 Haproxy 实例默认的运行模式，有 tcp、http、health 三个可选值。

运行模式	说明
tcp 模式	在此模式下，客户端和服务器端之间将建立一个全双工的连接，不会对七层报文做任何类型的检查，默认为 tcp 模式，经常用于 SSL、SSH、SMTP 等应用。
http 模式	在此模式下，客户端请求在转发至后端服务器之前将会被深度分析，所有不与 RFC 格式兼容的请求都会被拒绝。
health 模式	目前此模式基本已经废弃。

• retries：设置连接后端服务器的失败重试次数，连接失败的次数如果超过这里设置的值，Haproxy 会将对应的后端服务器标记为不可用。此参数也可在后面部分进行设置。
• timeout connect：设置成功连接到一台服务器的最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。
• timeout client：设置连接客户端发送数据时最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。
• timeout server：设置服务器端回应客户度数据发送的最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。
• timeout check：设置对后端服务器的检测超时时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

frontend 部分

此部分用于设置接收用户请求的前端虚拟节点。frontend 是在 Haproxy1.3 版本之后才引入的一个组件，同时引入的还有 backend 组件。通过引入这些组件，在很大程度上简化了 Haproxy 配置文件的复杂性。frontend 可以根据 ACL 规则直接指定要使用的后端

• bind：此选项只能在 frontend 和 listen 部分进行定义，用于定义一个或几个监听的套接字。bind 的使用格式为:bind [ :<port_range>] interface 其中，address 为可选选项，其可以为主机名或IP 地址，如果将其设置为“*”或“0.0.0.0”，将监听当前系统的所有 IPv4 地址。port_range 可以是一个特定的 TCP 端口，也可是一个端口范围，小于 1024 的端口需要有特定权限的用户才能使用。interface 为可选选项，用来指定网络接口的名称，只能在 Linux 系统上使用。
• option httplog：在默认情况下，haproxy 日志是不记录 HTTP 请求的，这样很不方便 Haproxy 问题的排查与监控。通过此选项可以启用日志记录 HTTP 请求。
• option forwardfor：如果后端服务器需要获得客户端的真实IP，就需要配置此参数。由于 Haproxy 工作于反向代理模式，因此发往后端真实服务器的请求中的客户端 IP 均为 Haproxy 主机的 IP，而非真正访问客户端的地址，这就导致真实服务器端无法记录客户端真正请求来源的 IP，而“X-Forwarded-For”则可用于解决此问题。通过使用“forwardfor”选项，Haproxy 就可以向每个发往后端真实服务器的请求添加“X-Forwarded-For”记录，这样后端真实服务器日志可以通过“X-Forwarded-For”信息来记录客户端来源 IP。
• option httpclose：此选项表示在客户端和服务器端完成一次连接请求后，Haproxy 将主动关闭此 TCP 连接。这是对性能非常有帮助的一个参数。
• log global：表示使用全局的日志配置，这里的“ global”表示引用在Haproxy 配置文件 global 部分中定义的 log 选项配置格式。
• default_backend：指定默认的后端服务器池，也就是指定一组后端真实服务器，而这些真实服务器组将在 backend 段进行定义。这里的htmpool 就是一个后端服务器组。

backend 部分

此部分用于设置集群后端服务集群的配置，也就是用来添加一组真实服务器，以处理前端用户的请求。添加的真实服务器类似于 LVS 中的real server 节点。

• option redispatch：此参数用于 cookie 保持的环境中。在默认情况下，Haproxy会将其请求的后端服务器的 serverID 插入到 cookie 中，以保证会话的 SESSION 持久性。而如果后端的服务器出现故障，客户端的 cookie 是不会刷新的，这就出现了问题。此时，如果设置此参数，就会将客户的请求强制定向到另外一个健康的后端服务器上，以保证服务的正常。
• option abortonclose：如果设置了此参数，可以在服务器负载很高的情况下， 自动结束掉当前队列中处理时间比较长的链接。
• balance：此关键字用来定义负载均衡算法。目前 Haproxy 支持多种负载均衡算法，常用的有如下几种：

算法	说明
roundrobin	是基于权重进行轮询调度的算法，在服务器的性能分布比较均匀的时候，这是一种最公平、最合理的算法。此算法经常使用。
static-rr	也是基于权重进行轮询的调度算法，不过此算法为静态方法，在运行时调整其服务器权重不会生效。
source	是基于请求源 IP 的算法。此算法先对请求的源 IP 进行 hash 运算， 然后将结果与后端服务器的权重总数相除后转发至某个匹配的后端服务器。这种方式可以使同一个客户端 IP 的请求始终被转发到某特定的后端服务器。
leastconn	此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法，例如数据库负载均衡等。此算法不 适合会话较短的环境中，例如基于 HTTP 的应用。
uri	此算法会对部分或整个 URI 进行 hash 运算，再经过与服务器的总权重相除，最后转发到某台匹配的后端服务器上。
uri_param	此算法会根据 URL 路径中的参数进行转发，这样可保证在后端真实服务器数量不变时，同一个用户的请求始终分发到同一台机器上。
hdr(name):	此算法根据 http 头进行转发，如果指定的 http 头名称不存在，则使用 roundrobin 算法进行策略转发。

• cookie：表示允许向 cookie 插入 SERVERID，每台服务器的 SERVERID 可在下面的 server 关键字中使用 cookie 关键字定义。
• option httpchk：此选项表示启用 HTTP 的服务状态检测功能。Haproxy 作为一款专业的负载均衡器，它支持对 backend 部分指定的后端服务节点的健康检查，以保证在后端 backend 中某个节点不能服务时，把从 frotend 端进来的客户端请求分配至 backend 中其他健康节点上，从而保证整体服务的可用性。“option httpchk”的用法如下：option httpchk 其中，各个参数的含义如下：

参数	含义
method	表示 HTTP 请求的方式，常用的有 OPTIONS、GET、HEAD 几种方式。一般的健康检查可以采用 HEAD 方式进行，而不是才采用 GET 方式，这是因为 HEAD 方式没有数据返回，仅检查 Response 的 HEAD 是不是 200 状态。因此相对与 GET 来说，HEAD 方式更快，更简单。
uri	表示要检测的 URL 地址，通过执行此 URL，可以获取后端服务器的运行状态。在正常情况下将返回状态码 200，返回其他状态码均为异常状态。
version	指定心跳检测时的 HTTP 的版本号。

• server：这个关键字用来定义多个后端真实服务器，不能用于 defaults 和frontend部分。使用格式为：server [:port] [param*] 其中，每个参数含义如下：

参数	含义
name	为后端真实服务器指定一个内部名称，随便定义一个即可。
address	后端真实服务器的 IP 地址或主机名。
port	指定连接请求发往真实服务器时的目标端口。在未设定时，将使用客户端请求时的同一端口。
[param*]	为后端服务器设定的一系参数，可用参数非常多，这里仅介绍常用的一些参数

[param*]常用参数	说明
check	表示启用对此后端服务器执行健康状态检查。
inter	设置健康状态检查的时间间隔，单位为毫秒。
rise	设置从故障状态转换至正常状态需要成功检查的次数，例如。“rise 2”表示 2 次检查正确就认为此服务器可用。
fall	设置后端服务器从正常状态转换为不可用状态需要检查的次数，例如，“fall 3”表示 3 次检查失败就认为此服务器不可用。
cookie	为指定的后端服务器设定 cookie 值，此处指定的值将在请求入站时被检查，第一次为此值挑选的后端服务器将在后续的请求中一直被选中，其目的在于实现持久连接的功能。上面 的“cookie server1”表示 web1 的 serverid 为 server1。同理， “cookie server2”表示 web2 的 serverid 为 server2。
weight	设置后端真实服务器的权重，默认为 1，最大值为 256。设置为 0 表示不参与负载均衡。
backup	设置后端真实服务器的备份服务器，仅仅在后端所有真实服务器均不可用的情况下才启用。

listen 部分

此部分是 frontend 部分和 backend 部分的结合体。在 Haproxy1.3 版本之前，Haproxy 的所有配置选项都在这个部分中设置。为了保持兼容性，Haproxy 新的版本仍然保留了 listen 组件的配置方式。目前在 Haproxy 中，两种配置方式任选其一即可。

• stats refresh：设置 Haproxy 监控统计页面自动刷新的时间。
• stats uri：设置 Haproxy 监控统计页面的URL 路径，可随意指定。例如、指定“stats uri /haproxy-status”，就可以过 http://IP:9188/haproxy-status 查看。
• stats realm：设置登录 Haproxy 统计页面时密码框上的文本提示信息。
• stats auth：设置登录 Haproxy 统计页面的用户名和密码。用户名和密码通过冒号分割。可为监控页面设置多个用户名和密码，每行一个。
• stats hide-version：用来隐藏统计页面上 Haproxy 的版本信息。
• stats admin if TRUE：通过设置此选项，可以在监控页面上手工启用或禁用后端真实服务器，仅在 haproxy1.4.9 以后版本有效。

参考博文

【1】Nginx服务器之负载均衡策略（6种）

【2】使用Haproxy+nginx 搭建负载均衡集群

【3】如何用Haproxy+nginx实现负载均衡

【4】haproxy安装配置(笔记一)