负载均衡需系统化落地，核心解决性能瓶颈、单点风险与资源失衡三大矛盾；须明确均衡目标，合理选型四层/七层，匹配算法（如iotdb场景宜用一致性哈希），并完善健康检查、异常兜底与压测验证。
负载均衡不是加个Nginx配置就完事的事。真正落地时，得从流量怎么进来、算法怎么选、节点怎么活、异常怎么兜底，一路走到压测验证它到底扛不扛得住——每个环节都可能成为线上故障的导火索。
接入前先理清三件事：你到底在均衡什么？
很多人一上来就配upstream，却没想清楚底层目标。负载均衡本质是解决三个矛盾：
- 性能瓶颈 vs 横向扩展：单台服务器QPS到2000就打满？那必须靠多节点分担，而不是堆硬件
- 单点风险 vs 高可用保障：一台挂了，用户是否直接看到502？健康检查+自动摘除必须生效
- 资源闲置 vs 利用率失衡：监控里总有一台CPU跑95%，另两台才20%？说明调度策略和实际负载不匹配
比如IoTDB集群写入突增时，若只用轮询，容易把大量时间序列请求打到同一台数据节点，引发热点；换成一致性哈希+按设备ID分区，就能让写入天然分散。
四层和七层怎么选？别被“高级”带偏
关键看你要在哪一层做决策：
- 选四层（如NLB、LVS）：要极致性能（10万+ QPS）、低延迟（
- 选七层（如Nginx、HAProxy、API网关）：需要按路径路由（/api/v2 → 新版服务）、按Header灰度（x-env: canary）、做SSL卸载、限流熔断——这些都得解析HTTP
电商大促入口用NLB做第一道分流，再由Nginx按商品类目二次分发，就是典型的分层负载策略。硬全用七层，反而成性能瓶颈。
算法不是贴标签，而是匹配业务特征
轮询、加权、最小连接……这些名字背后是不同的假设。选错等于埋雷：
- 轮询：适合无状态、同构服务（如静态API），但某台机器刚升级过内核，处理快20%，它却只分到1/3流量
- 加权轮询：适合混部环境（比如新老机型共存），权重设为CPU核数比（8核:16核 = 1:2），但需人工维护，扩容时容易漏调
- 最小连接：WebSocket、长轮询场景首选，可避免新连接挤爆已满载的连接池；但要注意连接统计是否实时（Nginx默认只统计活跃连接，不包括TIME_WAIT）
- 响应时间加权（WRT）：适合支付类系统，自动降低响应慢节点的权重，但需后端主动上报指标或LB侧主动探测，否则不准
某视频平台曾因用轮询调度转码服务，导致高分辨率任务集中到某台GPU服务器，转码失败率飙升至12%；切到最小连接后，失败率降至0.3%。
压测不是“打满再说”，而是验证全链路闭环
真实压测要覆盖四个关键断面：
- 健康检查有效性：模拟一台后端进程僵死（CPU 100%但端口仍通），看LB能否在10秒内摘除，而不是继续转发超时请求
- 故障转移真实性：杀掉一台服务，观察客户端是否在3秒内收到新响应（非重试后），确认会话保持未误伤、连接复用未卡住
- 算法收敛性：持续压测10分钟，看各节点QPS标准差是否
- 极限吞吐稳定性：在95%峰值下持续运行1小时，观察错误率是否稳定在0.1%以内，P99延迟是否无明显毛刺
IoTDB压测中发现，当集群写入达80万点/秒时，NLB后端连接数暴涨，部分节点因TIME_WAIT堆积触发端口耗尽；最终通过调大net.ipv4.ip_local_port_range + 开启tcp_tw_reuse才解决——这只有压测才能暴露。
接入负载均衡不是部署动作，而是架构决策的延续。它能不能稳，取决于你有没有想清楚流量特征、节点差异、故障模式和验证方法。不复杂，但容易忽略。
