HAProxy配置参数说明

一、全局配置
"global"配置中的参数为进程级别的参数，且通常与其运行的OS相关。
1、进程管理及安全相关的参数
chroot <jail dir>
修改haproxy的工作目录至指定的目录并在放弃权限之前执行chroot()操作，可以提升haproxy的安全级别，
不过需要注意的额是要确保指定的目录为空目录并且任何用户均不能有写的权限；
daemon
让haproxy以守护京城的方式工作于后台，其等同于"-D"选项的功能，当然，也可以在命令行中以"-db"选项将其禁用；
gid <number>
以指定的gid运行haproxy；
group <group name>
以指定的组运行haproxy；
uid <number>
以指定的uid运行haproxy；
user <user name>
以指定的用户运行haproxy；
log <address> <facility> [max level [min level]]
定义全局的syslog服务器，最多可以定义两个；
log-send-hostname [<string>]
在syslog信息的首部添加当前主机名，可以为"string"指定的名称，也可以缺省使用当前主机名；
nbproc <number>
指定启动的haproxy进程的个数，只能用于守护进程模式的haproxy；
pidfile path/to/haproxy.pid
指定pidfile的路径
ulimit -n
指定每个进程所能打开的最大文件描述符数量，默认即可；
node
定义当前节点的名称，用户HA场景中多haproxy进程共享同一个IP地址时；
description
当前实例的描述信息

2、性能调整相关的参数
maxconn <number>
指定每个haproxy进程所能接收的最大并发连接数；
maxpipes <number>
haproxy使用pipe完成基于内核的tcp报文重组，此选项则利用设定每个进程所允许使用的最大pipe个数，每个pipe会打开两个文件描述符，
因此，"ulimit -n"自动计算时会根据需要调整；默认为maxconn/4，其通常会显得过大；
noepoll
在linux系统上禁用epoll机制
nokqueue
在BSD系统上禁用kqueue机制
nopoll
禁用poll机制
nosepoll
在linux禁用启发式epoll机制；
nosplice
禁止在linux套接字上使用内核的tcp重组，这会导致更多的recv/send系统调用；
spread-checks <0..50, in percent>
在haproxy 后端有着众多服务器的场景中，在精确的时间间隔后统一对中服务器进行健康状况检查可能会带来意外问题，此选项将其检查的
时间间隔长度增加或减小一定的随机时长；
tune.bufsize <number>
指定buffer的大小，同样的内存条件下，较小的值可以让haproxy有能力接收更多的并发连接，较大的值可以让某些应用程序使用加到的cookie信息，
默认为16384；
tune.chksize <number>
指定检查缓冲区的大小，单位为字节，更大的值有助于在较大的页面中完成基于字符串或模式的文本查找，但也会占用更多的系统资源；
tune.maxaccept <number>
指定haproxy进程内核调度运行时一次性可以接受的连接个数，较大的值可以带来较大的吞吐量，默认在单进程模式下为100，多进程模式下为8，-1为不限制；
tune.maxpollevents <number>
设定一次系统调用可以处理的时间最大数，默认值取决于OS，其值小于200时可以节约带宽，但会略微增大网络延迟，而大于200时会降低延迟，
但会稍稍增加网络带宽的占用量；
tune.maxrewrite <number>
指定为首部重写或追加而预留的缓冲空间，建议使用1024左右的大小，在需要时使用更大的空间，haproxy会自动增加其值；

二、代理相关配置
balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post [<max_wait>]]
定义负载均衡调度算法，可以用于"defaults"、"listen"和"backend"。<algorithm>用于在负载均衡场景中挑选一个server，其仅应用于持久信息不可用的
条件下或需要将一个连接重新派发至另一个服务器时，支持的算法有：
roundrobin：基于权重进行轮叫，在服务器的处理时间保持均匀分布时，这是最平衡、最公平的算法，此算法是动态的，这表示其权重可以在运行时进行调整，
不过，在设计上，每个后端服务器最多接收仅能接收4128个连接；
static-rr：基于权重进行轮叫，与roundrobin类似，但是为静态方法，在运行时调整其服务器权重不会生效，不过，其在后端的连接数上是没有现制定的；
leastconn：新的连接请求被派发至具有最少连接数目的后端服务器，有着较长时间绘画的场景中推荐使用的算法，如LDAP,SQL等，并不太使用较短会话的应用
层协议，如HTTP，此算法是动态，可以在运行时调整其权重；
source：将请求的源地址进行hash运算，并由后端服务器的权重总数相除后派发至某匹配的服务器，这可以使得同一客户端IP的请求始终被派发至某特定的服务器
常用语负载均衡无cookie功能的基于TCP的协议，其默认为静态，不过也可以使用hash-type修改此特性；
hash-type：
    map-base：取模法，静态
    consisitent：一致性哈希，动态
