1.基本配置详解
global # 全局参数global模块的设置
log 127.0.0.1 local2 # log语法：log <address_1>[max_level_1] # 全局的日志配置，使用log关键字，指定使用127.0.0.1上的syslog服务中的local0日志设备，记录日志等级为info的日志
chroot /var/lib/haproxy #工作目录
pidfile /var/run/haproxy.pid #进程pid文件
maxconn 4000 #最大连接数
user haproxy #所属用户
group haproxy #所属用户组
daemon #以守护进程方式运行haproxy
stats socket /var/lib/haproxy/stats #定义socket套接字，针对在线维护很有帮助
defaults # defaults模块的设置
mode http #默认的模式{ tcp|http|health},health只会返回OK
log global #应用全局的日志配置
option httplog #启用日志记录HTTP请求，默认不记录HTTP请求日志
option dontlognull # 启用该项，日志中将不会记录空连接。所谓空连接就是在上游的负载均衡器者监控系统为了探测该 服务是否存活可用时，需要定期的连接或者获取某一固定的组件或页面，或者探测扫描端口是否在监听或开放等动作被称为空连接；官方文档中标注，如果该服务上游没有其他的负载均衡器的话，建议不要使用该参数，因为互联网上的恶意扫描或其他动作就不会被记录下来
option http-server-close #每次请求完毕后主动关闭http通道
option forwardfor except 127.0.0.0/8 #如果服务器上的应用程序想记录发起请求的客户端的IP地址，需要在HAProxy上配置此选项， 这样 HAProxy会把客户端的IP信息发送给服务器，在HTTP 请求中添加"X-Forwarded-For"字段。 启用 X-Forwarded-For，在requests 头部插入客户端IP发送给后端的server，使后端server获取到客户端的真实IP。
option redispatch # 当使用了cookie时，haproxy将会将其请求的后端服务器的serverID插入到cookie中，以保证会话的SESSION持久性；而此时，如果后端的服务器宕掉 了， 但是客户端的cookie是不会刷新的，如果设置此参数，将会将客户的请 求强制定向到另外一个后端server上，以保证服务的正常。
retries 3 # 定义连接后端服务器的失败重连次数，连接失败次数超过此值后将会将对应后端服务器标记为不可用
timeout http-request 10s #http请求超时时间
timeout queue 1m #一个请求在队列里的超时时间
timeout connect 10s #连接超时
timeout client 1m #客户端超时
timeout server 1m #服务器端超时
timeout http-keep-alive 10s #设置http-keep-alive的超时时间
timeout check 10s #检测超时
maxconn 3000 #每个进程可用的最大连接数
listen stats #定义一个listen模块，用于状态检测
mode http #模式采用http
bind 0.0.0.0:8888 #绑定本机的地址及端口
stats enable #启用状态检测功能
stats uri /haproxy-status #状态检测的URI
stats auth haproxy:123456 #访问检测界面的用户名和密码
frontend main *:80 #frontend模块的设置，定义了一个前端
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js #这里定义了一个acl规则
use_backend static if url_static #如果匹配到了acl，则访问后端的static模块
default_backend my_webserver #如果没有匹配到acl，则将请求丢给默认的模块
backend static #定义第一个后端模块，static
balance roundrobin #负载均衡算法为轮询
server static 127.0.0.1:80 check #后端服务器地址
backend my_webserver #定第二个后端，my_wenserver
balance roundrobin #负载均衡算法
server web01 172.31.2.33:80 check inter 2000 fall 3 weight 30 #定义的多个后端
server web02 172.31.2.34:80 check inter 2000 fall 3 weight 30 #定义的多个后端
server web03 172.31.2.35:80 check inter 2000 fall 3 weight 30 #定义的多个后端
Haproxy作为Loadblance，支持对backend的健康检查，以保证在后端backend不能服务时，把从frontend进来的request分配至其他可以服务的backend，从而保证整体服务的可用性。
2. 健康检查相关配置
httpchk <method><uri><version>
option httpchk HEAD / HTTP/1.0
check：启动健康检测
inter：健康检测时间间隔
rise：检测服务可用的连接次数
fall：检测服务不可用的连接次数
error-limit：往server写数据连续失败次数的上限，执行on-error的设定
observe<mode>：把正常服务过程作为健康检测请求，即实时检测
on-error<mode>：满足error-limit后执行的操作（fastinter、fail-check、sudden-death、mark-down）。其中fastinter表示立即按照fastinter的检测延时进行。fail-check表示改次error作为一次检测；sudden-death表示模仿一次fatal，如果紧接着一次fail则server为down；mark-down表示直接把server设置为down状态。
server web-node2 192.168.56.22:8080 check inter 2000 rise 30 fall 15
3. 检测方式
3.1 通过监听端口进行健康检测
这种检测方式，haproxy只会去检查server的端口，并不能保证服务真正可用。
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie serve02 check inter 500 rise 1 fall 2
3.2 通过URI进行健康检测
这种检测方式，是用去GET后端server的web页面，基本可以代表后端服务的可用性。
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk GET /index.html
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie serve02 check inter 500 rise 1 fall 2
3.3 通过request获取的头部信息进行匹配进行健康检测
这种检测方式，是基于一些高级、精细的监测需求，通过对后端头部访问的头部信息进行匹配检测。
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk HEAD /index.jsp HTTP/1.1\r\n\Host:\www.xxx.com
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie serve02 check inter 500 rise 1 fall 2
————Blueicex 2020/03/26 16:38 [email protected]
