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 完整内容进行哈希计算后的值决定。只要内容相同，无论长度如何，都会分配到同一台服务器；内容不同，即使长度和奇偶性相同，也可能分配到不同的服务器。
