选对负载均衡算法关键在于匹配业务真实运行方式：无状态服务用加权轮询，长连接场景用最少连接，需会话保持时选源ip哈希或一致性哈希，响应敏感业务用响应时间加权。
选对负载均衡算法，关键不是看它“多先进”，而是看它能不能匹配你业务的真实运行方式。同一套系统在不同阶段、不同模块，可能需要完全不同的调度逻辑。
无状态服务：加权轮询最稳妥
静态页面、RESTful API、微服务间调用这类服务不保存会话，请求之间相互独立。此时重点是让硬件资源“物尽其用”。
- 如果后端服务器配置差异明显（比如一台16核64G，另一台8核32G），直接用普通轮询会导致弱机早早打满；
- 加权轮询允许你按CPU核数、内存容量或历史QPS设定权重，例如16核设权重4，8核设权重2，流量自然按2:1分配；
- 权重值不需要精确到小数点，整数比即可，运维调整也方便，Nginx和HAProxy都原生支持。
长连接或耗时差异大：最少连接更可靠
数据库连接池、WebSocket网关、实时音视频转发等场景，单个连接可能持续数分钟甚至小时，且处理时间波动剧烈（一条SQL毫秒级，一条报表查询可能十几秒）。
- 轮询或加权轮询只管“发了多少次”，不管“还在忙多少个”，容易把新请求塞进已堆积大量慢请求的节点；
- 最少连接策略实时统计每个后端的活跃连接数，新请求永远去“最空闲”的那台，天然规避队列积压；
- 注意：该策略依赖健康检查准确上报连接数，若后端未正确关闭连接（如异常断连未清理），可能导致误判。
需要会话保持：源IP哈希或一致性哈希按需选
用户登录态、购物车、在线协作文档等必须保证同一用户后续请求落到同一台服务器上。
- 源IP哈希简单直接，适合客户端IP相对稳定、且数量分布较均匀的场景（如企业内网访问）；
- 但公网用户常走NAT，多个用户共享一个出口IP，会造成单点过载；扩容缩容时所有哈希映射重算，大量用户会话中断；
- 一致性哈希更适合分布式缓存或高可用网关，节点增减只影响约1/N的数据重分布，会话连续性更强，但实现复杂度略高。
对响应速度敏感：响应时间加权值得考虑
面向终端用户的前台服务，比如搜索页、商品详情页，用户等待超过500ms就会明显感知卡顿。
- 该策略要求负载均衡器能持续采集后端真实响应时间（不是TCP握手时间，而是完整HTTP返回耗时）；
- 适合配合APM工具使用，当某台机器因GC暂停或磁盘IO瓶颈导致延迟突增时，流量会自动倾斜到更快节点；
- 不适合短连接高频小请求（如心跳探测），因为采样噪声大，反而引发抖动。
