节点数量增加后，简单地把请求平均分发，未必能得到稳定结果。不同节点可能存在处理能力、连接数、网络距离和缓存内容差异，因此需要根据业务特征选择合适的节点负载均衡策略。下面从最容易落地的方法开始，比较五种常见方案，并说明实施时应关注的指标。

一、轮询：节点性能接近时的基础方案

轮询会按照固定顺序把请求依次发送到节点A、节点B、节点C，再从节点A重新开始。Nginx、HAProxy 等常见代理软件都支持这种方式，适合无状态的静态资源、普通查询接口或计算量相近的服务。

实施步骤

1. 把可接收请求的节点加入后端地址池。
2. 为每个节点设置相同的初始权重。
3. 配置失败重试和节点摘除条件，例如连续多次连接失败后暂时停止转发。
4. 观察各节点的响应时间、错误率和请求量，再决定是否调整方案。

轮询的优点是规则简单、开销低、容易排查；缺点是它只关注请求数量，不判断单个请求的处理成本。若某些请求会执行复杂报表或大文件处理，表面上的平均分配仍可能造成节点负载不均。

二、加权轮询：按处理能力分配流量

当节点配置不同，或部分节点承担更多资源时，可以使用加权轮询。比如一台节点拥有较多内存和更快的存储设备，另一台配置较低，就可以分别设置较高和较低的权重。权重并不是性能的精确比例，而是流量分配的起始参考。

在稳定网络和请求耗时相近的情况下，权重为5和权重为3的节点，长期接收的请求量通常接近5∶3，但短时间内会受到连接复用、失败重试和请求突发影响。部署后应通过一段观察周期调整，而不要仅凭硬件规格决定。

适用与限制

• 适用：新旧机器并存、云主机规格不同、部分节点需要预留容量。
• 优点：比普通轮询更能利用高性能节点。
• 限制：固定权重无法及时反映临时拥堵，节点实际负载变化较大时需要动态机制配合。

三、最少连接：适合请求耗时差异明显的服务

最少连接会优先把新请求发送给当前连接数较少的节点。它比单纯按请求次数分配更适合长连接、文件传输、在线协作或处理时间差别较大的服务。

配置时不能只看连接总数，还应确认连接是否长期占用资源。例如，一个保持数小时的空闲连接和一个正在执行复杂查询的连接，消耗并不相同。更完善的系统会把活跃连接、节点权重和响应状态一起纳入判断。

1. 确认代理层能够持续统计各节点连接数。
2. 为长连接设置合理的空闲超时，避免无效连接长期占用名额。
3. 记录连接数、请求耗时和异常断开比例。
4. 在节点恢复时采用逐步放量，避免大量连接同时涌入。

四、一致性哈希：需要保持会话或缓存命中时使用

一致性哈希会根据用户标识、设备标识或资源键计算分配结果，使相同键值通常进入同一个节点。它适合本地缓存、分片数据访问，以及不便频繁迁移的会话场景。

与普通哈希相比，一致性哈希在增删节点时只重新映射部分键，能减少全量缓存失效。但它不能替代数据持久化，也不能保证每个节点始终平均。若某个键特别热门，仍可能出现热点节点。

配置要点

• 选择稳定且分布较均匀的键，例如用户编号，而不是易变化的请求参数。
• 使用虚拟节点或等效机制改善节点分布。
• 节点扩缩容前评估缓存重建、会话迁移和回源压力。
• 对重要会话保留服务端存储，避免节点故障导致状态丢失。

五、基于延迟和健康状态的动态分配

动态分配会综合节点响应时间、错误率、排队情况和健康状态，优先选择当前更适合处理请求的节点。这是更灵活的节点负载均衡策略，但也需要更完善的监控与控制逻辑。

健康检查至少应区分“进程存活”和“业务可用”。例如，服务端口仍然开放，并不代表数据库、消息队列或文件存储正常。检查接口可以返回依赖状态，但不宜在每次检查中执行过重操作。常见做法是设置较短的探测周期，并配合连续失败次数、恢复确认次数和熔断时间。

在网络质量较稳定的内网环境中，可把几十毫秒级的延迟差异作为参考；跨地域访问时，运营商线路、访问时段和用户位置都会影响结果，不宜使用单一时间点的测量值作为永久规则。

五种方法如何选择

实际部署时，可以先用轮询建立基线，再根据监控结果切换到加权轮询或最少连接；若业务依赖本地缓存或会话，再考虑一致性哈希。无论采用哪种节点负载均衡策略，都应同时设置故障摘除、恢复放量、超时和告警规则。

常见问题

1. 节点性能相同，是否一定使用轮询？

不一定。若请求耗时差异明显，最少连接可能更合适；若存在本地缓存或会话依赖，则应评估一致性哈希。

2. 权重越高是否代表节点越快？

不是。权重只是分配比例，实际效果还会受到请求类型、内存压力、存储速度和网络状况影响。

3. 健康检查频率越高越好吗？

不是。过于频繁会增加探测开销，过低又可能延迟故障发现。应结合节点数量、故障影响和业务容忍时间设置。

4. 如何验证策略是否有效？

在不同时间段观察请求分布、成功率、P95或P99响应时间、连接数和节点资源使用情况，再用可控流量逐步调整。

选择节点负载均衡策略的关键，不是追求最复杂的算法，而是让分配依据与业务负载特征相匹配，并通过持续监控验证结果。