HAProxy调度算法全解析：从轮询到一致性哈希的选型指南

1. 先搞清楚HAProxy调度算法到底在解决什么问题

1.1 从一次线上事故说起

先说个我早年遇到的真实问题。有一次我负责的一个后端接口集群，总共三台服务器，配置大差不差，我图省事直接用了HAProxy默认的roundrobin算法上线了。平时请求量不大，一切风平浪静。直到有一次促销活动，流量一下子涨了将近二十倍，结果其中一台服务器CPU直接打满，另外两台却闲得在摸鱼，整个服务超时率飙升，差点酿成线上事故。

我当时的直觉是服务器性能差异导致的，但查了一圈发现配置明明一样，请求处理的耗时却差了三倍以上。最终定位下来的根因其实不复杂：roundrobin算法虽然轮询得很均匀，但它是按照“连接数量”来做分发的，根本不看后端每个连接的实际处理时间。有些请求是简单的读缓存，几毫秒就结束；有些请求是复杂的聚合查询，可能要几百毫秒。轮询分发下，慢请求集中在某台机器上，自然就拖垮了一台，其他两台反而空闲。

这件事给我的教训非常大。很多人在用HAProxy的时候，注意力全放在后端健康检查、keepalived高可用这些大件上，反而忽略了调度算法这个看似不起眼的配置项。但算法选错了，后面加再多机器、调再多内核参数都是白搭。

1.2 调度算法的本质：分发逻辑的优先级排序

说句大白话，HAProxy的调度算法就是决定“一个新请求来了，到底扔给哪台后端服务器”的规则。你既可以在frontend段指定，也可以在backend段指定，通常我们都是在backend里统一配置，因为调度是针对后端服务器组的策略。

但这里有一个很多人没想透的点：调度算法并不是简单的“负载均衡”四个字可以概括的。换句话说，你希望“流量尽量均匀”，还是希望“每个请求都能保持会话”，还是希望“同一个用户总是访问同一台机器”，这几种诉求在算法选型上是冲突的。没有哪个算法是万金油，只有最适合某个业务场景的那一个。

HAProxy官方把调度算法分了几个大类：静态算法、动态算法、以及基于哈希的算法。静态算法的特点是在配置加载后，权重变化不实时生效，需要reload；动态算法则可以在运行时调整权重，HAProxy会自动重新计算分配比例；哈希算法则是根据请求的某个特征值（比如来源IP、URL、Header）计算出一个哈希值，再映射到具体的后端服务器。

理解了这个分类逻辑，你再去看官方文档里那一堆算法名字，就不会觉得他们只是花里胡哨的排列组合了。接下来我逐个拆解，保证把每个算法的适用场景、坑点、以及和相近算法的区别，都给讲透。

2. 静态类调度算法：roundrobin和static-rr的取舍

2.1 roundrobin：默认但不一定最优

roundrobin是HAProxy默认的调度算法，也是最容易理解的一种：轮流把请求分配到每一台后端服务器上，A、B、C三台机器，第一个连接给A，第二个给B，第三个给C，第四个又回到A，如此循环。

原理虽然简单，但有一个核心细节你必须搞清楚：HAProxy的roundrobin是加权轮询，不是简单的1:1:1。每台后端服务器的weight权重会直接影响被选中的次数。默认权重都是1，但你可以通过weight参数调整，比如给性能更强的机器配置weight 2，它就会拿到两倍的请求量。

这个算法最大的优点是平滑、均匀、无状态，后端的请求分配在数量上非常平均，不会出现某台机器被突发流量瞬间打爆的情况。而且它处理新连接的开销极小，性能很高，适合绝大多数无状态服务，比如API网关、轻量级Web服务。

但是它的短板也很明显，就是我在前面提到的问题：它只看连接数，不看处理时间。如果后端服务器之间有性能差异，或者请求本身的长尾效应非常严重，roundrobin这种“数量均匀”反而会造成“负载不均”。另外，它是静态算法，修改权重后必须执行reload或者通过socket动态调整才能生效，不会随着运行时间自动校准。

