为什么一家店忙不过来，还要开好几家一起干？

第五期讲过：CDN 把你带到最近的门店。可进了店，如果只有一个柜台，人一多照样排长队。网站也一样——请求都挤到同一台服务器上就会扛不住。解决办法是负载均衡（load balancing）：多开几家柜台，门口再放一个导购来分人。下面分 6 步讲清楚。

6 步看懂负载均衡

1. 一家柜台排长队#▶ 从这里看

• 接第五期：CDN 解决的是路太远，把你带到附近的门店。
• 进店之后还有另一件事：人太多。只有一台服务器接所有请求时，队列变长，页面会转圈、超时。

2. 单点忙不过来#▶ 从这里看

• 单点故障（single point of failure）：整家店只靠一个柜台，它一停，店就关门。
• 远的人慢，是 CDN 管的；人一多挤垮柜台，是负载均衡要管的。
• 一台机器的中央处理器、内存、网口能力都有限，高峰时更容易顶满——具体上限取决于程序和硬件，这里只讲量级：一台接不住所有人时，就要水平加机器。

3. 多开柜台加导购#▶ 从这里看

• 后端服务器（backend）：真正处理业务的柜台，可以有多台，配置通常一样。
• 负载均衡器（load balancer）：门口的导购。你访问的还是同一个网站地址，请求先到导购，再被分到某家柜台。¹²
• 对外看起来仍是一家店，背后好几家柜台一起接单，队伍就短了。

4. 怎么分人#▶ 从这里看

常见分法有两类（名字因实现而异，意思差不多）：²

1. 轮询（round-robin）：一人一家柜台，轮着来。简单，请求长短差不多时够用。
2. 最少连接（least connections）：哪台服务器当前的活动连接少，就往哪指（连接数是估算忙闲的指标，不等于正在处理的请求数）；有的请求特别久时，比轮询更公平。

不管哪种分法，前提是柜台得开着——这就是下一节的健康检查。

还有按客户端地址做哈希、给某些柜台加权等变体，本期不展开。

5. 健康检查#▶ 从这里看

• 健康检查（health check）：导购定时问柜台「还开着吗？」。常见做法是发一个 HTTP 请求，看是否在时限内返回约定的成功状态（例如 200）。³
• 柜台不回、或回得不对，就先从名单里拿掉，不派单；恢复后再加回来。
• 弹性扩展（auto scaling，也叫自动伸缩）是另一件事：人多时自动多开几家柜台，人少时再关掉，按负载自动增减机器数量，而不是只靠把一台机器越配越强。⁴⁵
• 两者怎么配合：弹性扩展负责「开几家柜台」；新柜台开出来后会被登记到负载均衡器的名单里，通过健康检查后，导购才开始往那边分人。健康检查本身不会多开柜台。⁴

6. 回顾#▶ 从这里看

• CDN：去哪座城的店（路近）。
• 负载均衡：进店后去哪个柜台（人多一起干）。
• 两套经常叠在一起用：访客先被带到附近节点，节点后面再由负载均衡把请求分到多台后端。

深入一问

负载均衡器和反向代理是一回事吗？
很多负载均衡器本身就是反向代理（reverse proxy）：对访客来说它像网站本人，对后端来说它在替访客转发请求。反向代理还可以做缓存、压缩、终止 HTTPS 等；负载均衡强调的是「把流量分到多台后端」。¹

访客会不会总打到同一家柜台？
默认不一定。若登录态、购物车之类存在某一台机器的内存里，换柜台会丢状态，就要做会话保持（把同一访客尽量送到同一台），或者把状态存到所有柜台都能读到的地方（比如共享数据库）。

只有大网站才需要吗？
流量小、一台机器绰绰有余时，可以先不上。一旦一台机器经常顶满，或你担心它挂了整站就挂，就值得上多台 + 负载均衡。

易错点

• ❌ 「负载均衡就是 CDN」→ ✅ CDN 管「去哪座城」；负载均衡管「进店后去哪个柜台」，两者常一起用。
• ❌ 「多开几台机器，不用导购也行」→ ✅ 访客总得有一个统一入口；没有导购，你很难把流量自动、均匀地分出去，也很难在某台挂掉时自动躲开。
• ❌ 「健康检查通过、导购开始分人，就叫弹性扩展」→ ✅ 健康检查只决定「往哪些柜台分人」；弹性扩展是按负载自动增减柜台数量，是另一套机制。
• ❌ 「健康检查就是偶尔手动看一眼」→ ✅ 是导购按固定间隔自动探测，失败就停派单。
• ❌ 「轮询一定最公平」→ ✅ 请求耗时差很多时，最少连接往往更均匀。

参考资料