负载均衡如何使用

凌晨两点，负载电商平台大促，均衡流量像决堤的何使洪水一样涌向服务器。单台机器扛不住了，负载CPU飙到99%，均衡页面转圈圈，何使用户骂娘。负载这时候负载均衡就是均衡那个分流闸门，把请求均匀撒到多台服务器上，何使让每台机器都别闲着，负载也别累趴下。均衡

负载均衡最直白的何使用法，就是负载DNS轮询。你在域名商那儿配几条A记录，均衡指向不同服务器IP，何使解析时轮流返回。这法子便宜，但糙得很——它不管哪台机器活着，哪台快挂了，闭着眼睛轮流来。要是某台服务器宕机了，DNS照样把流量分给它，用户直接看到“无法访问”。所以这招只适合小场景，比如个人博客、内部工具，真刀真枪的线上业务别指望它。

正经业务得用LVS或者Nginx这种七层/四层负载均衡器。Nginx配起来简单，upstream里写几个server，权重设一下，完事。但别以为就这么简单——我见过太多人配了轮询策略就以为万事大吉，结果某台机器内存泄漏，响应越来越慢，Nginx还傻乎乎地往它那儿派活。这时候得加健康检查，每隔几秒探测一次后端，探测失败就自动摘掉节点。Nginx的health_check模块能配，但默认是关闭的，你得手动开。

再往上走，就是算法选择的问题。轮询适合处理时间差不多的请求，但要是你后端接口有的快有的慢，轮询就会让慢请求堆积在某一台机器上。加权轮询能缓解，但你得手动调权重，麻烦。更聪明的做法是用least_conn，谁当前连接数少就发给谁，动态适应负载变化。还有ip_hash，把同一个IP的请求固定打到同一台机器上——这招对session stuck很有用，但也容易让某台机器流量不均，因为某个公司出口IP可能是同一个。

真到了大规模集群，软件负载均衡器本身也会成为瓶颈。这时候得上硬件F5，或者用云厂商的SLB。它们内置了全自动的健康检查、弹性伸缩、跨可用区容灾。但贵，而且你没法像Nginx那样精细控制每一条location的转发规则。我的习惯是，中小规模用Nginx，规模上来了就切到云SLB，省心。

有个细节很多人忽略——负载均衡不只是分发请求，它还得处理连接复用。HTTP/1.1的keep-alive，后端服务器如果没配置好，每次请求都重建TCP连接，那负载均衡器再聪明也白搭。我见过一个案例，后端Tomcat的maxKeepAliveRequests设成1，结果每请求都断连，负载均衡器忙得团团转，后端CPU却闲得发慌。调成-1（无限复用）之后，吞吐量直接翻倍。

最后说个反直觉的点——负载均衡有时不是解决性能问题的首选。你得先看是不是代码写得烂，SQL查得慢，缓存没命中。负载均衡只是把流量分散开，但要是每个请求本身就要花2秒，那加十台机器也救不了你。先压测，找瓶颈，再谈扩容。这道理我踩过坑才明白。