2.2 static-rr和roundrobin的真实差别

static-rr这个名字看着和roundrobin很像，很多人以为它们是一回事。确实，从分发逻辑上看，它们几乎一模一样，都是加权轮询。但有一个非常本质的差异：static-rr是纯静态的，运行时完全不允许调整权重；而roundrobin是半静态的，它在设计上支持通过Unix Socket接口在运行中修改权重。

你在配置里写static-rr之后，如果想用set server backend1 weight 2这类命令去动态调整权重，HAProxy会直接拒绝。而roundrobin虽然也是静态类算法，但它允许在运行时调整权重，下一个连接就会按照新权重来分发，不需要reload。

那什么时候用static-rr呢？我个人的经验是，如果你的后端服务器配置完全一致，业务逻辑也没有任何会话粘连的需求，而且你确定不会在线上动态调整权重，那static-rr的性能会略好一点点，因为它省掉了一些动态计算的分支逻辑。不过说实话，这个性能差异在绝大多数场景下微乎其微，我一般不推荐为了这点性能去牺牲动态调整的灵活性。

还有一个很多人忽略的坑：当后端服务器数量发生变化时，比如一台机器宕机被摘除，或者扩容加了一台机器，roundrobin和static-rr都会重新开始轮询，这会导致原本均匀的分配出现短暂的波动。这种情况下配合健康检查的inter和fall参数，让摘除和添加的节奏可控，会平滑很多。

3. 动态类调度算法：leastconn和first的设计逻辑

3.1 leastconn：懊悔没早换上的算法

leastconn，顾名思义，就是“连接数最少的后端优先”。每次有新请求进来，HAProxy会数一下当前每台后端服务器上的活跃连接数，然后把请求分给连接数最少的那一台。

这里强调的是“活跃连接数”，不是累计请求数。什么意思呢？如果有三台服务器，A机器当前有5个连接，B机器有3个连接，C机器有2个连接，新请求会优先给C。但如果C上的请求都是慢请求，处理一个要好几秒，那它的活跃连接数就会一直居高不下，算法自然会慢慢把流量分给A和B。这就是它和roundrobin的本质区别：它能感知到后端的处理能力，而不是盲目地按数量轮转。

我后来在做长连接服务的时候，彻底把roundrobin换成了leastconn。比如WebSocket服务、消息推送服务、以及一些需要长时间占用数据库连接的业务，这些场景下连接的生命周期很长，处理时间不均匀。leastconn能有效避免“有人累死有人闲死”的情况。

但是注意，leastconn也有自己的适用边界。如果你的业务是短连接场景，比如普通的HTTP API请求，每个连接几毫秒就结束，那leastconn和roundrobin的效果其实差不多，因为活跃连接数在极短时间内就被释放了，谈不上什么“负载感知”。这种情况下用leastconn反而多了一层连接数的统计开销，虽然很小，但没有必要。

3.2 first算法的优势和致命短板

first算法是个比较特别的存在，它定义了一个优先级顺序：每次都是从上往下找，把请求分给第一个还有剩余连接槽位的后端。

配合maxconn参数使用，first算法可以实现一种“先来先占、满了再去下一台”的效果。比如你给A、B、C三台服务器都设置了maxconn 100，那么前100个请求会全部堆到A上，等A满了才轮到B，B满了才轮到C。

这个设计思路其实不是为了提高单机性能，而是为了最大化资源利用率和局部性。在很多场景下，把请求尽量集中在少数几台机器上，反而能提高缓存的命中率，或者减少集群中机器的空闲能耗。如果你用了虚拟机或者物理机，希望空闲的机器可以自动休眠省电，first算法就很合适。

