网站访问量忽高忽低，白天闲得发慌、晚上促销直接被打挂——这种场景下，弹性负载均衡就是那个把流量"削峰填谷"的调度器。它干的事说白了就是：把一堆请求均匀甩给后面多台服务器，哪台忙了少给点、哪台闲了多塞点、哪台挂了直接踢掉，前端用户完全感知不到背后换了机器。
核心机制拆开看
流量进来先打到负载均衡器(LB)，LB按预设策略挑一台后端服务器转发。常见策略：轮询(挨个发)、加权轮询(性能好的多扛)、最小连接数(谁闲给谁)、源IP哈希(同一用户始终落到同一台，解决会话保持问题)。四层LB(L4)只看IP+端口做转发，速度快;七层LB(L7)能解析HTTP/HTTPS内容，按URL路径、Header、Cookie做路由——比如 /api 走后端集群A，/static 走CDN或对象存储。
弹性在哪?
"弹性"不是LB自己变强，而是它和自动扩缩容(Auto Scaling)联动：监控检测到CPU超70%或请求队列堆积→自动起新机器→新机器启动完成后自动注册到LB的后端池→开始接流量;低谷时反向缩容。AWS的ALB+NAT网关+Auto Scaling Group、阿里云的SLB+ESS、腾讯云的CLB+AS，都是这套逻辑。没有LB，扩出来的机器外面流量进不去;没有Auto Scaling，LB后面机器数量固定，流量暴增还是扛不住。
健康检查是命门
LB每隔几秒向后端发探测请求(TCP握手或HTTP GET)，连续几次失败就标记为不可用、停止转发。但阈值设太敏感会误判——网络抖动就踢掉一台，流量全压到剩下机器上反而雪崩。一般设3—5次失败、间隔5—10秒，给后端留恢复窗口。
和CDN的区别
CDN是边缘缓存静态内容，离用户近;LB是源站入口做流量调度，管的是"请求最终去哪台服务器"。两者常配合用：用户→CDN→LB→后端集群，静态走CDN直接返回，动态回源经LB分发。
选型看规模：小项目用Nginx/HAProxy自建LB够用，配upstream和健康检查几行配置搞定;中大型上云厂商托管LB，省去高可用部署和维护的心智负担。不管哪种，后端至少两台起步才有意义，单机挂了LB也救不了。
