半夜两点被一条告警吵醒这种事情凡是搞linux服务器运维或者后端的人应该都不陌生。那次告警的内容很直白haproxy后面两台linux服务器一台CPU已经跑到90%另外一台只有8%。我盯着监控曲线愣了几秒又回头翻了翻haproxy的配置问题一下就看清了——balance roundrobin。严格说这不是错误配置但对当时那组长连接服务来说它恰恰是最不该用的默认选项。从那次之后我把haproxy的负载均衡算法从头到尾捋了一遍也就是这篇linux个人心得第15篇想聊透的东西haproxy的八种负载均衡实现方式它们各自解决什么问题、适用什么样的业务场景、配置时有哪些容易踩的坑。如果你刚接触linux和haproxy或者已经在用haproxy但对算法选型还有些模糊这篇应该能帮你少走一些弯路。1. 动手配置haproxy之前先搞清楚balance指令的位置很多人在网上搜haproxy的负载均衡算法搜到的都是半截配置片段抄下来发现不生效原因往往是balance指令放错了位置。这里先说清楚haproxy的配置文件通常由global、defaults、frontend、backend和listen几种配置段组成balance指令不在global里也不在frontend里它专门放在backend段或者listen段中控制的是“后端服务器组”内部的分发策略。1.1 四个配置段各自负责什么global进程级别的全局参数比如用户权限、pid文件、日志等级、nbproc或nbthread这类并发模型参数和具体的负载均衡策略无关。defaults公共默认值可以给后续的frontend、backend、listen提供统一的timeout、retries、option等基础设置减少重复配置。frontend接收客户端流量的入口负责定义监听地址、端口以及最常用的use_backend规则把不同请求路由到不同后端组。backend真正干活的后端服务器集合balance指令、server列表、健康检查参数都在这里配置。listenfrontend backend的合并写法适合单组后端、端口又比较简单的场景比如四层TCP转发时经常用。如果你用的是简化写法的listen段balance同样生效原理和backend一样。搞清楚这些段落在哪里后面看任何配置样例都不会迷路。1.2 balance指令就藏在backend段里在haproxy中切换负载均衡算法只需要改一行backend web_servers balance roundrobin server web1 192.168.1.11:8080 weight 1 maxconn 500 check server web2 192.168.1.12:8080 weight 2 maxconn 500 checkbalance这一行的参数就是算法名称比如roundrobin、static-rr、leastconn、source、uri、url_param、hdr、rdp-cookie等等。配置虽简单但每个算法的行为差异非常大选对了事半功倍选错了就是开头那种一台机器打满、另一台闲着的情况。1.3 一个最小可运行的负载均衡配置为了后面每个算法的演示不突兀先给一个可以直接跑起来的最小haproxy配置global log /dev/log local0 maxconn 4096 user haproxy group haproxy defaults log global mode http option httplog option dontlognull retries 3 timeout connect 5000 timeout client 50000 timeout server 50000 frontend http_in bind *:80 default_backend web_servers backend web_servers balance roundrobin server web1 192.168.1.11:8080 weight 1 check server web2 192.168.1.12:8080 weight 1 check这份配置虽然基础但几个参数值得说明check开启健康检查web1或web2如果挂掉haproxy会自动把它摘除不再往里分新请求maxconn不设置时haproxy会认为后端可以承载无限连接这对部分算法leastconn、first的影响非常关键后面会专门讲timeout系列参数如果不配好长连接场景下会引发排队和假死问题也不容小觑。2. 经典八种算法拆解上轮询与连接数早期haproxy版本中官方文档和社区常说的负载均衡算法大致是这八种roundrobin、static-rr、leastconn、source、uri、url_param、hdr、rdp-cookie。我把它们分成上下两篇来拆解先说最常用的前四种。2.1 roundrobin动态加权轮询roundrobin可能是大家最熟悉的算法。它的核心逻辑是把新请求轮流分配给后端的每台服务器每台服务器的权重weight决定它在一轮中能分到多少连接。假设web1的权重是2web2的权重是1那么每三个新连接里大约有两个落到web1、一个落到web2。但haproxy的roundrobin和我们想象中朴素的“排队叫号”不太一样它内部做的是平滑加权轮询。什么意思比如权重分别是2和1时它不会连续给web1塞两个连接再切到web2而是会交错分发在宏观统计上满足2:1的比例在微观时间片上又避免某一台服务器被瞬间打满。这个细节对短连接、突发流量场景很重要。配置方法backend web_servers balance roundrobin server web1 192.168.1.11:8080 weight 2 check server web2 192.168.1.12:8080 weight 1 check适用场景很清晰后端服务器处理能力接近、请求处理时间也接近的无状态服务。比如常见的REST API集群、普通的Web网站后端都是清一色的应用实例没有特殊会话保持要求roundrobin就是稳妥可靠的选择。但有两个场景需要避开。第一是长连接服务比如WebSocket、IM推送、数据库代理这类。轮询只能保证“建立连接”这个过程是均匀的一旦连接建立并长期存活早期通过轮询建立的连接会慢慢不均匀有些机器上积累了上千条长连接另一些可能只有几十条。开头那个线上事故就是这种情况。第二是后端性能差异非常大的集群比如一台老机器和一台新机器混跑同样的weight其实是拍脑袋定的很难精确反映真实处理能力这时leastconn往往更合适。roundrobin还有一个非常好的特性它的权重可以在运行时动态调整而不需要重启haproxy或reload配置。后面讲到灰度发布时这个能力特别有用。2.2 static-rr静态轮询static-rr从名字就能看出来它是“静态”的轮询。它和roundrobin的核心区别在于权重在配置加载阶段就固定下来运行过程中不允许通过socket接口动态修改。配置几乎一样backend web_servers balance static-rr server web1 192.168.1.11:8080 weight 2 check server web2 192.168.1.12:8080 weight 1 check它适合什么场景后端权重长期保持不变的稳定业务。比如两台上线时间、硬件配置完全一致的机器从上线到退役都不会做什么权重调整用static-rr完全可以。因为少了一层动态计算它的分配行为更可预测排障时更容易追溯这在某些严格审计的行业环境里反而是优点。不过要记住一个限制如果你某个时刻想在线调整某台机器的权重static-rr是做不到的必须改配置后reload。与之相比roundrobin通过unix socket一条命令就能改。你要是希望保留灰度发布、流量切换的灵活性最好别用static-rr。另外一个容易混淆的地方是即使配置进行reloadstatic-rr也会保留整个会话表只是权重变化无法动态生效而已。在实际使用中我见过有人把static-rr当成roundrobin用结果临时切流量时发现权重调不动只能紧急改配置文件再reload白白多等几秒钟。所以在选择这两种算法前先问自己一个问题我需不需要在运行期动态调权重需要就选roundrobin不需要再考虑static-rr。2.3 leastconn按当前活跃连接数分配leastconn是我个人在生产环境里用得最多的算法之一。它的分配逻辑非常直观haproxy实时统计每台后端服务器当前的活跃连接数新连接到来时选择当前连接数最少的那台服务器。直观理解就是超市收银台roundrobin是“下一号顾客去下一个收银台”leastconn是“看哪个收银台队伍最短就去哪个”。配置示例backend tcp_push mode tcp balance leastconn server push1 192.168.1.21:9001 maxconn 500 check server push2 192.168.1.22:9001 maxconn 800 check它最擅长处理的场景是长连接和请求处理时间差异较大的服务。比如消息推送服务客户端连上后可能几分钟甚至几小时才断开如果按轮询分配先前建连的机器连接越积越多而leastconn会动态地把新连接引导到连接数更少的机器上实现真正的连接级均衡。再比如某些后端接口偶尔会出现慢查询一个请求挂了十几秒还不返回期间占用着连接和线程leastconn同样可以减少慢请求打在某台机器上的概率。但leastconn有一个隐藏的关键配置maxconn。如果server上没有设置maxconnhaproxy就不知道这台服务器到底能承载多少并发计算时相当于把它当成容量无限大的节点这样“最少连接数”这个指标就失去了参照意义。生产环境中我强烈建议给每个server都配上合理的maxconn值这个值可以结合后端的线程池大小、数据库连接池上限来估算。比如你的应用是TomcatmaxThreads是200那maxconn可以配在180到200之间。还有一个坑要注意当所有后端服务器的连接数都达到maxconn上限时新的连接不会立即失败而是会进入haproxy内部的排队队列等待。如果业务方没有设置合理的timeout queue用户可能会长时间挂在一个“半连接”状态体感就是页面一直在转圈。配合上timeout queue比如设为3到5秒排队超时就快速返回503至少能让用户知道服务是过载的而不是无限等待。相反如果后端的业务请求处理得极快比如静态小文件、简单的redis读取接口每个连接都是“秒建秒断”leastconn的连接数统计会频繁抖动反而不如roundrobin来得干脆。2.4 source按源IP哈希source是一种基于哈希的算法。haproxy对客户端IP地址做哈希计算然后把结果映射到某一台后端服务器上。效果是同一个源IP的请求正常情况下永远落在同一台后端上。配置示例backend api_server balance source hash-type consistent server api1 192.168.1.31:8080 check server api2 192.168.1.32:8080 check它的价值在于“会话保持”。有些场景不能用cookie比如内部RPC调用、某些没有浏览器状态的接口客户端或者你想让同一个调用方IP的所有请求固定走同一台后端方便进行审计、日志聚合、本地缓存预热。source算法就能满足这种诉求。但source算法的坑也不少。最常见的坑是NAT出口问题。如果大量客户端处于同一个NAT网关后面对外访问的源IP就是网关那一两个IP所有被哈希的请求会集中落在少数几台后端上负载瞬间严重倾斜。遇到这种场景不要盲目相信source算法应该考虑改用cookie、url_param或hdr(Cookie)这类基于应用层信息的哈希。另外source算法只对源IP哈希不感知后端当前负载。哪怕某台后端配了4倍于其他机器的资源只要哈希结果指向它流量还是会全部砸过去。所以source适合的是“更看重会话一致性、能容忍一定负载偏差”的场景而不是追求极致的资源利用率。3. 经典八种算法拆解下哈希类与协议类如果说上半场的轮询和连接数算法是“把流量均匀分发出去”那下半场的哈希类算法更像是“把具有相同特征的请求稳定地送到同一台后端”。这种思路在很多业务里比均匀分发更实用。3.1 uri按请求URI哈希uri算法的原理是对HTTP请求的URI字符串做哈希计算把相同URI的请求映射到同一台后端服务器。在Web层面看就是“今天访问/images/logo.png的请求永远由同一台后端处理”。配置示例backend static_cache balance uri hash-type consistent server cache1 192.168.1.41:8080 check server cache2 192.168.1.42:8080 checkuri算法最经典的用武之地是缓存集群。假设你有一个图片服务或CDN节点后端有几台缓存服务器希望同一个资源的请求尽量落到同一台缓存上这样缓存命中率能大幅提升。如果使用roundrobin同一个图片请求今天打到A机器明天打到B机器每台缓存都得重新回源缓存命中率自然上不去。换成uri算法后同一个URL稳定命中同一台缓存效果非常明显。需要留意的是URI的稳定性。如果URL里带了大量动态参数比如/product?id123utm_sourcexxx那么这个URI的哈希值会被这些动态部分打散每台后端分到的缓存命中率又会下降。实际项目中可以考虑只对URI的路径部分做哈希或者结合正则、map把动态参数剥掉再做负载均衡。不过haproxy原生的uri算法默认是对整个URI做哈希想细化到路径级别通常需要额外配置这个属于进阶玩法。在生产使用中还有两个细节值得注意后端扩缩容时哈希映射关系会发生变化原先落在A机器上的URI可能被重新映射到B机器造成缓存大规模失效。解决思路是配合一致性哈希hash-type consistent后面单独讲。另外同样URI的请求如果来自不同地域或不同运营商其实不一定需要固定到同一台后端这时候强行用uri算法反而会削弱地域调度的灵活性不如用geo相关的负载均衡方案。3.2 url_param按URL查询参数哈希url_param算法和uri算法长得有点像但它的哈希对象不是整个URI而是URL查询参数里指定的某个键值。比如balance url_param user_id意思是提取请求URL里user_id参数的值对这个值做哈希然后映射到后端。配置示例backend user_services balance url_param user_id server user1 192.168.1.51:8080 check server user2 192.168.1.52:8080 check这个算法的典型场景是“同一用户的数据尽量落在同一台后端”。比如某个服务在本地缓存了用户的会话数据、购物车数据、权限信息如果用户每次请求都跳到不同后端本地缓存就形同虚设。用url_param把user_id作为路由依据可以保证同一用户的请求稳定地到达同一台后端同时比source算法更精准——因为同一个IP后面可能有多个用户而user_id参数直接标识用户维度的会话。url_param还有一个不少人都不知道的选项check_post。默认情况下它只看URL查询参数如果参数被放在POST请求体里它是看不到的。加上check_post后haproxy会解析请求体里的表单字段从中提取指定参数。这带来一个问题解析请求体需要占用haproxy的CPU并发量大的时候会有一定性能损耗。所以我通常只在真的有必要、且POST请求占比大时才启用check_post。还有两个边界行为要记住。一是请求中如果找不到指定参数haproxy会退化到roundrobin分配方式二是如果同一个参数出现多次默认取第一个值。这些默认行为和Roundrobin之间切换时可能会导致部分请求的分发看起来“不规律”在排查问题时别被误导。3.3 hdr按HTTP头哈希hdr算法是八种算法中比较有“应用层思想”的一个。它根据HTTP请求头中指定字段的值做哈希。最常见的用法是balance hdr(Cookie)对Cookie头做哈希把同一会话的请求固定到同一后端也可以balance hdr(host)按域名路由到不同后端或者balance hdr(X-Forwarded-For)按真实客户端IP做哈希。配置示例backend web_servers balance hdr(Cookie) server web1 192.168.1.61:8080 check server web2 192.168.1.62:8080 checkhdr算法的价值在于它能在不修改业务代码、不引入额外会话保持组件的情况下实现纯应用层的会话粘滞。比如某种老系统内部没有做分布式会话同步用户登录后状态只保存在本机内存里这时用hdr(Cookie)把同一用户的请求固定到同一台机器问题就绕过去了。但它有几个前提要搞清楚。第一如果请求头里没有指定的headerhaproxy会回退到roundrobin所以排查时要先确认客户端是否真的携带了该header。第二多个同名header存在时默认会对它们依次做哈希可能造成哈希值不稳定。如果想只取首个或某个特定位置需要配合hdr(name)后面的选项去控制。第三用X-Forwarded-For做哈希时要注意信任边界如果客户端能伪造这个头就相当于能控制自己被路由到哪台后端存在被恶意利用的可能。3.4 rdp-cookieRDP专用哈希rdp-cookie在八种经典算法里显得比较特别因为前七个都是面向通用TCP或HTTP协议的而rdp-cookie是给远程桌面协议RDP用的。它的原理是提取RDP会话里的mstshash cookie并以此为哈希键把同一会话稳定地分配到同一台Windows远程桌面服务器。配置示例backend rdp_farm mode tcp balance rdp-cookie server rdp1 192.168.1.71:3389 check server rdp2 192.168.1.72:3389 check应用场合比较聚焦如果你想用haproxy给一组Windows远程桌面服务器做负载均衡并且希望用户每次重连都回到同一台机器上避免会话状态丢失就可以用rdp-cookie。普通Web服务基本用不到但如果你的公司内部有远程桌面网关需求知道这个算法的存在能省不少折腾。4. 新版扩展算法与动态调整很多人以为haproxy只有那八种算法其实新版haproxy又陆续支持了一些扩展的负载均衡算法比如first和random。虽然不是本文主题里的“经典八种”但在生产环境里也用得不少我放在这一章一并说说顺便讲一下实际的动态权重调整操作。4.1 first按顺序填装first算法的思路比较特别它不追求“均匀”而是让haproxy按照server在配置文件中出现的顺序从上往下填装连接。只要第一台服务器没有达到maxconn上限新连接就全部给第一台第一台满了再开始给第二台分配依此类推。配置示例backend batch_workers balance first server worker1 192.168.1.81:8080 maxconn 50 check server worker2 192.168.1.82:8080 maxconn 50 check server worker3 192.168.1.83:8080 maxconn 50 checkfirst适合的场景非常明确慢启动和环境预热。比如一组后端服务刚上线我希望先把流量集中灌给第一台机器让它慢慢把缓存、连接池预热起来满了再启用第二台。这种“顺序填装”的逻辑在普通轮询里很难实现用first却非常顺手。但它有一个极其重要的前提每台server都必须设置合理的maxconn。如果server没有maxconn第一台机器永远不会“满”那后面的机器就永远是闲置状态负载均衡完全失效。我第一次试用first时就被这个细节坑过配置里忘了写maxconn结果流量全部压在worker1上其他机器CPU纹丝不动。4.2 random随机分配random算法相对比较新。haproxy会对每个新连接生成一个随机数然后映射到后端服务器。在并发量足够大的情况下随机数的分布天然接近均匀而且实现非常轻量CPU开销低。配置示例backend web_servers balance random server web1 192.168.1.91:8080 check server web2 192.168.1.92:8080 checkrandom的一大优势是在大规模集群下它的均衡效果非常理想几乎不会出现roundrobin在某些极端负载波动下的局部不均衡。缺点同样是随机无法做任何形式的会话保持。所以它适合完全无状态、对一致性没有任何要求的服务。random还可以配合哈希一致性使用但生产里我见到的场景相对少一些。4.3 动态调整权重socket操作才是灵魂我前面反复强调一个概念roundrobin的权重可以动态调整static-rr不行。这里补充一种非常实用的操作方式通过haproxy的unix socket接口实时调整权重完全不用reload。首先在global段开启socketglobal stats socket /var/run/haproxy.sock mode 600 level operator然后连接socket执行调整命令。常见工具是socatecho show servers state web_servers | socat stdio /var/run/haproxy.sock echo set weight web_servers/web1 3 | socat stdio /var/run/haproxy.sockset weight后面跟的是“backend名/server名”然后把web1的权重调整到3。命令下发后新连接立刻按新权重分配不需要reload不需要重启对在线服务是零影响的。这个操作在灰度发布时非常实用先把新版本节点的权重从0拉到一个小值观察一小段时间再逐步放大如果出了问题又可以把权重立即降回0等于瞬间摘流。我实际用下来的感受是真正熟练的haproxy用户在发布场景里很少去改配置文件reload基本都是靠socket动态调权重。不仅快而且可回滚。5. 算法选型对比与生产避坑前面把算法都讲完了现在到了最关键的环节面对一个实际业务到底怎么选这一章我给出比较直接的建议以及一些生产环境里经常遇到的坑。5.1 八种算法横向对比为了好参照我整理了一个表格算法核心逻辑适合场景不适合场景roundrobin平滑加权轮询无状态短连接服务、性能接近的集群长连接、权重需要动态调整但没配socketstatic-rr静态加权轮询权重长期不变、行为可预测的业务运行期需要动态调权重的场景leastconn活跃连接数最少的优先长连接、慢请求、处理时间差异大极短生命周期连接的纯静态服务source源IP哈希无法使用cookie的会话保持NAT出口集中、负载偏差容忍度低的场景uri请求URI哈希缓存集群、静态资源、CDN回源动态参数过多的接口、地域调度诉求强的场景url_param指定查询参数哈希用户维度路由、有状态的HTTP服务参数缺失率高、POST体解析影响性能的场景hdr指定HTTP头哈希Cookie会话保持、按域名路由Header缺失率高、伪造风险大的场景rdp-cookieRDP会话Cookie哈希远程桌面网关负载均衡普通Web服务5.2 典型业务场景的选型建议无状态Web API集群首选roundrobin其次static-rr。两者都简单稳定区分点就是需不需要动态调权重。长连接推送、IM、WebSocket直接上leastconn同时给每台server配好maxconn。静态资源缓存集群用uri算法并且加上hash-type consistent减少扩缩容带来的缓存抖动。需要用户会话粘滞但不想改代码看维度和安全边界能用url_param用户ID的就用url_param能用Cookie的就用hdr(Cookie)。Windows远程桌面网关rdp-cookie基本是唯一正解。慢启动预热和按序加载first算法前提是配好maxconn。这里有个通用判断框架先问业务是有状态还是无状态再看连接是短还是长然后考虑后端性能差异大小最后看可用的会话标识是什么IP、URI、参数、Cookie还是协议特有的session。把这四个问题回答了选型基本就有了。5.3 健康检查与算法的联动陷阱健康检查参数check会直接影响所有算法的实际效果。比如leastconn场景中某台后端健康检查失败haproxy会把它摘除原本落在它身上的连接数统计会被清空新连接只会分给剩下的机器这在预期之中。但如果是uri或url_param这种哈希类算法后端摘除后原先映射到它的请求会被重新哈希到其他后端这在缓存类业务里会引发短暂的缓存穿透和回源风暴。哈希类算法配合一致性哈希能缓解这个问题但无法完全消除生产上还是要靠后端服务的快速扩容和优雅摘除配合。另一个容易忽视的坑是健康检查本身占用的连接也会计入后端连接数吗实际上haproxy对check连接和业务连接是分开管理的leastconn统计的是业务连接不会因为健康检查频率高而把某台机器的连接数顶满。但如果你配置的check间隔特别密集后端机器又卡在负载临界点健康检查请求本身也可能加剧后端压力。建议把inter间隔调到合理的秒级别不要为了“尽早发现故障”把健康检查打得过于频繁。5.4 hash-type consistent到底改了什么哈希类算法source、uri、url_param、hdr等都有一种可选参数hash-type。默认是map-based另一种是consistent也就是一致性哈希。map-based方式可以理解为把所有哈希结果均匀切成若干段每个后端对应一段然后新请求的哈希值落到哪段就去哪台后端。它的优点是分配均匀但后端的增删会导致大量映射关系发生变化。举个例子原来三台后端A、B、C某天新增一台Dmap-based会把原本映射到A、B、C的大量请求重新计算并分布到D上缓存命中率瞬间下降。consistent方式是一致性哈希后端增删时只影响其“邻居”节点范围内的映射关系其他请求的落点保持不变。这个性质对缓存类业务极其重要。我现在的习惯是只要使用哈希类算法一律加上hash-type consistent。唯一要注意的是一致哈希在后端节点数量非常少比如只有两台时扩容一台新机器的影响面依然不小但相比map-based已经好太多了。5.5 reload与长连接保持的坑haproxy reload时新配置会以新进程方式启动旧进程会继续维持已有的长连接直到连接自然断开或超时。这个过程有时候会让人误解明明改了算法为什么老连接看起来还是按旧算法分配的这是因为老进程和新进程是同时在工作的旧连接继续留在旧进程里新连接才走新进程和新的算法。遇到这种情况不用慌等旧连接排空后行为就会完全符合新配置。在处理长连接时还有一个小技巧可以在reload前把旧进程的连接优雅排空比如通过socket命令逐步把权重调低再reload或者配置option graceful这类参数让旧连接平稳退出。如果只是临时改个权重直接用socket操作就好根本不需要reload这一点和前面的动态调整是呼应的。我也越来越觉得选负载均衡算法其实没有绝对的“最优解”只有“当前业务前提下最合适”的方案。没有哪个算法能同时满足均匀、稳定、有粘滞性、又能动态调整权重你必须在这些维度里做取舍。我目前个人项目里比较固定的组合是内网API用leastconn保连接均衡缓存类统一用uri加consitent灰度发布场景临时切成roundrobin并通过socket动态控制权重这样做下来平衡性和可运维性都不错。希望这篇haproxy算法的个人心得能让你少走一些我踩过的弯路。