负载均衡算法与架构选型指南

可视化演示

负载均衡原理

张经理的叫号屏解决的核心问题是什么？不是把学生平均分到窗口，而是确保每个窗口都被高效利用，让食堂整体出餐量最大。没有叫号屏时，某个窗口挤爆、某个窗口闲置，总出餐量上不去。计算机系统也是一样：单台服务器性能有天花板，把请求集中打到一台机器，它就会像超载的铁板饭窗口一样“罢工”。

负载均衡器就是这个叫号屏。它位于客户端和后端服务器集群之间，接住所有请求，再按一定策略转发到某一台后端服务器。后端集群对外只暴露一个虚拟 IP（VIP），客户端完全感知不到背后有多少台机器，这就是“流量分发”的本质——对内多台分担，对外一个入口。负载均衡器扮演的是“总调度员”角色，所有请求先经过它，再由它决定谁接单。

有了负载均衡，系统获得两个核心收益：一是横向扩展能力，食堂不够用就多开窗口，服务器不够用就加机器，无需改动代码；二是高可用能力，某台服务器宕机时，负载均衡器把它剔除，请求自动落到其他机器，整个过程用户无感。用概率的眼光看问题：单机可用性为 a，n 台机器并联后，只要至少一台活着系统就能服务，整体可用性大幅提升。这就是负载均衡成为高可用系统核心组件的原因。

张经理发现，叫号屏不能只是“平均分”，还要知道哪个窗口最空、哪个窗口快打烊，否则形同虚设。负载均衡器同样如此——它的灵魂在于“算法”。接下来几节，我们看看食堂经理的各种分派策略。

轮询与加权轮询

张经理最开始用最简单的方式：叫号屏按 1、2、3……顺序把订单轮流派给每个窗口。这就是“轮询”（Round Robin），请求按顺序轮流分发到每一台后端服务器，大家机会均等。新同学来食堂，最爱这种“人人有份”的公平感。

但轮询有个问题：铁板饭窗口师傅三头六臂效率高，牛肉面窗口新人手脚慢，轮流派单导致快的窗口排队、慢的窗口积压。于是张经理给窗口标了“产能分”：铁板饭 5 分、牛肉面 3 分、饺子 2 分，按 5:3:2 的比例派单。这就是加权轮询（Weighted Round Robin），权重越大，分到的请求越多。权重通常根据服务器的 CPU 核数、内存大小等配置设定。

加权轮询用权重描述机器的处理能力，适合后端配置不一的场景。权重为 $w_i$ 的机器 i 分到的请求比例，等于它的权重占所有机器权重之和的比例。不过经典的加权轮询在权重相差大时，会出现“前面全是重机器、后面全是轻机器”的忽高忽低现象。Nginx 采用的平滑加权轮询通过动态调整当前权重，让请求序列像波浪一样均匀交错，避免短时间内的流量毛刺。

张经理满意之余也发现，光看窗口的“产能分”还不够——如果某窗口前面已经排了 20 个人，师傅再快也应付不过来。派单，还得看看窗口前的队伍长度。这就引出了下一节。

最少连接与哈希算法

张经理让叫号屏每次派单前先扫一眼各窗口的排队人数，哪个队伍最短就把订单派给哪个。这就是“最少连接”（Least Connections）：请求到达时，负载均衡器统计每台后端服务器当前的活跃连接数，把新请求分给连接数最少的那台。

最少连接比轮询更贴近“真实负载”，因为连接数是动态的：一台慢服务器即使权重低，只要它当前接的请求少，新请求也可以优先给它。实际中常把权重和连接数结合，形成加权最少连接。公式上，最少连接选择的是所有候选中活跃连接数 $C_i$ 最小的服务器 $i^*$，这个“argmin“符号就是”从一堆候选里挑出最小的那个”的动作。

张经理还遇到一个诉求：有些同学认准了铁板饭的阿姨，希望每次都在同一个窗口。计算机里用户也有类似需求——登录状态、购物车数据如果散落到不同服务器，每次都要重新认证。IP 哈希算法对客户端 IP 做哈希后取模，把来自同一 IP 的请求始终映射到同一台后端，实现了天然会话亲和。但节点增删时普通取模会大范围失效，一致性哈希把节点映射到环形空间，增删节点只影响相邻区域，适合缓存类场景。

现在张经理的工具箱里有轮询、加权、最少连接、哈希四大算法，但他还有更根本的问题没解决：叫号屏该装在大门口（只看学生来不来），还是装在窗口内部（看清盘子里是什么菜）？这就是负载均衡的“层”的问题。

