haproxy的算法——混合算法

1.简介

混合算法即可作为静态算法，也可通过选项作为动态算法

算法	核心依据	核心优势	典型适用场景	注意事项
source	客户端源 IP 地址	实现简单，保证同一客户端请求固定到一台服务器	- 电商网站的用户会话保持- 后台管理系统的登录态	同一 NAT 出口的多个用户会被视为同一来源，可能导致负载不均
uri	请求的 URI 路径	提升缓存命中率，避免资源重复计算	- 静态资源服务（图片、CSS、JS）- CDN 节点调度	URI 频繁变化或资源分布不均时，可能导致负载倾斜
url_param	URL 中指定的查询参数（如 user_id）	可按业务维度实现更精细的粘性调度	- 按用户 ID 分区的用户服务- 按会话 ID 保持的长连接应用	参数值分布不均时，可能导致部分服务器负载过高
hdr	HTTP 请求头中的指定字段（如 X-User-ID）	策略灵活，可按域名、用户标识等复杂维度路由	- 多租户 SaaS 平台（按 Host 头区分）- 按用户标识分区的微服务架构	依赖请求头的完整性和一致性，需确保客户端或网关正确传递字段

2.source算法

source 算法基于客户端的源 IP 地址进行哈希计算，将同一 IP 的请求始终转发到同一台后端服务器。它能保证来自同一客户端的会话粘性，避免因服务器切换导致的会话丢失，适合需要保持会话状态的应用（如登录态、购物车），同时在后端服务器增减时可通过一致性哈希减少请求重定向的范围。source一般默认静态算法。

实验一：source静态算法

进入haproxy配置文件编写命令，保存退出，重启生效

测试：

实验二：source动态算法

在实验一的修改内容基础上添加一段命令：hash-type consistent（哈希形式 一次性），保存退出，重启生效

测试：

3.uri算法

uri 算法根据请求的 URI 路径进行哈希调度，确保对同一资源路径的请求始终落到同一台服务器上。这对缓存类服务（如静态资源、CDN 节点）非常友好，能提升缓存命中率，减少重复计算和资源加载，但在 URI 频繁变化或资源分布极不均匀的场景下，可能导致部分服务器负载过高。

主备uri动态算法实验环境

设定uri算法

测试：访问的文件不同

4.url_param算法

url_param 算法提取 URL 中指定的查询参数（如user-id、session-id）进行哈希，将带有相同参数值的请求转发到同一台服务器。它比 source 算法更精细，可按业务维度（如用户 ID）实现会话粘性，适合按用户或业务标识进行分区处理的场景。

主备url_param动态算法实验环境

设定url_param算法

这里的<name>就是你要提取的 URL 查询参数名，比如user_id、session_id、product_id等。

haproxy 会从请求的 URL 中提取这个参数的值，然后对这个值进行哈希计算，从而决定将请求转发到哪台后端服务器。

测试：name=的后面只能包含 字母（a-z/A-Z）、数字（0-9）、下划线（_）、连字符（-），这是 URL 查询参数名的通用规范

5.hdr算法

hdr 算法基于 HTTP 请求头中的指定字段（如Host、X-User-ID）进行哈希调度，能根据请求头信息实现更灵活的分区策略，例如按域名、用户标识或设备类型分配到不同服务器组，适合多租户、多业务线或需要精细化路由的复杂架构。

主备hdr动态算法实验环境

测试：分配结果由对 User-Agent 完整内容进行哈希计算后的值决定。只要内容相同，无论长度如何，都会分配到同一台服务器；内容不同，即使长度和奇偶性相同，也可能分配到不同的服务器。