负载均衡入门：流量为什么不能只压在一台服务器上

你有没有遇到过这样的场景：一个小网站刚上线时跑得好好的，活动一推广，页面突然转半天，最后干脆打不开了。很多人第一反应是“配置不够，升级就好”。升级确实能顶一阵，但流量再涨，总有一天会发现：再大的单机，也有扛不住的时候。

一、单机到底卡在哪里

一台服务器的资源是有限的：CPU 核心数、内存、磁盘读写速度、网卡带宽，每一项都有上限。流量上来后，瓶颈可能出现在任何环节：CPU 被请求占满，响应变慢；内存不够，进程频繁交换；带宽跑满，下载卡顿；磁盘 I/O 跟不上，数据库查询排队。

更要命的是，单机还是一个“单点故障”：一旦宕机、断电或重启，整个服务就跟着停摆。升级单机看起来简单，但成本越涨越快，而且单机规格永远有天花板。

二、负载均衡是什么

负载均衡的做法，是在用户和后端服务器之间加一层“分发器”：用户请求先到负载均衡器，再由它按规则分发到后面多台服务器处理。

好处很直接：多台服务器一起干活，单台压力降下来；某台挂了，流量自动转给其他健康机器，服务不中断；流量涨了加机器、降了减机器，不用再为单机上限发愁。

三、四层与七层的区别

负载均衡通常分四层和七层两种，区别在于它“看”到哪一层的信息。

四层工作在传输层，主要根据 IP 地址和端口号分发，不关心请求内容，只负责把连接转发到后端，效率高、延迟低，适合性能要求高、协议多样的场景。

七层工作在应用层，能读懂 HTTP 请求的内容，比如 URL 路径、请求头、Cookie。它可以按内容做更精细的分发，比如把图片请求发给静态资源服务器，把登录请求发给认证服务。

怎么选？只分担流量，四层就够；要按业务规则分流、做基于内容的路由，就需要七层。

四、常见分发策略

同一个负载均衡器，分发规则也可以不同：

• 轮询：按顺序轮流分发，每台服务器雨露均沾，简单公平，适合机器配置差不多、请求耗时也差不多的场景。
• 最少连接：把新请求发给当前连接数最少的服务器，适合请求耗时差异大的场景，避免某台机器被长请求拖垮。
• 哈希：按客户端 IP 或某个字段算哈希，同一来源的请求总发到同一台服务器，适合需要会话保持、比如登录状态存在本机内存的场景。

五、健康检查不能少

负载均衡器会定期对后端服务器做健康检查：发一个探测请求，如果某台机器多次没有响应，就把它暂时从分发名单摘掉，等恢复了再放回来。

这个机制很关键：没有健康检查，坏掉的机器还会继续收到请求。探测间隔和失败阈值要合理：太频繁会增加负担，太宽松又会让故障发现太慢。

六、新手注意事项

• 先想清楚再上：流量很小的个人项目，单机就够了，不要为了用技术而用技术。
• 会话保持要小心：用了哈希或粘性会话，扩容和故障转移都会受影响，能用无状态设计就尽量无状态。
• 别让负载均衡器本身成为单点：生产环境里，负载均衡器也要做高可用，至少两台互备。
• 留意后端配置：分发策略只是入口，后端服务器的连接数、超时时间也要相应调整，否则瓶颈会转移而不是消失。
• 观察指标再调优：上线后盯着各台机器的 CPU、连接数和响应时间看，策略不合适就及时换。

结尾

单台服务器的上限，早晚会被流量追上。负载均衡的核心思想很朴素：别让一台机器扛下所有事，让多台机器一起分担，再把坏掉的机器及时摘出去。