haproxy调度算法

在使用haproxy时在后台段会用到平衡以指明用何种方式实现后端服务器的调度。

,动态算法:权重可以动态调整

,静态算法:调整权重不会实时生效,只能重启才能生效

,此平衡的算法有:循环、static-rr leastconn,来源,uri, uri_param, hdr等

,轮询,基于权重进行轮询,此算法是动态的,每个后端服务器仅能最多接受4128个连接;

,要求后端不能有状态及会话方面的等,只能是静态的页面

,当后端有会话等动态信息时,结合饼干使用,效果最佳

,此静态的循环,不支持动态调整;静态算法,每个后端主机支持的数量无上限;

,根据后端主机的负载数量进行调度,新的连接请求被派发至具有最少连接数目的后端服务器;

,在长连接会话的场景中推荐使用此法,不适用http、动态算法

,将请求的源地址进行散列运算,由后端服务器的权重总数相除后派发至某匹配的服务器,此方法可以让,同一个IP的请求发往同一个服务器;不过,当服务器权重总数发生变化时,如某服务器宕机或添加了,新的服务器,许多客户端的请求可能会被派发至与此前请求不同的服务器;常用于负载均衡无cookie,功能的基于TCP的协议,其默认为静态,不过也可以使用hash-type修改此特性;

,hash-type:

,,地图:取模法(除模取余法);(静态的,默认的)

,,一致:一致性哈希法;(动态的,使后时需要指定:hash-type一致)

,对URI的左半部分(“问”号标记之前的部分)或整个URI进行散列运算,并由服务器的总权重相除后派发至某匹配的服务器;这可以使得对同一个URI的请求总是被派发至某特定的服务器,除非服务器的权重总数发生了变化,此算法常用于代理缓存或反病毒代理以提高缓存的命中率

,例:?项=123,#红色标记的部分是uri部分

,hash-type:

,,地图:取模法(除模取余法);(静态的,默认的)

,,一致:一致性哈希法;(动态的,使后时需要指定:hash-type一致)

,注:用到uri时,当访问过后端某个页面后,后面所有此页面的请求都发至此服务器

,当未访问过后端某个页面时,采此用循环算法,随机挑选一个响应,并且随后所有的此页面的请求都发至此主机,这种算法,当后端缓存时非常有效果! ! ! !,

,饼干的作用是基本浏览器实现会话粘;

,饼干的使用方法:饼干& lt; name>(重写| |前缀插入][间接][nocache],,

,[重写| |前缀插入]:添加饼干的方式

,,重写:把原有的饼干替换

,,插入:在原有的饼干后中插入,#此种方式最为常用

,,前缀:在原有的饼干前插入

,饼干常使用的方式:

,饼干SERVERID才能插入间接nocache

,,注:

,,a.SERVERID,是自己随便指定的,在下面的例子中就是SERVERID=websrv1 SERVERID=websrv2;插入:表示插入原有饼干后边

,,b。不根据源IP进行绑定,根据不同客户端的进行绑定,这种方式我感觉源要比好,因为源是把同一IP的发往同一后端服务器;根据不同客户端绑定,可以实现同一个公网IP的用户,请求发送到不同的后端

,,c.roundrobin算法,结合饼干这种方式可以进行尝试;这种方式弥补此了循环不保持会话的缺点

,用法实例:,

,,此平衡循环

,,饼干SERVERID插入间接

,,服务器web1 192.168.0.100检查重量1饼干websrv1

,,服务器web2 192.168.0.101检查重量3饼干websrv2

,,注:websrv1:是web1专有饼干的标识符,在客户端浏览器的cookie中可以看到

,,,websrv2才能:是web2专有饼干的标识符,在客户端浏览器的cookie中可以看到

,设置轮流捡取

,源

,uri

haproxy调度算法