uri：对URI的左半部分("问题"标记之前的部分)或整个URI进行hash计算，并由服务器的总权重相除后派发至某匹配的服务器，这可以使得对同一个URI的请求是被
派发至某特定的服务器，除非服务器的权重总数发生了变化，此算法常用语代理缓存或反病毒代理以提高缓存的命中率，需要注意的是，此算法仅应用于HTTP后端
服务器场景，其默认为静态算法，不过也可以使用hash-type修改此特性；
url_param：通过<argument>为URL指定的参数在每个HTTP GET请求中将会被检索，如果找到了指定的参数且其通过等于号"="被赋予了一个值，那么此值将被执行
hash运算并被服务器的总权重相除后派发至某匹配的服务器，此算法可以通过追踪请求中的用户标识而且确保同一个用户ID的请求被送往统一特定的服务器，除非
服务器的总权重发生了裱花，如果某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度，此算法默认为静态，可使用hash-type修改；
hdr(<name>)：对于每个HTTP请求，通过<name>指定的HTTP首部将被检索，如果对应的首部没有出现或其没有有效值，则使用轮叫算法对相应的请求进行调度，
其中一个可选选项"use_domain_only",可在指定检索类似host类的首部时仅计算域名部分以降低hash算法的运算量，此算法默认伪静态，可调整；
根据请求报文中指定的header(如user_agent,referer,hostname)进行调度，把指定的header的值做hash计算
bind
bind [<address>]:<port_range>
只能用于frontend，listen
mode
HAProxy的工作模式；默认tcp
    tcp,http,health
maxconn <conns>
设定一个前端的最大并发连接数，因此，其不能用于backend区段，对于大型站点来说，可以尽可能提高此值以便让haproxy管理连接队列，从而避免无法响应用户
请求，此值不能超出"global"段中的定义，此外，需要注意的是，haproxy会为每个连接维持两个缓冲，每个缓冲的大小为8KB，再加上其他数据，每个连接将大约
占用17KB的RAM空间，这意味着经过适当优化后，有这1G的可用RAM空间时将能维护40000-50000并发连接。默认为2000；
server
server <name> <addr>[:port] [param*]
    backup:设定当前server为backup server；
    check：健康状态检测
        inter <delay>:设定健康状态检查的时间间隔，单位为毫秒，默认为2000；
        rise <count>:设定健康状态检查中，某离线的server从离线状态转移至正常状态需要成功检查的次数；
        fall <count>:确认server从正常状态装换为不可用转台需要检查的次数；
    cookie <value>:为指定server设定cookie值，此处指定的值将在请求入站是被检查，第一次为此值挑选的server将在后续的请求中被选中，
                    其目的在于实现持久连接的功能；
    maxconn <maxconn>:指定此服务器接收的最大并发连接数，如果发往此服务器的连接数高于此处指定的值，其将被放置于请求队列；
    maxqueue <maxqueue>:设定请求队列的最大长度；
    observe <mode>
    通过观察服务器的通信状况来判定其健康状态，默认为禁用，其支持的类型有"layer4"和layer7"，"layer7"仅能用于http代理场景；
    redir <prefix>
    启用重定向功能，将发往此服务器的GET和HEAD请求均匀以302状态码响应，需要注意的是prefix后面不能使用/，且不能用相对地址，
    以免造成循环，例如:
        server web1 192.168.1.111:80 redir http://img.fansik.com check
    weight <weight>:权重，默认为1，最大值为256,0表示不参与负载均衡；
检查方法：
option httpchk
option httpchk <uri>
option httpchk <method> <uri>
option httpchk <method> <uri> <version>
不能用于frontend段，例如：
backend https_relay
    mode tcp
    option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www.fansik.com
    server web1 192.168.1.111:443 check port 80
使用案例：
server first 192.168.1.110:80 cookie first check inter 1000
server second 192.168.1.184:80 cookie second check inter 1000
基于浏览器cookie实现session sticky
    backend webserver
        balance     roundrobin
        cookie      fansik insert nocache indirect
        server      web1 192.168.1.110:80 check weight 1 cookie web1
        server      web2 192.168.1.184:80 check weight 3 cookie web2
    要点：
        (1)每个server有自己唯一的cookie表示；
        (2)在backend中定义为用户请求调度完成后操纵其cookie；
　　如图：