3、负载均衡基础：定义、分类与核心指标
负载均衡这东西，说白了就是「把活儿分均匀」。
我刚开始接触分布式系统时，觉得负载均衡不就是加个nginx转发一下嘛。后来线上出了几次事故，才明白这玩意儿的水有多深。你想想看，一个请求从客户端进来，经过负载均衡器，最后落到某台后端服务器上——这中间任何一个环节出了问题，用户感知到的就是「系统挂了」。
所以，咱们先把基础打牢。这一节我会把负载均衡的定义、分类和核心指标讲透，顺便聊聊我在项目中踩过的坑。
3.1 负载均衡的定义
负载均衡（Load Balancing），核心目标就两个：
- 分散压力：把请求均匀地分发到多台服务器上，避免单台机器过载。
- 提高可用性：某台机器挂了，流量自动切到其他机器，用户无感知。
我习惯把负载均衡比作「交通指挥员」。没有它，所有车都挤一条路，早晚堵死。有了它，车流被引导到多条路上，整体通行效率大幅提升。
核心要点：负载均衡不是简单的「轮流转发」，它需要综合考虑后端服务器的健康状态、当前负载、网络延迟等因素，才能做出最优决策。
3.2 负载均衡的分类：四层 vs 七层
这是面试高频题，也是实际选型时必须搞清楚的问题。我见过不少团队，明明业务场景适合四层，非要用七层，结果性能上不去；反过来，需要七层做精细化路由，却用四层硬扛，功能实现不了。
咱们直接看对比：
| 维度 | 四层负载均衡（L4） | 七层负载均衡（L7） |
|---|---|---|
| 工作层级 | 传输层（TCP/UDP） | 应用层（HTTP/HTTPS/gRPC） |
| 处理内容 | IP地址、端口号 | URL、Header、Cookie、请求体 |
| 性能 | 高（内核态转发，吞吐量大） | 相对低（需要解析应用层协议） |
| 灵活性 | 低（只能基于IP+端口） | 高（可以做内容路由、灰度发布） |
| 典型产品 | LVS、F5、HAProxy（TCP模式） | Nginx、HAProxy（HTTP模式）、Envoy |
3.2.1 四层负载均衡
四层负载均衡，处理的是TCP/UDP报文。它不关心请求里装的是什么，只看目标IP和端口，然后根据策略把报文转发给后端服务器。
我记得有一次，团队需要给一个MySQL读写分离做负载均衡。MySQL用的是TCP协议，业务逻辑不需要在负载层处理。我们直接上了LVS，配置简单，性能也够用。如果当时用Nginx做七层代理，反而多了一层不必要的协议解析，延迟会增加。
我的建议：如果你的场景是TCP/UDP协议，或者对性能要求极高（比如网关、数据库代理），优先考虑四层方案。它简单、高效、稳定。
3.2.2 七层负载均衡
七层负载均衡，工作在应用层。它能读懂HTTP请求里的URL、Cookie、甚至请求体内容，然后根据这些信息做精细化路由。
举个例子：
- 根据URL路径，把
/api/v1/*转发到微服务A，/api/v2/*转发到微服务B。 - 根据Header中的
X-Canary: true，把请求路由到灰度版本。 - 根据Cookie中的
session_id，实现会话保持。
这些能力，四层负载均衡是做不到的。我参与过一个电商项目，大促期间需要做流量灰度，就是靠Nginx的七层能力，根据用户ID哈希值，把一小部分流量引到新版本上。整个过程零停机，效果很好。
注意：七层负载均衡虽然灵活，但性能开销不可忽视。解析HTTP协议、正则匹配URL、处理Cookie，这些操作都会消耗CPU。在高并发场景下，七层负载均衡本身可能成为瓶颈。我曾经遇到过Nginx CPU打满的情况，就是因为正则规则写得太复杂，每进来一个请求都要做大量匹配。
3.3 核心指标
衡量一个负载均衡方案好不好，不能光看「能不能用」。我习惯从三个维度来评估：吞吐量、延迟、一致性。这三个指标，基本决定了系统的性能和可靠性。
3.3.1 吞吐量（Throughput）
吞吐量，指的是单位时间内系统能处理的请求数量。常用单位是QPS（每秒查询数）或TPS（每秒事务数）。
负载均衡器的吞吐量，决定了它能扛住多大的流量。举个例子：
- 单机Nginx，在普通硬件上，七层代理的吞吐量大概在几万QPS。
- LVS（四层），同样硬件，吞吐量可以到几十万甚至上百万QPS。
为什么会差这么多？因为Nginx需要做HTTP协议解析，而LVS在内核态直接转发报文，几乎没有额外开销。
实战经验：我在压测一个网关服务时，发现吞吐量上不去。排查了半天，最后发现是负载均衡器的CPU先打满了。换了个更高效的方案后，吞吐量直接翻了三倍。所以，选型时一定要考虑吞吐量上限，留足余量。
3.3.2 延迟（Latency）
延迟，指的是一个请求从发出到收到响应所花费的时间。负载均衡器本身会引入一定的延迟，这个延迟越小越好。
延迟通常分为两部分：
- 网络延迟：数据包在网络上传输的时间。
- 处理延迟：负载均衡器处理请求的时间（包括协议解析、路由决策、连接管理等）。
我习惯用P99（99%的请求延迟）来衡量系统性能。为什么不用平均值？因为平均值容易被少数慢请求拉低，而P99能真实反映大多数用户的体验。
避坑指南：我曾经在项目中遇到一个问题——负载均衡器配置了健康检查，但健康检查的频率太高，导致后端服务器频繁被标记为「不健康」，流量不断切换，反而增加了延迟。后来我把健康检查间隔从1秒调整到5秒，问题就解决了。有时候，过度「积极」反而会坏事。
3.3.3 一致性（Consistency）
一致性，在负载均衡的语境下，通常指的是「会话保持」或「哈希一致性」。简单说，就是同一个用户的请求，能不能始终落到同一台后端服务器上。
为什么需要一致性？因为很多应用是有状态的。比如：
- 用户登录后，session信息存在服务器A的内存里。
- 下一个请求被转发到服务器B，服务器B没有这个session，用户就得重新登录。
解决这个问题，常见的方法有：
- 源地址哈希：根据客户端IP做哈希，同一个IP的请求始终发到同一台服务器。
- Cookie插入：负载均衡器在响应中插入一个Cookie，后续请求根据Cookie值路由。
- 一致性哈希：在分布式缓存场景中，用一致性哈希算法减少节点增减时的缓存失效。
注意：一致性不是万能的。如果后端服务器宕机，一致性策略会导致该服务器上的所有用户都受影响。所以，实际项目中，我通常会把「一致性」和「高可用」结合起来——优先保证一致性，但服务器挂了就自动切到其他机器，牺牲一致性保可用性。
3.4 知识体系总览
为了让你更直观地理解这一节的内容，我画了一张图，把负载均衡的基础知识串起来。
3.5 小结
这一节的内容，说白了就是三件事：
- 负载均衡是什么：把请求分散到多台服务器，提高系统的吞吐量和可用性。
- 四层和七层怎么选：性能优先选四层，灵活优先选七层。没有的好坏，只有合不合适的场景。
- 三个核心指标：吞吐量、延迟、一致性。做方案时，这三个指标必须量化，不能凭感觉。