但first算法的短板非常致命：它完全不做负载均衡。一旦第一台机器出现性能瓶颈，而你又没有设置合理的maxconn，请求就会全部堵在它那里，后面的机器空转也帮不上忙。这个问题在突发流量下尤其恐怖。我见过有的团队图省事用了first，结果一台机器挂掉后，健康检查把它摘除了，流量自然落到第二台，但第二台的maxconn设置不合理，立刻也被压垮，形成雪崩效应。

用first算法必须配合非常保守的maxconn设置，而且要有很强的监控报警机制。如果你不想半夜被电话吵醒，我建议慎用，除非你非常清楚自己在做什么。

4. 一致性哈希算法：source、uri、url_param、hdr的实战选择

4.1 source算法：会话保持的幕后功臣

source算法是基于来源IP地址做哈希，把同一个IP的请求总是分配给同一台后端服务器。原理上，HAProxy会取客户端的源IP，计算哈希值，然后映射到后端服务器列表上。

这个算法最常见的用途就是会话保持。有些老旧的业务系统，Session是存在本机内存里的，没有做分布式会话共享，用户登录之后，后续请求必须还打到同一台机器上，否则Session就丢了，用户被强制登出。source算法能完美解决这类问题。

但source算法有个著名的坑：哈希分布不均匀。如果某个IP段的用户特别多，比如公司出口IP只有一个，那所有员工的请求都会哈希到同一台后端上，其他几台机器根本接收不到流量。这个现象叫“哈希倾斜”。

解决哈希倾斜的关键在于hash-type参数。默认的map-based方式在节点数量变化时会导致大量请求重新映射，而consistent方式可以最大程度减少重映射。我强烈建议在用source算法时，显式配置hash-type consistent，同时给后端设置合理的weight，让哈希环上的节点分布更均匀。如果倾斜还是严重，可以考虑用hash-balance-factor这个参数，它能让超过阈值的请求自动溢到其他节点。

4.2 uri算法和url_param算法：缓存命中的关键

uri算法是对请求的URI部分做哈希，让同一个URI的请求始终落在同一台后端服务器上。这个算法的核心应用场景是HTTP缓存。比如你用了Squid或者Varnish做缓存层，同一个资源URL如果能固定在某一台缓存服务器上处理，缓存命中率就会大幅提升，回源流量也会显著降低。

用uri算法时，有一个参数叫len，它表示取URI的前多少个字符做哈希。比如你可以设置uri len 10，表示只取URI的前10个字符。这个参数在URI很长、有大量动态参数的时候很关键。如果整个URI参与哈希，带不同query string的请求会被分到不同机器，那缓存就被分散了，命中率反而下降。建议先用URL的path部分参与哈希，忽略query string，然后再根据实际情况微调。

url_param算法则更进一步，它会解析URL里面的query string参数，用你指定的那个参数值做哈希。比如你有一个user_id参数，设置url_param user_id，那同一个用户的所有请求都会被分到同一台后端。

这个算法在微服务网关场景下特别实用。比如你需要在网关层做一定的灰度发布，或者需要把某个用户的所有请求都路由到同一组实例，url_param可以做到非常精准的按业务标识分发。但要注意，如果请求URL里不包含你指定的参数，url_param会退化为roundrobin分发，这一点一定要在文档里写清楚，不然排障的时候会绕很大弯子。

4.3 hdr算法和rdp-cookie算法：协议敏感场景下的特殊处理

hdr算法是对HTTP请求头里的某个字段做哈希，最常用的就是hdr(Cookie)或者hdr(X-Forwarded-For)。这个算法在需要基于客户端标识做会话保持时非常好用。

举个例子，你用hdr(Cookie)做哈希的时候，HAProxy会提取Cookie头的内容计算哈希值，这样同一个用户的多个连接（即使源IP变了）也能被分到同一台后端。这个能力在移动端场景特别宝贵，因为手机的IP经常在Wi-Fi和蜂窝数据之间切换，用source算法会失效，但Cookie是稳定的。

