HAProxy负载均衡secondary算法及新url_param值选路规则咨询

你当前使用的配置实现了基于请求参数xyz的一致性哈希负载均衡，check_post标识会同时从GET请求的URL查询串、POST请求的表单请求体中提取xyz参数值参与哈希计算，在后端节点列表无变动的前提下，可以保证携带相同xyz参数值的请求固定路由到同一台后端服务器。

1. 携带全新xyz参数值的请求选路规则 #

当请求携带从未出现过的xyz参数值时，HAProxy会严格按照一致性哈希的固定逻辑选路：

• 第一步：对该全新参数值做固定哈希计算，得到唯一确定的哈希结果
• 第二步：将哈希结果映射到提前初始化好的一致性哈希环上——这个环上均匀分布了所有后端健康服务器对应的虚拟节点
• 第三步：从哈希映射的位置开始顺时针检索，碰到的第一台处于健康状态的后端服务器，就是本次请求的目标节点

注意：这个选路过程完全不感知后端服务器的实时连接数、CPU/内存负载情况，哪怕检索到的第一台服务器负载远高于集群内其他节点，只要它通过了健康检查，就会被选中。如果请求根本没有携带xyz参数，HAProxy会将空字符串作为哈希键，走完全相同的选路流程。
只有当检索到的第一台节点处于故障下线状态时，HAProxy才会跳过该节点继续顺时针查找下一台健康节点，不会将请求转发到故障节点。

2. 关于secondary/fallback兜底负载算法的支持情况 #

原生HAProxy不支持为url_param一致性哈希策略配置独立的二级兜底选路算法，具体规则如下：

• 配置中唯一内置的“兜底”逻辑只有上文提到的故障节点顺延，这个顺延逻辑是内置固定的，没有开放配置入口让用户替换为leastconn（最小连接数优先）、roundrobin（加权轮询）这类按负载、顺序选路的算法。
• 只要请求携带了合法的xyz参数，不管这个参数值是已经有映射关系的旧值，还是第一次出现的全新值，都会严格走一致性哈希环的选路流程，不会触发其他负载算法的选路逻辑。
• 如果你的业务诉求是“已有映射记录的参数值固定路由到对应后端，第一次出现的新参数值优先转发到当前负载最低的节点”，单靠一条balance规则无法实现，需要通过配置两层后端、配合会话跟踪计数做逻辑判断的变通方案实现，但这种方案会破坏一致性哈希原本的“节点变动时最小化映射漂移”的核心特性，生产环境一般不推荐使用。

内容的提问来源于stack exchange，提问作者Pranam