第 4 章 · 多台服务器第 4 页，共 5 页
一台服务器坏了，用户会察觉吗？
几台服务器里坏了一台，其余的还能接着干，可负载均衡器得先知道是哪一台。在它发现之前，读者会遇到什么？
为什么需要
按第 1 页留的余量，百家菜备了 6 台。坏了一台，其余 5 台的是每秒 250 个，仍然接得住晚饭高峰的 208 个。多准备一份同样的组件，一个坏了另一个还能顶上，这叫（redundancy）。
可得先知道是哪一台坏了。不知道的时候，它照样按规则往坏机器上分：时，每 6 个就有 1 个送进坏掉的那台，这些读者看到的是出错的页面。
怎样做
所以负载均衡器会定时问每台服务器「你还好吗」，这叫（health check）。你平时说的「健康」指身体；这里只表示这台服务器按时答对了检查，也就是通过了检查，不等于它的每项功能都正常。检查是这样做的：
- 每隔一段时间，负载均衡器给每台服务器发一个约定好的请求，例如要一个特定的网页，期待收到表示成功的 200。这段时间叫。
- 在规定的时间里没有回答，或者回答不对，都算没通过一次。
- 连续没通过到规定的次数，就判为不健康，从名单里移出，不再分给它新请求。这个次数叫。
- 移出以后照样检查；连续通过几次，再放回名单。
所以从坏掉到被移出，有一段空档，大约是「检查间隔 × 判定阈值」。下图里，你可以让服务器丙在第 5 秒坏掉：此后请求一到它那里就报错，检查也只得到错误的回答。
拔掉一台：从坏掉到被移出名单的空档
先看这里按「让服务器丙坏掉」，再按「下一步」或「直接看结果」，看丙从坏掉到被移出名单用了多久；然后把检查间隔换成 30 秒，或者把分法换成「交给手上活最少的一台」。
- 回了错误：这一次检查没通过
移动的点是负载均衡器发出的检查；丙移出名单以后，到丙的虚线只发检查，不分请求。
还没开始。按「让服务器丙坏掉」开始，也可以直接看结果。
图里假定丙坏掉之前 1 秒刚通过一次检查；坏的时刻不同，空档会短一些或长一些。请求的到达时刻带随机性，但每次打开都一样。图里的负载均衡器不替失败的请求改送别的服务器；有的会，例如常用的网站服务器软件 NGINX，默认在连接出错或超时（等了规定的时间还没有回答）时改送另一台，但发评论这类会改动数据的请求，已经发出去就不再改送。
检查间隔越长，空档越长，失败的请求越多。各家产品的默认值差别很大（按 2026 年 10 月的产品说明）：常用的负载均衡软件 HAProxy 默认每 2 秒检查一次，连续 3 次没通过才移出，空档约 4 到 8 秒；亚马逊的云服务 AWS 的负载均衡器默认每 30 秒一次、连续 2 次，约 1 分钟（推算）。
把分法换成「交给手上活最少的一台」（第 2 页），失败的反而更多：丙一律报错，手上的请求结束得最快，在负载均衡器看来它最闲，于是分到的比别的服务器都多。亚马逊的一篇工程文章就提醒过这种情况（2019）。
代价是什么
检查得越勤、判得越快，空档越短，可检查本身要占服务器的时间，也更容易误判：网络偶尔抖一下，好好的服务器也可能被移出去，时进时出。2025 年 10 月 AWS 就出过这样的事：检查系统把一批正常的机器反复判成坏的，移出又放回，部分客户的连接因此出错。
反过来，所有服务器同时没通过检查时，多半是检查本身或它们共用的东西出了问题，而不是 6 台一起坏了，所以 AWS 的负载均衡器这时照常把请求分给所有服务器，免得一次误判把整个网站停掉。健康检查也挡不住所有失败：发现之前的空档里照样有请求失败；一台能通过检查、却算错结果的服务器，在检查看来仍然健康。
资料来源
以下资料均于 2026-10-22 至 2026-10-23 访问。