负载均衡的英文完整写法是 Load Balancing，执行调度与转发任务的组件通常称为 Load Balancer，工程中常简写为 LB。它并非一种提高单机 CPU 或内存性能的技术，而是通过横向扩展方式，把来自客户端的请求按照既定策略分发到多个后端服务器，从而提升整体可用性和吞吐量。无论是 Web 站点入口、微服务网关，还是数据库中间件，负载均衡都承担着流量调度和故障隔离的关键角色。
如果只有一台后端服务器，所有请求都会集中到同一个进程或端口，一旦该节点出现故障或连接数打满，服务就不可用。引入负载均衡器后，客户端只与负载均衡器建立连接，后端节点可以随时增加、下线或替换。对客户端来说，访问入口保持不变，后端拓扑变化被完全隐藏。这也是大型分布式系统能够持续扩容的基础。
一、负载均衡的底层技术原理
负载均衡的核心工作发生在 OSI 模型的第四层或第七层。四层负载均衡基于传输层信息，例如源 IP、目标 IP、源端口、目标端口和协议类型，将 TCP 或 UDP 报文直接转发到后端节点。它不解析应用层内容，因此性能较高、延迟较低，适合大量连接、流媒体或数据库代理等场景。七层负载均衡则解析 HTTP、HTTPS、gRPC 等应用层协议，能够根据 URL 路径、Host 头、Cookie、请求方法等做更细粒度的路由。nginx、HAProxy、Traefik 等软件通常可作为七层负载均衡器使用，而 LVS、F5 设备更多覆盖四层能力。
除请求转发外，健康检查是负载均衡器不可或缺的机制。主动健康检查由负载均衡器定时向后端发送探测请求，例如 TCP 握手、HTTP GET /health 或特定端口探测，若连续失败达到阈值，则将节点暂时摘除。被动健康检查则根据真实请求的失败率进行判断，当某节点出现大量 5xx 错误、连接超时或连接拒绝时，自动降低其权重或标记为不可用。两者通常配合使用，以便在节点故障时快速隔离，同时避免因误判导致节点频繁抖动。
upstream backend_servers {
server 192.168.0.11:8080 max_fails=3 fail_timeout=30s;
server 192.168.0.12:8080 max_fails=3 fail_timeout=30s;
server 192.168.0.13:8080 backup;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_connect_timeout 3s;
}
}
上面这段 Nginx 配置定义了一个名为 backend_servers 的上游组，其中前两台服务器参与常规负载，第三台作为备份节点。max_fails 和 fail_timeout 控制被动健康检查的触发条件，backend_servers 内的请求通过 proxy_pass 转发。由此可见，负载均衡并不只是在多台服务器之间随机选择，而是由健康状态、权重、超时控制和连接复用等多个模块共同协作。
二、常见负载均衡算法与适用场景
轮询是最直观的算法：每个请求依次分配给后端列表中的下一台服务器。它实现简单，适合后端服务器性能一致、请求处理时间相对均衡的无状态服务。加权轮询则在轮询基础上为每台服务器设置权重，性能更强的机器可以承接更多请求。比如一台 8 核服务器和两台 4 核服务器组成集群，可以配置权重为 4、2、2，使总请求量按算力比例分摊。
最少连接算法动态统计每台后端服务器的活动连接数，将新请求分配给连接数最少的节点。它适合长连接、WebSocket、数据库代理等请求处理时间差异较大的场景。IP 哈希通过对客户端 IP 进行哈希计算，将同一客户端的请求固定到同一后端节点。一致性哈希则在节点扩容或缩容时减少重映射范围，广泛用于缓存集群和有状态服务。以下表格总结了常见算法的特点：
| 算法 | 核心依据 | 优点 | 典型缺陷 |
|---|---|---|---|
| 轮询 | 请求顺序循环 | 实现简单、分配均匀 | 不考虑节点负载和性能差异 |
| 加权轮询 | 预设权重 | 兼顾节点性能差异 | 权重需要人工调整 |
| 最少连接 | 活动连接数 | 适应长连接和耗时差异 | 需维护连接状态，有额外开销 |
| IP 哈希 | 客户端 IP 哈希 | 会话粘滞、缓存命中稳定 | 客户端分布不均时导致热点 |
| 一致性哈希 | 哈希环映射 | 扩缩容时重映射少 | 实现较复杂，可能引入虚拟节点 |
在实际项目中，会话粘滞不一定强制绑定到 IP 哈希。很多七层负载均衡器支持 Cookie 粘滞，即第一次请求由调度器选择后端，然后下发一个标识后端节点的 Cookie，后续请求根据该 Cookie 继续路由到同一节点。这种方式比单纯使用客户端 IP 更灵活，因为同一出口 IP 的大量用户仍可被分散到不同后端。
def weighted_rr(servers, counts):
sequence = []
for name, weight in servers.items():
sequence.extend([name] * weight)
index = 0
while True:
yield sequence[index % len(sequence)]
index += 1
上面的 Python 生成器展示了加权轮询的朴素思路：先把服务器名称按照权重倍数展开成一维列表，再循环取出。这种实现适合演示和测试，但在生产环境中，当权重很大或节点很多时，会消耗较多内存。工程实现通常使用平滑加权轮询算法，在保持权重比例的同时使分配更均匀，不会出现连续多次命中同一台服务器的情况。
三、负载均衡的典型应用场景
最常见的场景是 Web 服务器集群入口。客户端访问电商、资讯或视频网站时，流量先到达负载均衡器，再由其转发给 Nginx、Apache、Tomcat 等后端节点。入口层可以部署多层负载均衡：第一层使用 LVS 或云负载均衡做四层转发，第二层使用 Nginx 或 HAProxy 做七层路由，第三层才是具体应用服务器。这种分层结构能够将连接处理、TLS 卸载、路径路由和应用逻辑解耦，便于独立扩容和故障排查。
微服务架构下，API 网关本身通常内置负载均衡能力。服务发现组件如 Consul、Etcd 或 Eureka 维护可用实例列表，网关或客户端负载均衡器根据实例健康状态和版本标签选择目标服务。例如 Spring Cloud 中的 Ribbon、LoadBalancer 以及 gRPC 客户端负载均衡都属于这一类。相比集中式硬件负载均衡，客户端负载均衡省去了额外网络一跳，但要求每个客户端都实现相应策略，并且难以统一管理。
global
maxconn 65535
defaults
mode http
timeout connect 5s
timeout client 50s
timeout server 50s
frontend web_front
bind *:80
default_backend web_servers
backend web_servers
balance roundrobin
option httpchk GET /health
server web1 192.168.0.21:8080 check inter 3s fall 3 rise 2
server web2 192.168.0.22:8080 check inter 3s fall 3 rise 2
这段 HAProxy 配置展示了七层负载均衡的常见写法：前端绑定 80 端口，后端使用 roundrobin 算法，并通过 HTTP GET /health 做主动健康检查。check inter 表示探测间隔，fall 表示连续失败多少次摘除节点，rise 表示连续成功多少次重新上线。这样的配置能及时发现故障节点，同时给恢复后的节点一个稳定观察窗口。
除了 Web 服务，负载均衡还用于数据库读写分离和缓存集群。例如 MySQL 的 ProxySQL、MaxScale 或 Redis Cluster 客户端均可根据 SQL 类型或 key 所在槽位选择不同节点。DNS 负载均衡则通过为同一域名配置多个 A 记录，将用户分散到不同机房或 CDN 节点。DNS 方案实施简单，但缺少精细健康检查，客户端本地缓存也可能导致切换不及时，因此通常会配合全局负载均衡和智能解析使用。
四、常见问题与注意事项
第一个需要注意的是会话保持与状态共享。很多老系统会把登录状态写入服务器本地内存，一旦负载均衡把用户请求转发到另一台节点，就会造成登录失效或购物车丢失。解决办法通常有三种：使用分布式 Session 存储如 Redis；启用基于 Cookie 的粘滞会话；或者改造应用为完全无状态服务。粘滞会话可以暂时缓解问题，但如果后端节点宕机，用户仍会被迫重新登录，因此分布式 Session 往往比单纯粘滞更可靠。
第二个问题是健康检查的准确性。健康检查接口不应只是简单返回 HTTP 200，而应该检查关键依赖是否可用，例如数据库连接池、消息队列或缓存是否正常。若健康检查过浅，后端线程池已经耗尽时仍然可能被判定为健康；若健康检查过深，则可能因为一个非核心依赖抖动导致整台节点被频繁摘除。实践中常设置 liveness 和 readiness 两类探针，分别用于判断进程是否存活和是否具备处理请求的条件。
负载均衡器自身的高可用也经常被忽视。单一负载均衡器一旦宕机，所有后端即使正常也会整体不可用。生产环境通常使用主备模式或集群模式，例如通过 Keepalived 提供虚拟 IP，实现主备自动切换；或通过云厂商托管负载均衡和多个可用区部署来消除单点。此外，TLS 证书管理、HTTP 到 HTTPS 重定向、请求头透传、客户端真实 IP 获取、连接超时和重试策略都需要在负载均衡层进行统一规划。重试不应盲目开启，否则可能造成请求重复提交，尤其对于下单、支付等非幂等接口必须谨慎。
最后，后端服务器的时间同步、日志关联和监控指标也值得关注。负载均衡器与后端节点时钟不一致时，日志链路会错乱，问题追踪非常困难。建议在所有节点启用 NTP 时间同步，并在访问日志中记录 request_id 或 trace_id，由负载均衡器向后端传递。通过这些手段，才能在流量分发的同时保持系统可观测性和可维护性。
负载均衡Load Balancer负载均衡算法修改时间：2026-09-20 16:33:01