什么是负载均衡：一万个人同时点进来，网站为什么没倒

设想一个场景：你开了一家小面馆，生意好到排长队。一个人掌勺，队伍越排越长，最后大家等得不耐烦走掉大半。你会怎么办？多雇几个厨师，再安排一个人在门口分流：这队去一号窗口，那队去二号窗口。这就是负载均衡最朴素的样子。

网站也是一样。一个应用火了之后，访问量可能在几分钟内翻几十倍——比如电商大促开始的那一秒，或者一条内容突然上了热门。所有请求都涌向同一台服务器时，它的 CPU、内存和网络带宽很快会被占满，响应越来越慢，最后直接超时、报错，页面打不开。问题往往不是程序写得不好，而是「人太多，一个厨师忙不过来」。

负载均衡做的三件事

负载均衡（Load Balancing）就是在用户和服务器群之间加一个「分流员」：请求先到它这里，再由它按某种规则分配给后面多台服务器中的一台。它主要解决三个问题：

第一，分摊压力。 十台服务器一起干活，每台只承担十分之一的请求，单台被压垮的概率大大降低。想扩容也简单：往后面加机器就行，分流员自然会把新请求分过去。

第二，故障兜底。 分流员会定期「点名」——给每台服务器发健康检查。如果某台机器没回应，它就自动把流量切走，用户几乎无感。等机器修好重新回应，再把它加回来。对用户来说，网站一直是好的；对运维来说，坏一台机器不再是半夜爬起来救火的事故。

第三，就近和灵活调度。 流量可以按地域分（让离用户近的机房来响应）、按权重分（性能强的机器多分一点）、也可以让同一个用户的请求固定落到同一台机器上（比如购物车信息存在本地时）。这些都是分流规则的不同选择。

常见的分流规则

• 轮询：一台接一台轮流分，最简单、最公平，适合各台机器性能差不多的情况。
• 最少连接：谁当前手头请求最少就分给谁。适合请求处理时间长短不一的场景，比如有的查询一秒返回、有的要算十秒。
• 源地址哈希：按用户 IP 计算，同一个用户的请求总是落到同一台服务器。适合需要保持会话状态的场景。
• 加权轮询：给性能强的机器设更高的权重，让它多接一些；新上线的弱机器少接一些。

没有哪种规则是万能的，选错了反而会让流量分配不均。判断标准其实就一条：你的请求是不是「时长差不多、彼此无状态」。是，就用轮询这类简单的；不是，就要考虑连接数和会话保持。

它工作在哪一层

按工作层次，负载均衡常分为两类。四层负载均衡工作在传输层，只看 IP 和端口就做转发，速度快，像个只认门牌号的分拣员；七层负载均衡工作在应用层，能看懂 HTTP 请求的内容——网址路径、请求头、Cookie 都能作为分流依据，比如把图片请求分到静态资源服务器、把接口请求分到应用服务器，代价是处理开销稍大。

云服务里的弹性负载均衡产品大多两者都支持：对外的高并发入口用四层扛量，对内的精细路由用七层调度，组合起来用。

一个容易踩的坑

上了负载均衡不等于万事大吉。最常见的坑是会话状态：用户登录信息如果只存在某一台服务器的内存里，下一次请求被分到另一台机器，就会被当成没登录。解法要么用源地址哈希让同一用户固定落点（扩容时又会打乱），要么干脆把会话抽出来放到独立的缓存里，让所有机器共享——后者是现在更主流的做法。

另一个坑是健康检查太迟钝：机器已经卡死了，检查间隔太长，分流员还在往它身上送请求。检查频率和判定阈值要根据业务的容忍度来设，没有标准答案。

小结

负载均衡的本质，是把「一台机器扛所有」变成「一群机器分着扛」，并在有机器掉队时自动绕开它。它不直接让单次请求变快，但它决定了系统在流量洪峰和局部故障面前能不能站得住。下次再遇到大促页面丝般顺滑、或者某个服务挂了一台机器你却毫无察觉，背后大概率就有它在默默分流。