rdp-cookie算法则是为微软远程桌面协议（RDP）准备的，它会解析RDP协议里的Cookie字段来做会话保持。这个场景比较垂直，一般人用不到，但在做远程桌面网关的时候，它就是唯一靠谱的选择。要注意的是，使用rdp-cookie必须在backend里启用tcp模式，并且需要后端返回正确的RDP Cookie，否则算法没法正常工作。

5. 算法参数详解与真实场景选型建议

5.1 weight、backlog、hash-type这些参数怎么搭配

很多人在配置里只知道写个算法名字，后面的参数一概不加，这样其实浪费了HAProxy调度算法的真正威力。我重点讲几个搭配必用的参数。

第一个是weight，它直接影响各种调度算法的初始分配比例。在roundrobin、leastconn、以及基于哈希的算法中，weight都会作为加权因子参与计算。给性能更强的机器配置更高的weight，是调度优化里性价比最高的一件事。但不要瞎调，我一般建议先在压测环境找出每台机器的真实吞吐上限，再按比例折算权重。

第二个是backlog，它设置的是后端服务器连接队列的深度。当后端所有机器都达到maxconn上限，新的连接会进入backlog队列排队等待，而不是直接拒绝。这个参数在处理瞬间突发流量时非常有用，它能给后端一个缓冲时间，避免因为一瞬间的并发升高而触发健康检查失败。我通常会把backlog设置为maxconn的2倍左右，太大会导致请求等待时间过长，太小又失去了缓冲意义。

第三个是hash-type，它决定了哈希算法如何把请求映射到后端。map-based是默认方式，计算快，但节点增删时受影响范围大。consistent使用一致性哈希环，节点变化时只影响环上相邻的一小部分请求，非常适合后端数量会动态变化的场景。在分布式缓存、微服务网关等领域，我基本都会显式配成hash-type consistent。

5.2 不同业务的算法选型矩阵

为了方便你快速选型，我整理了一张算法选型表，都是我自己在真实项目里验证过的思路：

这张表只是个起点，实际生产环境里，往往需要在算法之外叠加ACL规则、use_backend条件，才能组合出最合理的路由策略。这点在后面常见问题里会聊到。

5.3 算法的性能和可维护性考量

选算法的时候，很多人只盯着功能，忽略了性能和可维护性。我实际测试过，roundrobin和leastconn在每秒钟几万连接的压力下，性能差异在1%以内，基本可以忽略。真正有性能差异的是哈希类算法，尤其是一致性哈希，它在计算哈希值和环形查找上的开销会略高一点，但一般也在微秒级别，不至于成为瓶颈。

可维护性才是更重要的考量。比如roundrobin支持运行时通过socket调整权重，而static-rr不支持。你在做容量扩容的时候，如果用了static-rr，就必须reload配置才能让新权重生效，这在高可用要求严格的场景里是不可接受的。所以我个人的倾向是，除非特殊场景，否则优先选支持动态调整的算法，把灵活性攥在自己手里。

6. 常见问题排查实录与避坑指南

6.1 会话保持失效，用户频繁被登出

这是我在社区里被问得最多的问题。现象很明显：用户登录后，操作一会儿就掉线，再登录，过一会儿又掉。排查思路首先要确认你用的是什么算法。如果用的是roundrobin或者leastconn，那恭喜你，Session一定丢失，因为这两个算法根本不保证同一个用户落在同一台机器上。

正确做法是切换到source、url_param、hdr这类哈希算法。但还有一种更隐蔽的情况：你已经用了source算法，但用户还是掉线。这时候要看是不是有中间层做了IP伪装，比如CDN回源、NAT网关等。如果所有用户经过NAT后都显示同一个源IP，那source算法的哈希结果就会全部落到同一台机器上，其他机器被闲置，这既会导致负载不均，也可能因为单机压力过大而重启，导致所有会话丢失。

