采用源IP哈希策略的负载均衡可用性相关技术咨询

核心结论 #

裸的、无额外兜底逻辑的源IP哈希/会话ID哈希策略，在后端节点故障切换时，原本映射到故障节点的用户不会彻底无法访问服务，但会丢失存储在该故障节点本地的所有会话状态，请求会被重新调度到其他健康节点，表现为用户需要重新登录、未同步的临时操作（比如没存上的购物车条目、游戏断线前的临时状态）丢失，不会出现全服务不可用的情况。

常见的容灾兜底实现 #

生产环境不会直接用最原始的哈希取模转发，一般会配合几层机制降低故障影响：

• 用一致性哈希替代普通取模哈希：将后端节点和客户端标识都映射到首尾相接的哈希环上，客户端请求顺时针找到环上最近的健康节点作为转发目标。单个节点故障时，只会影响该节点与环上前一个健康节点之间的一小部分流量，不会导致全量用户的映射关系全部重算，故障影响面可以从1/N（N为后端节点数）降到5%以内，配合虚拟节点配置还能避免节点数量变化带来的负载倾斜。
• 内置故障二次转发逻辑：负载均衡侧会实时做节点健康检查，第一次哈希命中故障节点时，不会直接返回错误，而是按预设规则（比如取哈希环上的下一个健康节点、走兜底轮询池）将请求转发至正常节点，保证请求能正常处理。
• 状态外置或多副本同步：要彻底消除状态丢失的影响，最直接的做法是不把用户会话存在单台服务器本地：要么将会话、购物车、游戏临时状态这类数据存在共享缓存集群，请求转发到任意节点都能读取到对应的用户状态；要么做节点间的会话异步多副本复制，节点故障时，接管的节点可以直接从副本拉取对应用户的状态，用户无感知。

无复杂兜底的源IP哈希适用场景 #

如果不做上述复杂的状态同步、一致性哈希配置，裸用源IP哈希只适合这几类场景：

• 无状态长连接/四层网关场景：同IP的请求固定转发到同一节点，可以最大化TCP连接复用率，降低连接建立开销。节点故障时客户端自动重连，重新哈希到新节点即可，没有状态丢失的额外成本。
• 缓存类节点场景：比如静态资源缓存节点、服务本地热点缓存节点，用源IP哈希可以大幅提升单节点的本地缓存命中率，降低回源率。节点故障时，请求落到其他节点顶多触发一次回源拉取，不会产生业务故障，用户侧感知顶多是单次请求延迟略高。
• 内部微服务调用场景：内部服务间调用使用源IP哈希，可以让同个上游服务的请求固定打到固定下游实例，提升下游实例本地配置、权限等热点数据的缓存命中率。节点故障时，上游框架自动重试其他节点即可，重试成本极低，不会影响外部用户体验。

对常见落地案例的补充说明 #

你觉得游戏、电商场景裸用源IP哈希不合理，这个判断是完全正确的：

• 游戏场景的“断线重连回同一服务器”是业务层的分服逻辑，用户注册/选服时就已经绑定了固定的逻辑服入口，不是负载均衡靠源IP哈希动态计算出来的，且游戏的用户状态一般会做持久化或多副本存储，不会只存在单台服务器内存里。
• 电商场景的未登录购物车，现在基本都存在客户端Cookie或者共享缓存集群中，不会存储在应用服务器本地，用源IP哈希顶多是为了提升连接复用率，根本不依赖单节点的本地存储。

内容的提问来源于stack exchange，提问作者AM14a