Haproxy简介 HAProxy提供高可用、负载均衡以及基于TCP和HTTP的应用代理，适合处理高负载站点的七层数据请求。类似的代理服务可以屏蔽内部真实服务器，防止内部服务器遭受***。 HAProxy特点和优点： 1.支持原声SSL,同时支持客户端和服务器的SSL. 2.支持IPv6和UNIX套字节（sockets） 3.支持HTTP Keep-Alive 4.支持HTTP/1.1压缩，节省宽带 5.支持优化健康检测机制（SSL、scripted TCP、check agent...） 6.支持7层负载均衡。 7.可靠性和稳定性非常好。 8.并发连接40000-50000个，单位时间处理最大请求20000个，最大数据处理10Gbps. 9.支持8种负载均衡算法，同时支持session保持。 10.支持虚拟主机。 11.支持连接拒绝、全透明代理。 12.拥有服务器状态监控页面。 13.支持ACL.
1、支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机； 2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作 3、支持url检测后端的服务器出问题的检测会有很好的帮助。 4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现 5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。 6、HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。 9、支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie） 10、不能做Web服务器即Cache。 https://blog.csdn.net/HzSunshine/article/details/61671730
2.配置文件 HAProxy配置中分五大部分： global： 全局配置参数，进程级的，用来控制Haproxy启动前的一些进程及系统设置 defaults： 配置一些默认的参数，可以被frontend，backend，listen段继承使用 frontend： 用来匹配接收客户所请求的域名，uri等，并针对不同的匹配，做不同的请求处理 backend： 定义后端服务器集群，以及对后端服务器的一些权重、队列、连接数等选项的设置，我将其理解为Nginx中的upstream块 listen： frontend和backend的组合体
日志配置： 日志的level: local0～local7 16～23保留为本地使用 emerg 0 系统不可用 alert 1 必须马上采取行动的事件 crit 2 关键的事件 err 3 错误事件 warning 4 警告事件 notice 5 普通但重要的事件 info 6 有用的信息 debug 7 调试信息 ----------------------------------------------------------------------- #全局配置 global log 127.0.0.1 local2 #全局的日志配置，使用log关键字，指定使用127.0.0.1上的syslog服务中的local0日志设备，记录日志等级为info的日志 chroot /var/lib/haproxy #修改haproxy的工作目录至指定目录并在放弃权限前执行chroot()操作，可以提升haproxy安全级别 pidfile /var/run/haproxy.pid maxconn 4096 # 定义每个haproxy进程的最大连接数 ，由于每个连接包括一个客户端和一个服务器端，所以单个进程的TCP会话最大数目将是该值的两倍，需考虑ulimit-n限制，默认4096 user haproxy # group haproxy #设置运行haproxy的用户和组，也可使用uid，gid关键字替代 daemon #以守护进程的方式运行 nbproc 1 # 设置haproxy启动时的进程数，根据官方文档的解释，我将其理解为：该值的设置应该和服务器的CPU核心数一致；创建多个进程数，可以减少每个进程的任务队列，但是过多的进程数也可能会导致进程的崩溃 stats socket /var/lib/haproxy/stats
defaults mode http # mode语法：mode {http|tcp|health} 。http是七层模式，tcp是四层模式，health是健康检测，返回OK log global option httplog # 启用日志记录HTTP请求，默认haproxy日志记录是不记录HTTP请求的，只记录“时间[Jan 5 13:23:46] 日志服务器[127.0.0.1] option dontlognull #启用该项，日志中将不会记录空连接。所谓空连接就是在上游的负载均衡器或者监控系统为了探测该服务是否存活可用时，需要定期的连接或者获取某一固定的组件或页面，或者探测扫描端口是否在监听或开放等动作被称为空连接； #官方文档中标注，如果该服务上游没有其他的负载均衡器的话，建议不要使用该参数，因为互联网上的恶意扫描或其他动作就不会被记录下来# option http-server-close #每次请求完毕后主动关闭http通道,haproxy不支持keep-alive,只能模拟这种模式的实现 option forwardfor except 127.0.0.0/8 option redispatch #当使用了cookie时，haproxy将会将其请求的后端服务器的serverID插入到cookie中，以保证会话的SESSION持久性；而此时，如果后端的服务器宕掉了，但是客户端的cookie是不会刷新的，如果设置此参数，将会将客户的请求强制定向到另外一个后端server上，以保证服务的正常，可定义到default模块 retries 3 # 定义连接后端服务器的失败重连次数，连接失败次数超过此值后将会将对应后端服务器标记为不可用 timeout http-request 10s #默认http请求超时时间 timeout queue 1m #默认队列超时时间 timeout connect 10s #连接超时 timeout client 1m #客户端超时 timeout server 1m #服务器超时 timeout http-keep-alive 10s #长连接超时时间 timeout check 10s #心跳检测超时 maxconn 4096 #默认的最大连接数
#frontend前端配置 frontend main *:5000 #监听地址端口5000 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 #如果上面定义的web规则被触发，请求发到static default_backend app #指定后端服务池，将对应的请求转发给后端
backend static #静态/动态资源分离 balance roundrobin #balance roundrobin 负载轮询，balance source 保存session值，支持static-rr，leastconn，first，uri等参数 server static 127.0.0.1:4331 check
#backend后端配置
backend app #后端
balance roundrobin #负载均衡方式，使用随机
server app1 127.0.0.1:5001 check #后端服务器
server app2 127.0.0.1:5002 check
server app3 127.0.0.1:5003 check
server app4 127.0.0.1:5004 check
server web03 127.0.0.1:5005 check inter 2000 fall 3 weight 30
#更详细的权重定义,check inter 2000 是检测心跳频率
#rise 2是2次正确认为服务器可用，fall 3是3次失败认为服务器不可用，weight代表权重
负载均衡： 一、roundrobin，表示简单的轮询，每个服务器根据权重轮流使用，在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。
二、static-rr，表示根据权重，建议关注；每个服务器根据权重轮流使用，类似roundrobin，但它是静态的，意味着运行时修改权限是无效的。另外，它对服务器的数量没有限制。
三、leastconn，表示最少连接者先处理，建议关注；leastconn建议用于长会话服务，例如LDAP、SQL、TSE等，而不适合短会话协议。如HTTP.该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。
四、source，表示根据请求源IP，建议关注；对请求源IP地址进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化，那么客户端会定向到不同的服务器； 该算法一般用于不能插入cookie的Tcp模式。它还可以用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
五、uri，表示根据请求的URI；表示根据请求的URI左端（问号之前）进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个URI地址总是访问同一个服务器。一般用于代理缓存和反病毒代理，以最大限度的提高缓存的命中率。该算法只能用于HTTP后端；该算法一般用于后端是缓存服务器；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
六、url_param，表示根据请求的URl参数'balance url_param' requires an URL parameter name,在HTTP GET请求的查询串中查找<param>中指定的URL参数，基本上可以锁定使用特制的URL到特定的负载均衡器节点的要求；该算法一般用于将同一个用户的信息发送到同一个后端服务器；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
七、hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；在每个HTTP请求中查找HTTP头<name>，HTTP头<name>将被看作在每个HTTP请求，并针对特定的节点；如果缺少头或者头没有任何值，则用roundrobin代替；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
八、rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。为每个进来的TCP请求查询并哈希RDP cookie<name>；该机制用于退化的持久模式，可以使同一个用户或者同一个会话ID总是发送给同一台服务器。如果没有cookie，则使用roundrobin算法代替；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。
https://www.cnblogs.com/gtms/p/6790939.html https://blog.csdn.net/tantexian/article/details/50056199
