负载均衡是什么：原理、算法与实际部署方案

定义

负载均衡是什么？简单来说，它是一种将网络请求或计算任务分发到多台服务器的技术，目的是避免任何单台服务器过载，同时提升整体系统的吞吐量和可用性。

当用户访问一个网站时，请求并不是直接打到某一台固定的服务器上，而是先经过一个”调度层”——负载均衡器。这个调度层根据预设的规则，把请求转发到最合适的服务器去处理。整个过程对用户是透明的：用户只知道自己访问了一个域名，并不关心背后有几台服务器在工作。

负载均衡与反向代理密切相关——反向代理负责接收客户端请求并转发给后端，负载均衡则决定”转发给谁”。在实际部署中，Nginx、HAProxy 这类工具同时承担了反向代理和负载均衡两种角色。更多关于服务器架构的基础概念，可以参考VPS 是什么。

工作原理

负载均衡的运作可以分为四个阶段：

1. 接收请求：客户端发起 HTTP/TCP 请求，负载均衡器（前端）作为入口接收
2. 选择后端：根据配置的算法，从后端服务器池中选出一台来处理这个请求
3. 转发请求：负载均衡器将请求修改后（如添加 X-Forwarded-For 头）转发给选中的服务器
4. 返回响应：后端处理完成后，响应经负载均衡器原路返回给客户端

关键概念是”服务器池”（Server Pool）。负载均衡器维护一张后端服务器列表，每个条目包含 IP、端口、权重、健康状态等属性。健康检查机制会定期探测后端服务器是否正常——如果某台服务器连续多次探测失败，负载均衡器会自动将它从池中移除，不再往它转发请求。当服务器恢复后，再自动加回池中。

这种机制解释了为什么负载均衡是构建高可用架构的基础：单台服务器宕机不会导致服务中断，因为流量会被自动切换到存活的服务器上。关于服务器选型的基础概念，可以参考VPS 是什么。

常见算法

负载均衡算法决定了”哪个请求交给哪台服务器”。不同算法适用于不同场景，选错算法会导致流量分配不均或响应延迟上升。

轮询（Round Robin）

最基础的算法，按顺序依次将请求分配给后端服务器：A→B→C→A→B→C……轮询假设所有服务器处理能力相同，不关心各台服务器的实际负载。

适用场景：后端服务器配置一致、请求处理耗时相近。

加权轮询（Weighted Round Robin）

在轮询基础上为每台服务器分配权重。权重高的服务器获得更多请求。例如三台服务器权重分别为 5:3:2，则每 10 个请求中，A 分到 5 个、B 分到 3 个、C 分到 2 个。

适用场景：服务器配置不同，需要按性能比例分配流量。

最少连接（Least Connections）

将新请求分配给当前活跃连接数最少的服务器。这比轮询更智能——即使某台服务器配置更高，如果它已经在处理大量慢请求，新请求也不会再被分配过去。

适用场景：请求处理耗时不均匀（如混合了快速 API 调用和慢速文件下载）。

IP 哈希（IP Hash）

对客户端 IP 地址做哈希运算，根据哈希结果固定分配到某台服务器。同一 IP 的请求始终落到同一后端，保证会话粘性（Session Affinity）。

适用场景：应用依赖本地 Session 且未做分布式会话管理。但要注意：IP 哈希在服务器增减时会导致大量会话重新分配，不适合频繁扩缩容的场景。

加权最少连接（Weighted Least Connections）

结合权重和当前连接数两者，公式为 活跃连接数 ÷ 权重，选择该值最小的服务器。既考虑服务器性能差异，又考虑当前实际负载。

适用场景：生产环境中后端配置不同且请求耗时不均匀，这是较为通用的选择。

部署方案

Nginx 反向代理 + 负载均衡

Nginx 是最常用的七层负载均衡方案。配置一个 upstream 块即可实现基本的负载均衡：

upstream backend {
    server 192.168.1.10:8080 weight=5;
    server 192.168.1.11:8080 weight=3;
    server 192.168.1.12:8080 weight=2;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

这段配置将 Nginx 作为入口监听 80 端口，按 5:3:2 权重将请求分发给三台后端服务器。X-Forwarded-For 头让后端能获取真实客户端 IP，而不是 Nginx 的 IP。

Nginx 还支持健康检查（max_fails + fail_timeout）、限流（limit_req）、缓存等能力，单机即可承担相当规模的流量。

HAProxy 四层 + 七层负载均衡

HAProxy 专注于负载均衡，不支持静态文件服务，但在连接调度和健康检查方面比 Nginx 更精细。HAProxy 同时支持四层（TCP）和七层（HTTP）负载均衡：

• 四层模式：直接转发 TCP 连接，延迟极低，适用于数据库、邮件等非 HTTP 协议
• 七层模式：基于 HTTP 头、Cookie、URL 路径做路由决策，适用于 Web 应用

实际项目中常见组合：前端用 Nginx 做静态资源服务和 HTTPS 卸载，后端用 HAProxy 做精细化的应用层调度。

云平台托管负载均衡

主流云服务商都提供托管的负载均衡产品（如 CLB、ALB、NLB），用户无需自行部署和运维 Nginx/HAProxy。托管方案的优势在于：

• 自动扩缩容：后端服务器增减时自动更新路由表
• 内置 DDoS（分布式拒绝服务攻击）防护和 WAF（Web 应用防火墙）
• 跨可用区分发：自动将流量调度到不同可用区的健康实例
• 按量计费：小流量场景下成本可控

劣势是灵活性不如自建方案：自定义路由规则、特殊协议支持、精细日志分析等需求可能在托管产品中受限。

对于刚起步的项目，托管负载均衡是性价比最高的选择——不需要运维知识就能获得基本的高可用能力。当流量增长到需要更细粒度控制时，再迁移到自建方案。了解网络路由基础可以参考什么是 BGP。

应用场景

负载均衡几乎出现在所有中大规模的网络架构中。几个典型场景：

Web 站点：日均 PV 超过 10 万的站点通常需要至少 2 台 Web 服务器 + 1 台负载均衡器。Nginx 在前端做请求分发，后端应用服务器水平扩展即可。

API 网关：微服务架构中，API 网关本身就是一层负载均衡。它根据 URL 路径将请求路由到不同的服务集群，每个集群内部再用负载均衡分发到具体实例。

数据库读副本：MySQL 主从架构下，写请求走主库，读请求通过负载均衡分发到多个只读副本。ProxySQL 是这类场景的常用工具。

CDN（内容分发网络）边缘：CDN 的全局负载均衡（GSLB）根据用户地理位置将 DNS（域名系统）解析到最近的边缘节点，本质也是负载均衡的一种形式。更多内容参考什么是 CDN 加速国外服务器。

对比与边界

负载均衡解决的是”分发”问题，不是”存储”或”计算”问题。如果你的瓶颈是数据库写入性能，加负载均衡无法解决——需要考虑分库分表或读写分离。如果你的瓶颈是单机 CPU 不够，加负载均衡 + 水平扩展可以解决，但前提是应用必须是无状态的。当业务增长到单机无法承载时，选择独服还是云服务器需要综合评估，可参考什么是独立服务器及适合哪些类型的网站这篇评测文章来做出决策。

参考资料

• Nginx 官方文档：Using nginx as HTTP load balancer
• HAProxy 官方文档：HAProxy Documentation
• 什么是 CDN 加速国外服务器 — 理解全局负载均衡在 CDN 中的角色