负载均衡的原理：不只是分摊压力
你有没有遇到过双十一大促时，打开某个购物网站特别慢，甚至直接打不开？而有些大平台却依然稳如老狗。这背后，除了服务器多，还有一个关键技术在起作用——负载均衡。
简单说，负载均衡就像是商场里的多个收银台。如果只有一个收银员，顾客排长队，效率低下。但如果有十个收银台，并且有专人引导顾客去人少的窗口，结账速度自然就上来了。负载均衡干的就是这个“引导”的活儿。
请求太多怎么办？分出去
当一个网站访问量暴增，单台服务器扛不住，响应变慢甚至崩溃。这时候，把流量合理地分给多台服务器，就成了必须的选择。负载均衡器就站到了用户和服务器之间，像交通指挥员一样，决定每个请求该交给哪台机器处理。
常见的分配策略有不少。比如“轮询”，就是按顺序一个接一个地分，第一台、第二台、第三台……循环下去。适合服务器性能差不多的场景。
还有“加权轮询”，给性能强的服务器多分点活。比如一台服务器配置是另一台的两倍，那就让它处理两倍的请求。这样资源利用更合理。
另外，“最小连接数”策略会看哪台服务器正在处理的请求最少，就把新请求发给它。避免某台机器已经忙得冒烟，还继续往它身上压任务。
硬件还是软件？都在用
早些年，负载均衡靠专门的硬件设备，比如F5。这类设备性能强、稳定性高，但价格也贵，一般大公司才用得起。现在更多是用软件方案，比如Nginx、HAProxy，成本低，灵活性高，中小团队也能轻松上手。
拿Nginx举例，配置起来很简单。比如下面这段配置：
upstream backend {
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=2;
server 192.168.1.12:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}这里定义了三台后端服务器，前两台带权重，第三台默认权重为1。Nginx会根据配置自动分配请求。
健康检查：别把请求发给“死机”的服务器
负载均衡不只是转发请求，还得会“看病”。如果某台服务器挂了，或者响应超时，就不能再往上面派活。系统会定期发送探测请求，比如访问一个/health接口，如果连续几次没回应，就把它从可用列表里摘掉。等它恢复了，再重新加入。
这种机制保证了整个系统的容错能力。哪怕坏了一两台机器，用户几乎感觉不到异常。
实际场景中的意义
你每天刷的短视频、点的外卖、查的导航，背后都是成千上万台服务器在协作。没有负载均衡，这些服务很容易因为局部故障或流量高峰而瘫痪。它不光提升了响应速度，也让系统更可靠、更容易扩展。想加服务器？加完告诉负载均衡器就行，不用改前端逻辑。
说白了，负载均衡的核心目标就两个：别让机器闲着，也别让机器累死。在“忙”和“闲”之间找到平衡，让用户访问更顺畅。