如何进行负载均衡

负载均衡，何进衡说白了就是行负一句话：别让一台机器累死，也别让其他机器闲着看戏。载均 我见过太多初创团队，何进衡服务器一挂就手忙脚乱加配置，行负结果流量高峰一来，载均单点瓶颈照样崩。何进衡真正该做的行负，是载均在入口处就分流。 先看最基础的何进衡做法——DNS轮询。 把同一个域名解析到多台服务器的行负IP，浏览器每次请求都会随机命中一个。载均这招零成本，何进衡但有个致命缺陷：DNS缓存会让流量分配失真。行负某个用户可能一整天都卡在同一台机器上，载均而那台机器已经快扛不住了。 更麻烦的是，如果某台服务器宕机，DNS不会自动摘除它，用户依然会被引导到死胡同。 稍微靠谱点的方案是反向代理，比如Nginx。 你可以在配置里写`upstream`块，定义一组后端服务器，然后设置权重。比如`server 192.168.1.10 weight=3`，那这台机器就会收到三倍于其他机器的请求。 这里有个细节很多人忽略——健康检查。Nginx默认不会主动探测后端是否存活，你得配`max_fails`和`fail_timeout`。我见过一个案例，某团队没配这俩参数，后端一台机器内存泄漏挂了，Nginx还傻乎乎地继续转发，结果用户看到的是半个页面加载失败，排查了整整两小时。 再往上走，就该谈负载均衡器的算法了。 `least_conn`——谁当前连接数少就发给谁，适合长连接场景，比如WebSocket。 `ip_hash`——同一IP固定打到同一台机器，解决session一致性问题。但注意，如果用户用手机流量，IP会频繁变动，这招就失灵了。 还有个冷门但实用的`consistent_hash`，它按URL或参数做哈希，能让同一类请求始终落在同一节点，对缓存命中率极其友好。我做过一个电商项目，商品详情页用这个算法后，后端Redis命中率从61%飙到89%，响应时间直接砍半。 别以为配完就万事大吉。 负载均衡器本身也会成为单点故障。你得给它做高可用，比如用Keepalived做VIP漂移。 我习惯把两台Nginx都挂上keepalived，虚拟IP绑在master上，slave时刻监听心跳。一旦master宕机，VIP自动切到slave，整个过程对用户无感——但前提是你得测过切换时间。我见过有人配了keepalived，却因为防火墙没放行VRRP协议，切换时VIP死活漂移不过去，线上事故持续了整整三分钟。 最后说个反直觉的观察。 很多团队过度追求负载均衡器的性能，却忘了后端服务的扩展性。你就算用LVS把每秒十万请求分发给一百台机器，每台机器每秒只处理一千个请求——但如果这些请求都卡在数据库查询上，每台机器照样会拖垮整个集群。 真正的负载均衡，是从客户端到数据库每一层的协同。入口分流只是第一步，你得同时关注连接池大小、线程池上限、缓存策略，甚至SQL查询的慢日志。 我见过最蠢的故障，是某团队把负载均衡器配得完美无缺，但后端每台服务器都连同一个Redis，Redis一崩，全网瘫痪。 均衡不是终点，只是起点。