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

使用场景：

• 高并发（High Concurrency）： 单台服务器的硬件资源（CPU、内存、带宽）是有上限的。当访问量超过单机极限时，通过负载均衡将流量分摊到多台服务器上。

• 高可用（High Availability）： 负载均衡器会持续进行健康检查。如果某台后端服务器宕机，它会自动将流量切换到健康的服务器上，实现故障自愈。

• 水平扩展（Scalability）： 业务增长时，你可以随时向集群中添加新的服务器，而不需要停机，负载均衡会自动发现并开始向新机器分配任务。

1. 核心原理

• 四层负载均衡（L4）： 运行在 传输层。它只根据 IP 地址和端口号进行流量转发。它不解析应用层数据（如 HTTP 内容），因此速度极快，适用于对性能要求极高的底层架构。

• 七层负载均衡（L7）： 运行在 应用层。它可以识别 HTTP 头部、URL、Cookie 等信息。这使得它能做更智能的决策，比如“动静分离”（静态资源发给 A 服务器，动态接口发给 B 服务器）。

2. 常用调度算法

• 轮询 (Round Robin): 依次轮流分配。

• 加权轮询 (WRR): 根据服务器性能分配权重。

• 最少连接 (Least Connections): 优先把请求给当前最闲的服务器。

• 一致性哈希 (Consistent Hashing): 解决服务器增减时，缓存或 Session 大规模失效的问题。

3. 会话保持

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

• 客户端 IP 绑定： 源 IP 哈希。

• Cookie 植入： 负载均衡器在响应中插入识别 ID。

• 后端 Session 共享： 使用 Redis/Memcached 统一管理 Session。

4. 健康检查

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

• 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 章节）