新手心得：负载均衡到底在忙什么

热门 App 一上新活动，几十万人同时点开，页面却没有卡死；背后往往不是一台超级服务器在硬扛，而是一群普通服务器在分工。站在它们前面指挥交通的，就是负载均衡。

先说它是什么。负载均衡就是把涌进来的请求，按照某种规则分发给后面多台服务器，让任何一台都不至于被压垮。生活里的比方很好理解：超市高峰期只开一个收银台，队伍会排到货架尽头；多开几个收银台，再安排一个人在入口处引导——“您去三号台、您去五号台”，队伍立刻就短了。负载均衡干的就是入口处那个引导员的活，只不过它引导的是网络请求。

它是怎么工作的？对外，网站通常只露出一个入口地址，用户并不直接和某台具体的服务器打交道；对内，入口后面站着一组干同样活的服务器，叫后端。请求一到，负载均衡先挑一台后端，把请求交过去，拿到结果后再送回给用户；用户只觉得网站能打开，并不知道这次是哪台服务器招待了自己。

挑哪一台，是有讲究的，常见的分法有几种。最简单的是轮询：按顺序一个一个轮着来，第一台、第二台、第三台，再回到第一台，公平但不管每台忙不忙。改进版是加权轮询：配置高的机器多分一点，配置低的少分一点，量力而行。还有最少连接：谁手头正在处理的连接最少，就把新请求派给谁，适合请求耗时差别很大的场景。另外一种是按来源地址算哈希：同一个用户总是落到同一台后端上，这叫会话保持，适合把登录状态存在单台机器上的老系统——但状态一旦绑死，那台机器出问题时会话也会跟着受影响，是个妥协。

除了“怎么分”，还要看“按什么信息分”，这就分出了四层和七层两种。简单理解：四层只看连接层面的信息，比如 IP 和端口，不拆开看请求里面写了什么，速度快、开销小；七层会读到应用层，看 URL 路径、域名、请求头再做决定，比如把图片请求和登录请求派给不同的后端，灵活得多，但拆包解析的代价也更大。两者没有绝对好坏，只有合不合适。

负载均衡真正重要的地方，其实不只是“分担压力”，更是“容错”。它会不停地给后端做健康检查：定时问一句“你还活着吗、还能干活吗”。一旦某台服务器没回应或者报错连连，它就会暂时把这台从名单里摘掉，不再派活过去，等它恢复了再放回来。这样一来，单台机器宕机，用户最多感觉到一点波动，而不是整个网站打不开。反过来，流量涨了也不用换一台更大的机器，只要往后端再加几台，整体能力就跟着涨，这就是所谓的横向扩展。

最后澄清几个常见误解。第一，负载均衡本身不是万能药：如果后端全都过载，或者数据库先扛不住了，前面分得再均匀也没用，瓶颈只是换了个地方。第二，均衡不等于平均：轮询分的是请求个数，不是工作量，几个耗时的大请求恰好落到同一台上，那台照样会累。第三，负载均衡器自己也可能成为单点：一台引导员倒下了，后面再多收银台也没用，所以生产环境里它自己往往也要做成高可用的一对，或者多台互备。

总结一下：负载均衡的本质，是用“一个入口、多台后端、持续体检、按规则分流”换来稳定和可扩展。下次看到大促期间网站纹丝不动，脑子里可以过一遍：入口处有人分流，后端有人体检，哪台累了就先歇着——这就是负载均衡在忙的事。