四层与七层负载均衡

食堂叫号系统有两种设计。省事版：大门口放一个发号机，只数人头发号，不关注学生点了什么菜，学生进了食堂自己绕到对应窗口。升级版：叫号屏能看清每个订单点了什么菜，直接告诉学生“铁板饭去 3 号窗口、牛肉面去 5 号窗口”。这两种设计，对应负载均衡的“四层”与“七层”。

四层负载均衡工作在传输层，负载均衡器只解析 TCP/UDP 报文头部的 IP 和端口，做地址转发（比如 LVS、HAProxy 的 TCP 模式）。它不关心报文内容，转发速度极快，像只数人头的发号机；七层负载均衡工作在应用层，解析 HTTP 报文中的 URL、Header、Cookie 等内容后按规则转发（比如 Nginx），像看得懂菜单的引导员。

四层和七层的时延差异可以用一个简单公式表达：七层时延约等于四层时延加上报文解析开销。别看只是多了解析，在高并发下这个差距会被放大：四层每秒可处理百万级连接，七层在十万到几十万量级，同时七层能做 URL 路由、限流、灰度发布等高级功能。选择依据是：追求极致性能且转发逻辑简单选四层，需要精细化路由和管理选七层，生产环境往往两者叠加使用。

张经理想通了：发号机适合大食堂低成本管控，看得懂菜单的引导员适合讲究服务的食堂。但无论选哪种，他还得选“设备商”——找谁来当这个叫号屏？市面上最出名的三个“叫号屏”厂家就是 LVS、Nginx 和 HAProxy。

三大开源工具对比

张经理在展会上看中三款叫号屏：LVS 像一台内核级的高速发号机，Nginx 像一个懂菜单的引导员，HAProxy 像一个极其专注的专职调度员。三者并不完全同类，但都是负载均衡领域的明星，各有绝活。

LVS（Linux Virtual Server）运行在 Linux 内核态，通过修改数据包的目标地址做四层转发，支持 DR、NAT、TUN 三种模式，性能最强，单机可支撑百万级并发，适合作为集群最前端；HAProxy 是用户态专业的负载均衡软件，四层七层都支持，配置灵活、统计报表强大，尤其擅长 TCP 会话管理和健康检查；Nginx 本身是高性能 Web 服务器，其负载均衡模块按 URL 等七层信息转发，还能兼任静态资源服务和限流。

三者的吞吐能力大致满足下面的不等式：相同硬件下，LVS 的转发吞吐最高，HAProxy 次之，Nginx 七层转发再次。选型口诀：需要极致性能、扛最外层流量选 LVS；需要专业的四层/七层混合调度和精细化健康检查选 HAProxy；需要 Web 服务、反向代理、负载均衡一体化选 Nginx。实际大厂常把 LVS 挡在最前，Nginx 做七层路由，形成分层负载。

叫号屏装上后，张经理又发现新问题：某个窗口的师傅突然请假，叫号屏却还在拼命派单，订单越积越多。他意识到，叫号屏必须随时知道每个窗口是不是真的在营业。

健康检查机制

张经理给叫号屏加了一个功能：每 5 秒“拍一拍”每个窗口，问一句“师傅在吗？”。如果连续 3 次没有回应，就把该窗口标记为“暂停营业”，不再派单；恢复后自动重新开放。这个机制在负载均衡里叫“健康检查”。

健康检查分主动与被动：主动探测是负载均衡器按固定周期向后端发送探测请求，比如 ICMP ping 检查主机是否存活、TCP 检查端口能否建立连接、HTTP 检查业务接口是否返回 200；被动熔断是负载均衡器观察真实转发中连续失败的次数，达到阈值就自动摘除，相当于“窗口连续出餐失败三次自动暂停”。

判定规则可以抽象为状态机：连续成功 $s_{ok}$ 次达到上线阈值 $u$ 才标记为 up，连续失败 $s_{fail}$ 次达到下线阈值 $f$ 才标记为 down。两个阈值防止抖动——网络抖动一次就摘除会导致雪崩，检查太频繁又会增加后端负担。此外还有优雅摘除：让正在处理的请求先完成（排空 drain），再下线新流量，避免用户请求被硬生生切断。

健康检查保证了“活着的窗口才接单”，但还有一个体验问题：老顾客希望每次都去熟悉的窗口，可轮询和最少连接会把他分到任意窗口。张经理该怎么满足这群“认窗口”的同学？

