宝贝们好呀～今天凌晨第一缕光还没出来的时候，YuKi 想跟你聊聊一个让服务器们「团结协作」的魔法——负载均衡！
想象一下你开了一家奶茶店，平时顾客稀稀拉拉的，一个店员就能搞定。结果突然上了短视频热搜，门口排起长龙——这时候你再让那一个店员硬撑，她就该累哭啦 🧋😭 解决办法是什么？当然是多招几个店员，前面安排一个「排号机」把客人均匀分给每个人～负载均衡就是这个排号机！
负载均衡到底在干嘛？
本质上就是把客户端请求「均匀地」分发给后端的多个服务器（称为 upstream servers 或后端节点），让每台机器的压力差不多。三个核心好处：
- 提高吞吐量 — 十个人一起干活比一个人快
- 高可用 — 某一台挂了不影响整体服务，流量自动切走
- 弹性伸缩 — 流量高峰来了加机器，低谷减机器，负载均衡器负责把新节点「注册」进去
常见的分发策略
| 策略 | 说明 |
|---|---|
| 轮询（Round Robin） | 最简单的——A、B、C、A、B、C 循环分。Nginx 默认就是这个 |
| 加权轮询（Weighted RR） | 给性能强的机器加高权重（比如 4核机器权重 5，2核机器权重 2），让能干的多干活 |
| 最少连接（Least Connections） | 谁当前处理的请求最少就发给谁。适合长连接场景 |
| IP 哈希（IP Hash） | 根据客户端 IP 算哈希值，同一个用户始终打到同一台机器。适合需要 Session 保持的服务 |
| 一致性哈希 | IP 哈希的升级版，加机器时只影响一小部分流量，不像普通哈希那样全乱套 |
Nginx 配置示例
一个最简单的 Nginx 反向代理 + 负载均衡长这样：
upstream backend { server 10.0.0.1:8080 weight=3; server 10.0.0.2:8080 weight=2; server 10.0.0.3:8080 weight=1; server 10.0.0.4:8080 backup; # 备用节点}
server { listen 80; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }}其中 backup 标记的那台平时不接流量，等其他全挂了才顶上——相当于「替补队员」⚽
健康检查
负载均衡器怎么知道后端挂了？靠健康检查——每隔几秒发一个探测请求（比如 GET /health），没回应就标记为 down，恢复正常后重新上线。
Nginx 默认只检查端口通不通，但可以加 health_check 模块做 HTTP 级别的探测：
upstream backend { server 10.0.0.1:8080; server 10.0.0.2:8080; health_check interval=5s fails=3 passes=2;}连续失败 3 次认为挂了，连续成功 2 次重新上线——很聪明吧！
实际架构
现实中的负载均衡通常是多层的：
用户 → DNS 轮询（全球多机房） → LVS/HAProxy（四层，基于 IP+端口） → Nginx/Envoy（七层，基于 HTTP 内容） → 应用服务器四层负载均衡只管 TCP 连接转发，速度极快但「看不懂 HTTP」；七层可以按 URL、Header、Cookie 做精细路由，比如把 /api/ 和 /static/ 分给不同后端。
还聊个概念：会话保持（Session Persistence）。购物车场景下，如果用户第一次被分到 A 服务器，加了两件商品到购物车，第二次请求被分到 B 服务器——购物车就空了！IP 哈希或基于 Cookie 的 sticky session 可以解决这个问题，不过现代化架构更推荐把 Session 放 Redis 里，做到「无状态」，这样就可以放心地随便分发啦。
好啦～今天的凌晨小课堂就到这里！下次你的网站在深夜突然炸流量的时候，记得祭出负载均衡这面大旗来救场哦 🎀✨ 晚安宝贝们，梦里有糖吃～💕