负载均衡基础：从概念到实战
各位同学好，我是老张。今天咱们聊聊负载均衡。
说实话，我入行那会儿，负载均衡还是个挺神秘的东西。那时候公司刚上第一套F5，大家都围着看，觉得这玩意儿能自动分流，太神奇了。现在呢？随便一个云服务商都标配了。但基础原理，其实没变过。
什么是负载均衡？
说白了，就是「别让一台机器累死」。
你想想看，一个网站访问量大了，单台服务器扛不住。怎么办？加机器。但加完机器，流量怎么分？总不能用户点一下，你手动分配吧？
负载均衡干的就是这件事——它站在服务器前面，像个交通指挥员。来一个请求，它看看哪台服务器空闲，就把请求扔过去。
核心定义：负载均衡是一种将网络流量分发到多个后端服务器的技术。目的是提高系统容量、增强可用性、降低延迟。
我在项目中遇到过最典型的场景：双十一大促。平时100台服务器够用，大促那天流量翻10倍。没有负载均衡？那只能看着服务器一个个挂掉。有了它，你只需要提前扩容，流量自动分配。
负载均衡的层级：L4 vs L7
这里有个关键概念——层级。我习惯把负载均衡分成两层：四层和七层。
为什么叫四层、七层？因为OSI模型。四层是传输层，七层是应用层。嗯，这里要注意，实际工作中我们很少纠结OSI七层全部，但这两个层级必须搞明白。
| 对比项 | L4（四层） | L7（七层） |
|---|---|---|
| 工作层级 | 传输层（TCP/UDP） | 应用层（HTTP/HTTPS） |
| 转发依据 | IP + 端口 | URL、Header、Cookie等 |
| 性能 | 高（内核态转发） | 较低（需要解析报文） |
| 灵活性 | 低 | 高 |
| 典型产品 | LVS、F5 LTM | Nginx、HAProxy |
L4负载均衡
四层负载均衡，只看IP和端口。它不关心你发的是什么内容，是HTTP还是MySQL，它不管。它只做一件事：把数据包从入口转发到后端。
我曾经用LVS做过一个游戏服务器的负载均衡。游戏用的是自定义TCP协议，七层根本解析不了。这时候只能用四层。性能也高，单机轻松跑满万兆。
我的建议：如果你的业务协议是自定义的，或者对性能要求极高（比如每秒百万连接），优先考虑L4。
L7负载均衡
七层就不一样了。它能看懂HTTP协议，知道用户访问的是 /api/login 还是 /static/image.jpg。然后根据这些信息做精细化调度。
举个例子。我做过一个电商平台，静态资源用CDN，动态请求走应用服务器。七层负载均衡可以做到：看到 .jpg、.css 后缀，直接转发到CDN节点；看到 /api/，转发到后端Java服务。
这种灵活性，四层做不到。
注意：七层需要解析报文内容，会消耗更多CPU。高并发场景下，七层负载均衡本身可能成为瓶颈。我曾经踩过这个坑——Nginx单机扛到5万QPS就开始丢包了。
负载均衡算法：选哪个？
算法决定了「下一个请求该给谁」。我常用的有四种，咱们一个一个说。
1. 轮询（Round Robin）
最简单。请求来了，按顺序分：第一个给A，第二个给B，第三个给C，然后循环。
适合场景：后端服务器配置一样，请求处理时间差不多。
我刚开始做负载均衡时，全用轮询。后来发现不对劲——有的请求处理快，有的慢。轮询不管这些，结果就是慢请求堆积，快的服务器闲着。
2. 最小连接（Least Connections）
这个就聪明一点。它看每台服务器当前有多少活跃连接，把新请求给连接数最少的那个。
适合场景：请求处理时间差异大。比如有的请求查数据库要2秒，有的只要10毫秒。
我在一个在线教育项目里用过。学生连上来做直播推流，有的推流时间长，有的短。用最小连接算法，服务器负载均衡多了。
3. 加权（Weighted）
有时候服务器配置不一样。一台是64核，一台是16核。你让它们平分流量？不合理。
加权算法就是给每台服务器设个权重。64核的权重设4，16核的设1。流量按4:1分配。
我建议：权重根据实际压测结果来调，别拍脑袋。我曾经见过有人把权重设成10:1，结果小机器直接被打挂。
4. 哈希（Hash）
哈希算法最特别。它不关心服务器负载，而是根据请求的某个特征（比如客户端IP、URL）计算哈希值，然后映射到某台服务器。
好处是：同一个客户端的请求，永远打到同一台服务器。这对有状态的服务特别重要。比如用户登录后，session存在A服务器，下次请求还去A，不用重新登录。
我踩过的坑：哈希算法会导致负载不均。如果某个IP段的用户特别多，那台服务器就惨了。解决方案是「一致性哈希」，这个后面章节会细讲。
| 算法 | 优点 | 缺点 | 推荐场景 |
|---|---|---|---|
| 轮询 | 实现简单，无状态 | 不考虑服务器负载 | 同配置、同处理时间的服务 |
| 最小连接 | 动态感知负载 | 需要维护连接数状态 | 请求处理时间差异大的场景 |
| 加权 | 支持异构服务器 | 权重需要手动调整 | 服务器配置不一致 |
| 哈希 | 保持会话亲和性 | 可能导致负载不均 | 有状态服务、缓存服务 |
一张图看懂负载均衡
下面这张图，是我自己画的。它展示了负载均衡的核心逻辑：用户请求进来，经过负载均衡器，根据算法分发到后端服务器池。
选型建议
说了这么多，到底怎么选？我个人习惯这样判断：
- 性能优先：选L4，比如LVS。能扛百万并发。
- 功能优先：选L7，比如Nginx。能做URL路由、SSL卸载、限流。
- 中小规模：Nginx就够了。配置简单，社区活跃。
- 大规模集群：LVS做入口四层转发，后面挂Nginx做七层精细控制。两层架构，各司其职。
一个小技巧：刚开始做负载均衡，别追求完美。先用轮询跑起来，观察一段时间。如果发现某台服务器负载特别高，再切换到最小连接或加权。逐步优化，比一步到位更靠谱。
好了，负载均衡的基础就聊到这儿。记住三个核心：层级决定能力，算法决定效率，选型决定上限。后面咱们会深入每个算法的实现细节，还有健康检查、会话保持这些实战内容。
公众号:蓝海资料掘金营，微信deep3321