#负载均衡概述

凌晨 2 点，电商大促刚刚结束，运维群里突然炸了：某台后端服务器 CPU 被打满到 100%，接口响应时间从正常的 50ms 飙升到 5 秒，而其他两台服务器却悠闲地 idle 着。你紧急登录负载均衡器查看，发现问题根源是一个「看起来很合理」的配置——加权轮询权重设置为 4:2:1，但实际处理能力比例却是 1:1:1。更糟糕的是，由于会话保持策略，这台被"照顾"的机器上还堆满了长连接，GC 压力剧增，雪球越滚越大。

这个场景折射出负载均衡领域最典型的两类问题：流量分配策略选择不当与会话保持机制的双刃剑效应。很多人以为负载均衡只是一个「把请求分到多台机器」的工具，但实际上，从算法选型、协议选择、健康检查到会话管理，每个环节都有深坑。

本节从负载均衡的基础概念出发，帮助你建立完整的知识体系。

#什么是负载均衡

负载均衡的核心目标很简单：将进入系统的请求合理分配到多个后端节点，使每台节点的负载保持在合理范围内，同时最大化系统整体吞吐能力。

但「合理分配」这四个字背后，涉及到流量分配算法、健康检查机制、会话管理策略等一系列复杂设计。一个配置失误，可能导致集群整体能力打个对折；一个策略不当，可能引发雪崩式的连锁故障。

flowchart TB
    subgraph LB["负载均衡器"]
        LA["流量分配器"]
        HC["健康检查器"]
    end

    subgraph Nodes["后端节点"]
        N1["节点 1\n负载: 80%"]
        N2["节点 2\n负载: 10%"]
        N3["节点 3\n负载: 5%"]
    end

    Client["客户端"] --> LA
    LA --> N1
    LA --> N2
    LA --> N3
    HC -.->|"检测节点状态"| N1
    HC -.->|"检测节点状态"| N2
    HC -.->|"检测节点状态"| N3

#负载均衡的三层模型

负载均衡按工作层级可分为三层：

flowchart TB
    subgraph Internet["互联网"]
        Client["客户端"]
    end

    subgraph L4["四层负载均衡（LVS/DPVS）"]
        L4LB["TCP/UDP 分发"]
    end

    subgraph L7["七层负载均衡（Nginx/HAProxy）"]
        L7LB["HTTP/S 路由"]
    end

    subgraph Backend["后端服务集群"]
        S1["服务节点 1"]
        S2["服务节点 2"]
        S3["服务节点 3"]
    end

    Client --> L4LB
    L4LB --> L7LB
    L7LB --> S1
    L7LB --> S2
    L7LB --> S3

三层模型的选择取决于业务场景：追求极致性能选四层，需要精细路由选七层，数据分片则需要在应用层或数据层处理。

#四层 vs 七层负载均衡

这两者的本质区别在于协议解析深度与转发性能的权衡。

选择依据：如果只需要把请求均匀分到后端节点，选四层；如果需要根据请求内容做路由选择，选七层。两者也可以组合使用——四层做入口流量分发，七层做细粒度路由。

#负载均衡算法分类

负载均衡算法是本模块的核心内容。从流量分配策略来看，算法可分为三大类：

#静态算法

静态算法不考虑节点实时负载状态，仅根据预设规则分配流量。优点是实现简单、行为可预测，缺点是无法应对节点性能差异和实时负载波动。

#动态算法

动态算法会采集节点实时状态（连接数、响应时间等），选择当前负载最轻的节点。优点是能更好利用集群整体能力，缺点是实现复杂、状态采集有延迟。

#哈希算法

哈希算法将某些特征（客户端 IP、请求参数等）映射到特定节点，保证相同特征的请求始终路由到同一节点。这对有状态服务至关重要。

#为什么需要负载均衡

#问题一：单点故障

没有负载均衡时，单台服务器宕机意味着服务完全不可用：

flowchart LR
    Client["客户端"] --> S["单一服务器"]
    S -.x|"宕机"| Down["不可用"]

#问题二：性能瓶颈

单台服务器的处理能力有限，无法应对流量高峰：

单台服务器能力：
- CPU：16 核 @ 3.0GHz
- 内存：64GB
- 最大并发连接：10000

实际需求：
- QPS：50000
- 并发连接：20000

结论：单台服务器无法支撑，需要多台

#负载均衡的价值

flowchart TB
    subgraph WithLB["有负载均衡"]
        Client["客户端"] --> LB["负载均衡器"]
        LB --> S1["节点 1"]
        LB --> S2["节点 2"]
        LB --> S3["节点 3"]

        S1 -.x|"宕机"| LB
        S2 -.x|"宕机"| LB
        S3 -.x|"宕机"| LB

        Note["仍有 N-1 台节点提供服务"]
    end

负载均衡解决了三个核心问题：

1. 消除单点故障：多台节点互为备份
2. 提升整体吞吐：水平扩展处理能力
3. 流量灵活调度：按需调整流量分配

#负载均衡器部署位置

负载均衡器可以部署在不同的位置，承担不同的职责：

#常见认知误区

#总结

负载均衡是分布式系统的核心基础设施，它的核心目标是将请求合理分配到多个后端节点。

按层级分类：

• 四层负载均衡：基于 TCP/UDP，极高性能，适合基础分发
• 七层负载均衡：基于 HTTP/S，功能丰富，适合精细路由

按算法分类：

• 静态算法：轮询、加权轮询、随机
• 动态算法：最小连接、最短响应时间
• 哈希算法：IP Hash、一致性哈希

下一节我们将深入讲解四层负载均衡的核心技术——LVS。