HAProxy基础知识整理

目录

1、HAProxy简介

2、HAProxy特性

3、HAProxy适用场景

4、HAProxy的调度算法简介

1、HAProxy简介

    HAProxy是可提供高可用性、负载均衡以及基于TCP(意味着可以反向代理mysql等应用)和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些并发大（并发在1w或2w左右）web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上，完全可以支持数以万计的并发连接，并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。

    HAProxy实现了一种基于事件驱动的处理模型，并且是单一进程模型工作，此模型稳健且支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接，而事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。

2、HAProxy特性

1、作者开发的独特的弹性二叉树数据结构，使数据结构的复杂性上升到了0(1)，即数据的查寻速度不会随着数据条目的增加而速度有所下降；

2、支持客户端的keepalive功能，减少客户端与haproxy的多次三次握手导致资源浪费，让多个请求在一个tcp连接中完成；

3、支持TCP加速，零复制功能，类似于mmap机制；

4、支持响应池（response buffering）

5、支持RDP协议

6、基于源的粘性，类似nginx的ip_hash功能，把来自同一客户端的请求在一定时间内始终调度到上游的同一服务器；

7、更好统计数据接口，有一个web接口显示后端集群中各个服务器的接收、发送、拒绝、错误等数据的统计信息；

8、详细的健康状态检测，web接口中有关于对上游服务器的健康检测状态，并提供了一定的管理功能；

9、基于流量的健康评估机制；

10、基于http认证；

11、基于命令行的管理接口

12、基于ACL，用于访问控制等；

11、日志分析器，可对日志进行分析。

3、HAProxy的适用场景

 从上图中可知HAProxy适用在各种场景，因为它支持tcp、http的代理场景，所以可以在web服务器前端做负载均衡，也可以在动态服务器前端做负载，如php、tomcat等，也可以用于mysql这样的数据做负载均衡集群，当然只是对读的请求做负载均衡，而对mysql数据库的读写分离HAProxy并不理解，这需要由前端程序或专业的读写分离器来完成，读写分离器对读的请求转发到HAProxy，再由HAProxy做读的负载均衡。

4、HAProxy的调度算法简介

    简单说来HAProxy的调度算法分为静态算法、动态算法、混合算法三类（注：这里的分类是作者自己归纳的，可能不准确），而HAProxy是一种能实现传输层、应用层的负载均衡器，所以调度算法也可以针对这两个层次实现。

    那怎样来区分一个算法是动态还是静态的？静态算法与动态算法之间的差别，动态算法是指上游服务器的权重(weight)可以在HAProxy运行时动态调整，不需要重新启动HAProxy，只需要重新读入配置文件即可；动态算法还支持上游服务器的慢速启动功能，是指当上游服务器因故障或维护需要下线维护处理后，服务器的状态由down恢复为up后，HAProxy不会一下将目前采用的算法一下把该恢复后的服务器加入进来，而是让up起来的服务器慢慢的接入业务，给服务器一个预热时间。

静态调度算法：

static-rr

    类似于roundrobin，每个服务器根据权重进行轮询，它是静态算法，意味着在服务器运行时修改权重是无效的，backed后端服务器数量没有限制，服务器启动后便会立即进入到集群中，整个集群的负载将被打破并重新进行计算分发，所以不支持慢速启动。

first

    此种算法表示把所有请求都转发到backend的第一个server上，直到连接数据达到maxconn的数目后才把客户端的请求转发到下一个server，不常用此种算法。

动态调度算法：

roundrobin

    虽然叫roundrobin，但其实是指带权重的轮询，不需要会话保持时可用此算法，这是一种最流畅、最公平的算法，此算法常用。此算法后端服务器的权重可动态调整，即修改服务器的权重后，重新载入haproxy.cfg配置文件就可以生效；后端服务器支持慢速启动，即当一服务器下线维护或故障又重新上线时，haproxy会慢慢的把请求调度到此服务器上，并不会一下打破之前的调度，这给刚上线的服务器一个预热的时间。后端backed的服务器数量最多不能超过4095台，实际生产环境中哪能达到这样的规模，所以相当于没有限制backed的服务器数量。

leastconn

    带权重的最少活动连接数算法，是动态算法，表示连接数最少的服务器优先选择，但这种算法不适用于web服务这样的短会话的协议，建议用于有长会话的服务，比如：LDAP, SQL, TSE, SSH。

混合算法：

source

    以源IP地址作为标准来挑选后端的服务器，此算法可以为静态，也可以为动态，以hash-type来指定。通常情况下以源IP的这种方式会有两种挑选后端服务器的方法，一是用取余的方式，还有一种是一致性hash。

    当“hash-type map-based”时表示source是静态算法，此算法把源IP地址做hash后除后端服务器数量得到的余数就是所选择的服务器，如果后端backend的服务器数量有变化那将影响全局的调度，影响范围大。

    当“hash-type consistent”时表示source是动态算法，此算法把后端的服务器平均放在一个hash环上，可能还会虚拟出许多虚拟节点，服务器两两之间就有了一个hash的取值范围，把源ip地址的hash值放在这个hash桶上来往顺时针方向转得到的那个服务器就是所挑选出来的服务器，如果后端backend的服务器数量有变化那只是影响一部份服务器的调度，影响范围较小。

uri

    先来看一下一个URL的格式：<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>，URI表示URL中的“/<path>;<params>?<query>#<frag>”这一部份。

    此种算法以URI的一部分（即是URL中<port>之后，问号之前的部分，即：/<path>;<params>）或全部URI（当使用"whole"作为uri的参数时是使用全部的URI）做hash，用服务器的总权重来除以此hash值来分配挑选backend后端的服务器，只要后端服务器群正常，同一个URI的地址总是被调度到同一台服务器。此种算法常用在后端是缓存服务器的场景，最大限度的提高缓存命中率，此算法是静态算法还是动态算法取决于hash-type的值，此算法还拥有"len"和”depth“两个参数，参数后接一个空格再加上一个正整数，可控制uri算法取URI字段中的字节长度或深度。

url-param：

    根据url中的参数（即是URL格式中的“<params>”部分）做调度，此算法是静态算法还是动态算法取决于hash-type值，此种调度算法用在类似这样的场景，假如一个站点提供对不同的用户提供不一要的服务，有VIP用户和非VIP用户之分，那么就可以根据这个<params>来区分用户身份的不同，以达到调度到不同的服务器组，以提供不同的服务。

hdr(<name>)：

    <name>更换成相应的请求首部，如"hdr(Host)"，表示以请求首部的Host首部作为调度。在每个HTTP请求中查找HTTP首部字段，以首部字段为调度。与ACL函数'hdr()'一样。括号括起来的首部名称不区分大小写。如果hdr()没有指定任何首部，则使用roundrobin算法代替。   

rdp-cookie

rdp-cookie(<name>)

    这种调度算法是根据cookie来做调度，不常用，详细的我也不了解。