haproxy支持多种负载均衡算法，分别对应用于多种应用场景下。
在CDN的cache
server这种后端大多数是分发静态文件的场景下，也需要一些特定的负载均衡算法。
将haproxy放置在cache
server的前端的理由有很多，实际好处包括：
SSL offloading
HTTP 7层交换
高级负载均衡算法
1.haproxy如何实现Content
Switching，即7层交换
客户端连接到haproxy定义的frontend上，haproxy根据指定的负载均衡算法，将请求路由到后端的backend(服务器群)中的一台服务器。
一个Frontend可以指定多个backend，可以通过ACL和use_backend规则来选择。
ACL可以使用各种fetch，fetch是haproxy的一个指令，用来指示haproxy从何处抽取数据。
2.实现最基本的动静态分离
frontend ft_public
[前端相关配置.......]
acl static_domain
req.hdr_beg(Host) -i static. images.
acl static_content
path_end -i .jpg .png .gif .css .js
use_backend bk_static
if static_domain or static_content
default_backend
bk_dynamic
backend bk_static
[后端相关配置......]
上边配置可以实现：
匹配所有域名是以‘static.’ 和
‘images.’开头
匹配所有文件扩展名是‘.jpg’ ‘.png’ ‘.gif’ ‘.css’
‘.js’
只要匹配上述两条规则中的任何一条，即可视为静态内容，则使用后端bk_static
其他不匹配上述规则的请求都视为动态内容，使用后端bk_dynamic
3.haproxy的hash相关算法
当计算一个hash算法时，以下因素会影响计算结果：
后端服务器群中的服务器数量
群中每个服务器的权重
服务器的状态(UP 或 DOWN)
如果上述因素中的任何一个发生改变，那么整个hash结果会重新计算，此后的请求会发送到不同的服务器上。这个过程尽管很短，但在高并发环境下还是有很大负面影响。
幸运的是，haproxy支持一致性hash(consistent
hashing),在这种条件下，只有跟改变的因素相关的流量才会受到影响，关于一致性hash，可以自行google。
在haproxy配置中，使用指令hash-type consistent
指定一致性hash。
4.hash的多种常见用法
a.仅针对URL
path做hash,即从第一个斜杠“/”开始，一直到问号“？”中间的部分
backend bk_static
balance
uri
hash-type
consistent
b.针对整个URL做hash，即包括查询串
backend bk_static
balance uri
whole
hash-type
consistent
c.针对查询参数做hash，假设URL为“/image.php?width=512&id=12&height=256”，针对id参数做hash
这样做的好处是，可以不用管对应参数的顺序位置。
backend bk_static
balance url_param
id
hash-type
consistent
d.针对特定的HTTP header做hash
backend bk_static
balance
hdr(Host)
hash-type
consistent
e.构造我们自己的hash
haproxy非常灵活，我们可以构建自己的hash。假设后端的vanish中，使用了请求的host主机头和URI来存储一个hash
key
那么在前端我们也可以使用对应的算法，来优化cache的命中率。
以下的配置将主机头中的host和请求的URI都转换为小写，将这两个变量连接在一起，形成一个新的header，叫做X-LB
然后haproxy基于这个X-LB做hash
backend bk_static
http-request
set-header X-LB %[req.hdr(Host),lower]%[req.uri,lower]
balance
hdr(X-LB)
hash-type
consistent
原文地址：https://www.haproxy.com/blog/haproxys-load-balancing-algorithm-for-static-content-delivery-with-varnish/
