选负载均衡器需先算清带宽账：阿里云6mbps是成本分水岭，超量后单价跳涨；两台5mbps ecs配slb比单台10mbps更省且具备故障隔离与弹性扩缩能力。
选负载均衡器前先算清带宽账
阿里云6Mbps是成本分水岭——超过它，单价跳涨明显；但很多人直接买10Mbps单实例，其实多花冤枉钱。真相是：用两台5Mbps的ECS+SLB，总费用更低，还能获得故障隔离和弹性扩缩能力。
- 别只看单台服务器带宽标称值，要算
总流量吞吐成本：比如日均1TB出网流量，在6Mbps档位按固定带宽计费更省；超量后切按流量计费反而失控 - SLB本身不收带宽费，只收实例费（约¥18/月起）和少量连接数费，但能让你把高带宽压力“摊薄”到多台低配机器上
- 警惕“免费SLB陷阱”：部分云厂商默认提供共享型SLB，连接数、QPS、新建连接速率都有硬上限，突发流量一来就排队，表面省钱实则伤体验
动态权重调度比轮询省30%以上资源
静态round_robin或weighted_round_robin在真实业务里经常失灵——一台CPU已跑90%，另一台才20%，流量还照分，等于主动制造瓶颈。
- 必须开启实时负载采集：让SLB能读取后端节点的
CPU利用率、连接数、内存使用率，至少每5秒更新一次权重 - 权重计算别用简单线性衰减，推荐用滑动窗口+阈值抑制：比如CPU＞80%时权重×0.5，但连续3次低于70%才恢复原权，防抖动
- MySQL读写分离场景下，只读节点权重可设更高（如1.5），主库权重压低（如0.7），配合
routing_strategy = first-available自动避让慢节点
健康检查配置错，等于白搭SLB
很多团队开了SLB却仍出现用户访问502，查半天发现是health_check_timeout设成1秒，而应用冷启动要3秒——健康检查永远失败，节点被持续摘除。
-
health_check_interval建议≥health_check_timeout×2，比如超时设3秒，间隔至少7秒，避免高频误杀 - HTTP健康检查路径别用
/healthz这种裸路径，要带业务语义，比如/api/v1/ready?check=db，否则数据库挂了你也感知不到 - TCP层检查不够：对Java应用，仅通端口不代表服务就绪，必须加HTTP探针；对Go微服务，可复用
/live和/ready端点，但得确认它们真做依赖检查
会话保持不是万能解，Redis共享才是稳态基础
用ip_hash做会话保持？NAT环境下一群用户挤同一台机器；用cookie粘滞？前端改域名、HTTPS升级、CDN缓存都可能丢cookie——结果就是登录态频繁失效。
- 真正低成本稳态方案：所有后端节点共用
redis存session，SLB彻底无状态，删节点、扩节点、滚动发布都不影响用户 - 如果非要用SLB级会话保持，优先选
sticky_session+cookie_insert，且cookie_max_age设为业务最大空闲时间（如30分钟），别用永不过期 - 视频会议类长连接业务，会话保持粒度要升到
connection级，而非HTTP请求级，否则一个页面多个XHR会分散到不同节点，信令乱序
