节点负载均衡策略的目标，不只是把请求平均分到多台机器，还要在节点性能不同、连接状态复杂或部分实例故障时，保持服务可用和响应稳定。下面按实际运维中最容易出现的六个问题展开，并比较不同方案的适用条件。

一、轮询看似公平，实际流量仍可能失衡

最基础的轮询会依次把请求发送到不同节点。它适合请求耗时接近、节点规格一致的无状态接口，但如果一个请求只需几十毫秒，另一个请求要执行文件转换或复杂查询，单纯按次数分配就会造成等待时间差异。

方案对比

• 轮询：配置简单，适合同规格、短请求服务；缺点是不了解节点当前负载。
• 加权轮询：为计算能力更强的节点设置更高权重，适合硬件规格不同的集群；权重需要根据长期监控结果调整。
• 最少连接：优先选择当前连接较少的节点，适合长连接或请求耗时差异较大的服务，但连接数不一定等于真实负载。

实施时可先按节点的并发处理能力设置初始权重，再观察请求完成时间、队列长度和错误比例，避免仅凭CPU占用率修改参数。

二、节点故障后，流量仍被继续转发

进程存活不代表服务可用。例如 Java 应用进程仍在运行，但连接池已耗尽，或者应用无法访问 Redis、PostgreSQL 等依赖服务，此时继续接收请求会产生大量超时。

可靠的节点负载均衡策略应包含健康检查。检查接口应验证真正的服务能力，例如返回明确的成功状态，并在必要时确认关键依赖可连接。

1. 为每个节点提供独立的健康检查路径，避免直接使用首页。
2. 设置检查间隔、超时和连续失败次数，短暂网络抖动时不要立即摘除节点。
3. 节点恢复后先逐步放量，确认错误率正常后再恢复完整流量。

健康检查越频繁，故障发现通常越快，但检查请求也会增加。生产环境应根据故障影响和节点规模选择间隔，常见做法是数秒到几十秒一个检查周期。

三、会话状态导致用户被迫重复登录

如果登录状态保存在单机内存中，请求从节点甲切换到节点乙后，乙可能无法识别会话。购物车、上传任务和部分后台操作也可能遇到类似问题。

三种处理方式

• 共享会话存储：把会话放入 Redis 或数据库，节点之间读取同一份状态，扩展性较好，但需要额外维护存储服务。
• 会话保持：根据Cookie或其他标识尽量把用户固定到同一节点，改造成本较低；节点故障时仍可能丢失状态。
• 无状态设计：使用可验证的令牌保存必要身份信息，节点无需保存用户会话，适合横向扩展；令牌撤销和敏感信息保护需要另行设计。

优先选择共享状态或无状态架构，再把会话保持作为过渡方案。不要把会话保持当成节点故障恢复机制。

四、节点规格不同，却使用同一套分配比例

两台机器即使数量相同，处理能力也可能不同。新节点拥有更多内存，旧节点却承担定时任务时，平均分配会让弱节点先出现排队和超时。

可采用加权轮询或基于资源的动态策略。初始权重可以参考CPU核心数、可用内存、连接上限和业务压测结果，但这些指标只能作为起点。对于数据库代理、消息消费或图片处理等任务，还应关注并发限制、磁盘IO和队列积压。

调整权重时建议一次只改变一个因素，并至少观察一个完整业务高峰周期。若某节点错误率明显升高，应先确认应用、网络和依赖服务问题，再判断是否需要降低权重。

五、热点对象让某个节点被集中打满

即使整体请求分配均匀，某些热点也可能集中到少数节点。例如一致性哈希常用于缓存或需要固定路由的对象，但热点键、热门文件或单个大客户会形成局部压力。

一致性哈希的优点是节点增减时迁移范围相对可控，适合缓存、分片和部分长连接场景；缺点是热点不会自动消失。普通轮询更容易摊平请求，却不适合必须访问固定状态的业务。

1. 先识别热点来源，区分热点用户、热点键和热点接口。
2. 为高频对象增加副本、分片或短期缓存，避免所有请求落到一个节点。
3. 对单用户或单对象设置并发限制，防止异常流量拖垮共享节点。
4. 将节点级指标与业务对象维度结合分析，不要只看集群平均值。

六、扩容或缩容时出现连接抖动

节点上下线会影响长连接、缓存命中和正在处理的请求。若新节点刚启动就接收全部流量，可能因缓存为空、连接池未预热或依赖服务尚未就绪而产生错误。

更稳妥的节点负载均衡策略是执行优雅上下线：先停止接收新连接，等待存量请求完成，再关闭实例；新节点则先通过健康检查，再逐步提高权重。对于容器集群，还要确认就绪状态与进程存活状态分开配置。

方案选择速查

常见问题

1. 节点数量少时要不要使用复杂算法？

如果节点规格一致、请求无状态且耗时接近，轮询通常足够。复杂算法应建立在明确问题之上，而不是为了增加配置项。

2. 最少连接能替代健康检查吗？

不能。故障节点可能连接数很少，仍会被选中。最少连接负责分配，健康检查负责判断节点是否可用。

3. 权重多久调整一次？

没有统一周期。可在版本变更、扩容或业务峰值后复核，通常先观察多个高峰周期，再进行小幅调整。

4. 如何判断节点负载均衡策略是否有效？

同时观察成功率、响应时间、超时比例、连接数、队列长度和节点资源，而不是只看请求数量。能够减少异常节点影响并保持容量余量，才算真正有效。

总的来说，节点负载均衡策略应从业务状态、节点能力和故障处理三方面设计：无状态服务可优先采用轮询或加权轮询，长连接关注最少连接，固定数据访问考虑一致性哈希，而所有生产节点都应配合准确的健康检查与优雅上下线。