新手先读懂节点负载均衡的请求分配逻辑

理解节点负载均衡原理，不能只记住“把请求分给多台服务器”这句话。一次访问通常会经过域名解析、入口监听、节点选择和响应返回四个阶段。真正决定请求去向的，是入口设备掌握的节点列表、调度算法、健康状态以及连接是否需要保持。

一、请求是怎样被分配的

以一个部署在三台应用服务器上的网站为例：用户访问域名后，首先通过DNS获得入口地址；请求到达负载均衡器后，入口读取目标端口、协议、请求头或源地址等信息，再从可用节点中选出一台。节点处理完成后，响应通常沿原连接返回用户。

这里要区分DNS分流和节点负载均衡原理。DNS可以把域名解析到不同入口，但它受缓存影响，切换并不即时；负载均衡器则能在每次新连接或每个请求到达时作出选择，通常更适合需要快速摘除故障节点的场景。

四个关键状态

• 节点池：记录节点地址、端口、权重和启用状态。
• 连接状态：记录当前连接数、空闲连接或请求处理情况。
• 健康状态：由探测结果判断节点是否继续接收流量。
• 会话信息：决定同一用户是否需要持续访问同一节点。

二、常见调度策略有什么差异

轮询最容易理解，但“请求数量相同”不代表“工作量相同”。例如图片缩放、报表生成这类请求耗时较长，最少连接往往比单纯轮询更合理。节点负载均衡原理的核心，就是让选择规则与请求成本相匹配，而不是盲目追求平均数量。

三、健康检查决定谁能接收请求

健康检查不是只看服务器能否响应网络连接。较可靠的检查通常分为三层：先确认目标端口可连接，再访问专用检查接口，最后验证关键依赖是否达到可服务状态。比如Java应用启动完成但仍无法读取配置中心时，进程可能“活着”，却不适合继续接收业务请求。

配置检查周期时，要在发现速度和检查开销之间取平衡。实际环境中，检查间隔可以从数秒到几十秒不等，失败次数通常设置为连续两次或三次后摘除，恢复也可要求连续多次成功。具体数值应结合启动时间、网络抖动和业务容错能力调整，不能套用一组固定参数。

节点被摘除后会发生什么

1. 探测器连续收到失败结果。
2. 入口把节点标记为不可用，不再为新请求选择它。
3. 已经建立的连接按协议和超时设置处理，可能自然结束，也可能被关闭。
4. 节点恢复后，先逐步接收流量，再观察错误率和延迟是否稳定。

四、会话保持与故障切换

如果应用把临时登录状态保存在单台节点的内存中，用户连续访问不同节点时可能被要求重新登录。此时可以使用会话保持，让同一来源在一段时间内优先回到原节点；也可以把会话状态放入所有节点都能访问的共享存储。前者改造较少，但故障节点会影响其关联用户；后者可用性更好，却增加了共享存储的设计和维护成本。

哈希策略也不是绝对的会话保持。它只能根据某个特征计算归属，节点列表变化、客户端网络变化或代理链变化，都可能使同一用户落到不同节点。因此，重要状态不应只依赖入口的分配结果。

五、按步骤验证节点负载均衡原理

1. 列出节点地址、监听端口、规格差异和应用版本，确认入口看到的节点清单正确。
2. 分别从入口和业务网络测试端口连通性，排除防火墙或路由问题。
3. 为应用准备专用健康接口，区分“进程存活”和“可以提供业务”。
4. 用短请求和长请求分别压测，比较轮询、加权和最少连接下的响应时间与错误情况。
5. 临时停止一台节点，观察新请求是否避开它、已有连接如何结束、恢复后是否出现突发流量。
6. 检查各节点的请求数、活跃连接、错误比例和延迟分位数，确认表面平均值没有掩盖单节点异常。

六、常见问题

为什么节点请求数不完全相等？

连接复用、请求耗时、权重、健康状态和会话保持都会影响结果。请求数不等不一定代表分配错误。

最少连接一定优于轮询吗？

不一定。请求长度接近且节点规格一致时，轮询更简单；长连接或耗时差异大时，最少连接更有参考价值。

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

不是。频率过高会增加探测流量，并可能把短暂网络抖动误判为故障，应结合超时和连续失败次数设置。

增加节点后为什么访问归属会变化？

节点池发生变化后，轮询顺序、哈希结果或权重比例都会改变。需要稳定会话时，应采用共享状态或支持节点变化的哈希方案。

归根结底，节点负载均衡原理就是在“可用节点集合”中，根据明确规则选择承载者，并用健康检查持续修正这个集合。掌握请求路径、调度策略、会话状态和故障切换四部分，新手就能从现象追溯到分配逻辑。