解决方案是在前端把真实的客户端IP写入X-Forwarded-For头，然后用hdr(X-Forwarded-For)替代source算法。这个坑非常典型，我建议做会话保持的人都要检查一下自己前面有没有代理层。

6.2 权重明明配置了，为什么流量比例不对

权重配置不生效，出问题的概率一半在“忘了reload”。roundrobin虽然是静态类算法，但HAProxy支持运行时通过socket调整，如果用配置文件改了weight但没reload，新配置就不会生效。另一半情况出在“权重和实际流量比例不对等”上。

比如你给A配了weight 2，B配了weight 1，你以为流量是2:1，但实际上看到的却是1.5:1。这是因为各个算法对权重的处理方式不完全一致。在leastconn算法中，权重的意义是“最大连接数的比例”，而不是“每轮被选中的比例”。如果A的maxconn是100，B的maxconn是50，而当前活跃连接数都没打满，那leastconn会优先把连接分给A，直到两者比例接近权重比例。

所以如果你一定要求流量比例绝对服从权重，建议优先考虑roundrobin。在leastconn这类动态算法下，权重更像是一个倾向性的引导，不是刚性分配。

6.3 哈希倾斜导致某台机器被打爆

哈希倾斜是source和uri算法最常见的问题。症状就是：明明集群有十台机器，但监控一看，某一台机器的流量占了80%，其他九台闲得发慌。

排查步骤我建议按顺序来：第一步，确认hash-type是否设置为consistent，map-based在节点变化时很容易产生热点。第二步，检查后端的weight是否设置合理，weight差距过大会导致哈希环上的节点分布密度不均匀。第三步，如果还是倾斜，给后端配置hash-balance-factor参数，它允许超过阈值的请求自动溢出到其他节点，是解决倾斜的杀手锏。

还有一个很不起眼的原因：后端服务器的name如果有规律（比如server1、server2），一致性哈希的节点也会比较集中。我习惯给后端节点名加上随机后缀，比如web-a3f9、web-c87d，这样哈希环上的分布会更离散。

6.4 健康检查导致的调度抖动

最后分享一个比较隐蔽的问题。健康检查的间隔和失败阈值设置不合理，会导致后端在“正常”和“down”之间反复横跳，每一次状态切换都会让调度算法重新计算后端列表，引起连接抖动，严重时甚至出现连接闪断。

我见过有人把inter设成500ms，fall设成1，意思是只要一次健康检查失败，就立刻把机器摘除。这在网络抖动稍微频繁一点的环境里，简直就是灾难。生产环境我一般建议inter设为2000ms到5000ms，fall设为2到3次，rise设为2次。原理很简单，健康检查要“慢进慢出”，给后端足够的恢复时间，也避免因为一次网络抖动就误杀一台机器。

另一个细节是健康检查的请求路径，如果你用的是HTTP健康检查，建议指向一个轻量的/healthz端点，不要指向首页或者复杂的业务接口。因为如果健康检查请求本身消耗太大，后端在压力高的时候健康检查会超时，进而被摘除，而摘除后流量转到其他机器，其他机器也被压垮，形成雪崩。这可以说是全网最常见的HAProxy误配置之一。

还有一点小技巧，当后端需要进行版本发布或重启时，可以先把它的weight临时调成0，让它不再接收新连接，等存量请求处理完了再操作。这个动作用HAProxy的socket接口几秒钟就能完成，相比直接停服务要优雅得多，这也是调度算法和运维流程结合的一个典型例子。

我在实际运维中的体会是，调度算法不是配一次就一劳永逸的东西，它跟业务形态、流量模型、甚至后端机器的性能差异都强相关。每次业务大版本迭代之后，我都会重新审视一遍当前算法是否仍然合适。比如从普通API变成WebSocket之后，就果断从roundrobin切到了leastconn，效果立竿见影。如果你也在用HAProxy，不妨把算法选型当成一件需要持续关注的配置，而不是写进去就不管了。