企业官网建设流程全解析

半夜两点被一条告警吵醒，这种事情，凡是搞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列表、健康检查参数都在这里配置。
• listen：frontend + 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 check

balance这一行的参数就是算法名称，比如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的权重是2，web2的权重是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。

另外一个容易混淆的地方是：即使配置进行reload，static-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上没有设置maxconn，haproxy就不知道这台服务器到底能承载多少并发，计算时相当于把它当成容量无限大的节点，这样“最少连接数”这个指标就失去了参照意义。生产环境中我强烈建议给每个server都配上合理的maxconn值，这个值可以结合后端的线程池大小、数据库连接池上限来估算。比如你的应用是Tomcat，maxThreads是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 check

uri算法最经典的用武之地是缓存集群。假设你有一个图片服务或CDN节点，后端有几台缓存服务器，希望同一个资源的请求尽量落到同一台缓存上，这样缓存命中率能大幅提升。如果使用roundrobin，同一个图片请求今天打到A机器，明天打到B机器，每台缓存都得重新回源，缓存命中率自然上不去。换成uri算法后，同一个URL稳定命中同一台缓存，效果非常明显。

需要留意的是URI的稳定性。如果URL里带了大量动态参数，比如/product?id=123&utm_source=xxx，那么这个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 check

hdr算法的价值在于：它能在不修改业务代码、不引入额外会话保持组件的情况下，实现纯应用层的会话粘滞。比如某种老系统，内部没有做分布式会话同步，用户登录后状态只保存在本机内存里，这时用hdr(Cookie)把同一用户的请求固定到同一台机器，问题就绕过去了。

但它有几个前提要搞清楚。第一，如果请求头里没有指定的header，haproxy会回退到roundrobin，所以排查时要先确认客户端是否真的携带了该header。第二，多个同名header存在时，默认会对它们依次做哈希，可能造成哈希值不稳定。如果想只取首个或某个特定位置，需要配合hdr(name)后面的选项去控制。第三，用X-Forwarded-For做哈希时要注意信任边界，如果客户端能伪造这个头，就相当于能控制自己被路由到哪台后端，存在被恶意利用的可能。

3.4 rdp-cookie：RDP专用哈希

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 check

first适合的场景非常明确：慢启动和环境预热。比如一组后端服务刚上线，我希望先把流量集中灌给第一台机器，让它慢慢把缓存、连接池预热起来，满了再启用第二台。这种“顺序填装”的逻辑在普通轮询里很难实现，用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 check

random的一大优势是，在大规模集群下它的均衡效果非常理想，几乎不会出现roundrobin在某些极端负载波动下的局部不均衡。缺点同样是随机，无法做任何形式的会话保持。所以它适合完全无状态、对一致性没有任何要求的服务。random还可以配合哈希一致性使用，但生产里我见到的场景相对少一些。

4.3 动态调整权重：socket操作才是灵魂

我前面反复强调一个概念：roundrobin的权重可以动态调整，static-rr不行。这里补充一种非常实用的操作方式，通过haproxy的unix socket接口实时调整权重，完全不用reload。

首先在global段开启socket：

global stats socket /var/run/haproxy.sock mode 600 level operator

然后连接socket执行调整命令。常见工具是socat：

echo "show servers state web_servers" | socat stdio /var/run/haproxy.sock echo "set weight web_servers/web1 3" | socat stdio /var/run/haproxy.sock

set weight后面跟的是“backend名/server名”，然后把web1的权重调整到3。命令下发后，新连接立刻按新权重分配，不需要reload，不需要重启，对在线服务是零影响的。这个操作在灰度发布时非常实用：先把新版本节点的权重从0拉到一个小值，观察一小段时间，再逐步放大；如果出了问题，又可以把权重立即降回0，等于瞬间摘流。

我实际用下来的感受是，真正熟练的haproxy用户，在发布场景里很少去改配置文件reload，基本都是靠socket动态调权重。不仅快，而且可回滚。

5. 算法选型对比与生产避坑

前面把算法都讲完了，现在到了最关键的环节：面对一个实际业务，到底怎么选？这一章我给出比较直接的建议，以及一些生产环境里经常遇到的坑。

5.1 八种算法横向对比

为了好参照，我整理了一个表格：

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，某天新增一台D，map-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算法的个人心得，能让你少走一些我踩过的弯路。