会话保持策略

张经理发现，有些同学打饭时喜欢和阿姨聊两句，每次换窗口就得重新解释一遍口味。于是叫号屏推出“老顾客模式”：识别出同一张饭卡，就始终把它派到上次的窗口。计算机系统中这叫“会话保持”（Session Stickiness），确保同一用户的多个请求落在同一台后端服务器，避免登录态丢失、购物车清空。

会话保持的实现方式主要有三种：一是会话粘滞，负载均衡器按用户会话 id 哈希到固定后端，最简单但节点增删会引起重映射；二是 Cookie 植入，七层负载均衡器在后端返回的响应中植入一个包含后端标识的 Cookie，后续请求带着 Cookie 直接路由到对应服务器，灵活且精准；三是分布式会话，把会话数据抽到 Redis 等共享存储，此时后端无状态，任意机器都能服务，是最彻底的解法。

一致性哈希在会话保持中也很常用：把服务器节点映射到哈希环上，请求 key 沿环顺时针找到最近的节点。相比普通取模，增删节点时只有环上相邻区域的请求会迁移，其他用户的会话不受影响，因此特别适合缓存和长连接场景。公式里 $pos(x)$ 表示把 key 或节点映射到环上 0 到 $2^{32}-1$ 的位置，ring_next 表示顺时针查找的行为。

至此，张经理把叫号屏的算法、层级、设备、体检、认人机制都备齐了。但每套食堂的规模、预算、客流特点都不同，怎么组合这些零件才是终极大考——这就是架构选型。

架构选型实战

张经理发现，隔壁小面馆只有两个窗口，根本不需要叫号屏；而五星级酒店食堂要兼顾 VIP 包间和千人快餐厅。架构选型的第一原则是“看菜下饭”：系统规模不同，负载均衡方案天差地别。

选型的三个核心步骤：先做场景分析——业务是长连接还是短连接？读写比例如何？要求秒级容灾还是分钟级？再做容量规划——估算峰值 QPS、平均请求体大小和单机承载能力，算出最少需要多少台后端机器；最后定高可用拓扑——负载均衡器自身也要冗余，通常采用主备（keepalived 做 VIP 漂移）或集群模式，避免“叫号屏坏了全食堂瘫痪”。

容量规划的经典公式是：所需机器数 N 等于峰值 QPS 除以单机可承载 QPS 后向上取整。单机承载能力要通过压测获得，而不是拍脑袋。典型的生产架构是多层叠加：DNS 轮询做地域分流，LVS 在最前扛四层流量，Nginx 做七层路由、限流和静态缓存，微服务层再用注册中心做客户端负载均衡，每层各司其职又互相兜底。

张经理最终按食堂规模定制了方案，叫号屏每天稳定运转，铁板饭窗口不再排队，牛肉面师傅也忙得过来。选型没有银弹，只有结合业务特征、性能预算和团队运维能力做权衡。记住那句老话：没有最好的负载均衡，只有最合适的负载均衡。

AI 应用场景

Python 演示

# 平滑加权轮询负载均衡器示例import time class SmoothWeightedRoundRobin:    def __init__(self, servers):        # servers 形如 [{'name': 'backend-a', 'weight': 5}, ...]        self.servers = servers        self.current = [0] * len(servers)     def next(self):        total = 0        best = -1        for i, s in enumerate(self.servers):            self.current[i] += s['weight']            total += s['weight']            if best == -1 or self.current[i] > self.current[best]:                best = i        self.current[best] -= total        return self.servers[best]['name'] def main():    servers = [        {'name': 'backend-a', 'weight': 5},        {'name': 'backend-b', 'weight': 3},        {'name': 'backend-c', 'weight': 2},    ]    lb = SmoothWeightedRoundRobin(servers)    for _ in range(20):        print(lb.next())        time.sleep(0.05) if __name__ == '__main__':    main()

1. self.current[i] += s['weight']每轮先给每个候选者加上权重分，模拟“不同产能窗口的累积机会”。
2. total += s['weight']累加所有权重，在选出后用于扣减，保证长期比例准确。
3. if best == -1 or self.current[i] > self.current[best]遍历选出当前分数最高的那个后端，即“本轮最该接单的窗口”。
4. self.current[best] -= total被选中的选手扣掉总权重分，让它的分数降下来，下次不会连续被选。
5. for _ in range(20)模拟连续到达的 20 个请求，观察分发序列。

常见误区

面试题