2026.1.27--负载均衡

定义：负载均衡（Load Balancing）是现代分布式架构中的核心组件。简单来说，它就像是超市里的排队调度员：当大批顾客（流量）涌入时，调度员负责将顾客引导到不同的收银台（服务器），以确保没有任何一个柜台由于压力过大而崩溃，同时也保证顾客能以最快的速度完成结账。

使用场景：

高并发（High Concurrency）： 单台服务器的硬件资源（CPU、内存、带宽）是有上限的。当访问量超过单机极限时，通过负载均衡将流量分摊到多台服务器上。
高可用（High Availability）： 负载均衡器会持续进行健康检查。如果某台后端服务器宕机，它会自动将流量切换到健康的服务器上，实现故障自愈。
水平扩展（Scalability）： 业务增长时，你可以随时向集群中添加新的服务器，而不需要停机，负载均衡会自动发现并开始向新机器分配任务。

核心原理

四层负载均衡（L4）： 运行在 传输层。它只根据 IP 地址和端口号进行流量转发。它不解析应用层数据（如 HTTP 内容），因此速度极快，适用于对性能要求极高的底层架构。
七层负载均衡（L7）： 运行在 应用层。它可以识别 HTTP 头部、URL、Cookie 等信息。这使得它能做更智能的决策，比如"动静分离"（静态资源发给 A 服务器，动态接口发给 B 服务器）。

常用调度算法

轮询 (Round Robin): 依次轮流分配。
加权轮询 (WRR): 根据服务器性能分配权重。
最少连接 (Least Connections): 优先把请求给当前最闲的服务器。
一致性哈希 (Consistent Hashing): 解决服务器增减时，缓存或 Session 大规模失效的问题。

会话保持

在分布式环境下，如何确保同一个用户的请求落在同一台服务器上？

客户端 IP 绑定： 源 IP 哈希。
Cookie 植入： 负载均衡器在响应中插入识别 ID。
后端 Session 共享： 使用 Redis/Memcached 统一管理 Session。

健康检查

负载均衡器必须实时监控后端服务器的状态：

TCP 探测： 检查端口是否存活。
HTTP 探测： 检查特定的状态码（如 200 OK）。

主流工具推荐

工具名称	类型	适用场景	优势
Nginx	软件 (L7为主)	绝大多数 Web 应用、反向代理	配置极其灵活，生态丰富，插件多。
LVS	软件 (L4)	超大规模集群的入口	Linux 内核集成，性能几乎接近硬件。
HAProxy	软件 (L4/L7)	高并发、高可用环境	转发性能极高，监控统计功能非常直观。
Traefik	软件 (L7)	云原生、Kubernetes/Docker	原生支持容器发现，自动生成配置。
F5 BIG-IP	硬件	金融、电信等大型企业	极高的吞吐量和稳定性，但价格极其昂贵。

特性	TCP	UDP
连接性	面向连接（需三次握手）	无连接
可靠性	高（不丢失、不重复、按序）	低（尽力而为，可能丢包）
传输方式	字节流（无边界，自动拆分/合并）	数据报（有明确边界，原样发送）
速度	较慢（复杂的控制机制）	极快（无握手、无校验确认）
双工性	全双工点对点	一对一、一对多、多对多
资源消耗	较大（维护状态、大头部）	较小（极简头部）

官网链接：https://docs.nginx.com/nginx/admin-guide/load-balancer/

http负载均衡：

HTTP 负载均衡是一种通过在多个应用实例间分配流量来优化资源利用、最大化吞吐量、降低延迟并确保容错能力的各种配置技术。

1. 核心概念与基础配置

HTTP 负载均衡的核心在于将流量代理到一组后端服务器（Upstream Group）。

• 定义后端组 (Upstream) ：使用 upstream 指令定义一组服务器。你可以在这里列出后端服务器的域名或 IP 地址。

• 配置代理 (Proxy Pass) ：在 NGINX 的虚拟服务器（server 块）中，使用 proxy_pass 指令将请求转发到定义好的 upstream 组

基础配置示例：

复制代码

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server 192.0.0.1 backup; # 备用服务器
    }
    
    server {
        location / {
            proxy_pass http://backend; # 转发流量
        }
    }
}

2. 负载均衡算法（流量分配策略）

决定流量如何分配的关键在于选择合适的算法。NGINX 支持多种策略：

• 轮询 (Round Robin) ：默认方法。请求按顺序均匀分配给服务器，会考虑服务器权重。

• 最少连接 (Least Connections)：将请求发送给当前活动连接数最少的服务器，适合处理长连接请求。

• IP 哈希 (IP Hash)：根据客户端 IP 地址计算哈希值来分配服务器。这能保证来自同一 IP 的请求总是落在同一台服务器上（除非该服务器宕机）。

• 通用哈希 (Generic Hash) ：根据用户定义的键（如 URL request_uri）来分配，支持一致性哈希（Consistent Hashing），适合缓存服务器场景。

• 高级算法 (仅限 NGINX Plus)：

◦ 最短时间 (Least Time)：基于平均响应时间（Header 或 Full response）和连接数选择服务器。

◦ 随机 (Random)：随机选择服务器，可结合"最少连接"或"最短时间"作为二级筛选标准。

3. 流量控制与优化

除了简单的分配，你还可以精细控制流量的权重和流向：

• 服务器权重 (Weights) ：通过 weight 参数设置。例如 weight=5 的服务器接收的流量是默认服务器（weight=1）的 5 倍。

• 慢启动 (Server Slow-Start) ：（NGINX Plus 功能） 当服务器恢复或新加入时，在指定时间内（如 slow_start=30s）逐渐增加其流量权重，防止瞬间流量压垮刚启动的服务器。

• 连接限制 ：使用 max_conns 限制单台服务器的最大连接数。配合 queue 指令，可以将超过限制的请求放入队列排队，避免直接报错

4. 会话保持 (Session Persistence)

对于有状态应用（如购物车），需要确保用户在同一会话中的请求始终被路由到同一台服务器。

• Sticky Cookie：NGINX 生成一个 cookie 植入客户端，后续请求携带该 cookie 以识别目标服务器。

• Sticky Route：根据请求中的特定参数（如 URL 或已有 Cookie）路由到指定服务器。

• Sticky Learn ：（高级模式） NGINX 自动学习应用生成的 Session ID 与服务器的对应关系，并将映射表存储在内存共享区中，无需向客户端植入新 Cookie

5. 架构可靠性与监控

在生产环境中，负载均衡不仅仅是转发，还需要确保系统的高可用性。

• 共享内存区 (Zone) ：强烈建议配置 。通过 zone 指令，让多个 NGINX 工作进程（Worker Processes）共享后端服务器的状态（如计数器、健康状态）。如果没有它，各进程独立计数，会导致"最少连接"等算法在低负载时不准确，且无法实现动态配置。

• DNS 动态负载均衡 ：如果后端服务器的 IP 经常变化，可以配置 resolver 和 resolve 参数，让 NGINX 根据 DNS 记录的 TTL 自动更新后端服务器地址，无需重启。

• 健康检查：配置健康检查可以自动剔除故障服务器，待其恢复后再自动加入集群（文档中提及需参考专门的 HTTP Health Checks 章节）