负载均衡倾斜/健康检查误判 LB imbalance, bad health checks

原因 ID dc-lb-imbalance · 主责 运维团队·网络运维 · 配合研发团队·服务器开发

连接全都挤到一台服务器上，或者一直把玩家分配到已经挂掉的服务器。

起因分配规则不合适，或健康检查反映不了实际状态 → 结果只有一台服务器过载，或连接请求被发往挂掉的服务器 → 画面表现 只有部分分线、部分玩家出现慢动作、连不上/无限加载

症状: 慢动作, 连不上/无限加载
因素: 停顿, 丢包
谁会遇到: 特定地点/分线
何时出现: 刚登录/维护结束后, 人多的时候
负责方: 主责 运维团队·网络运维 · 配合研发团队·服务器开发
研发团队要做的事: 实现健康检查：根据实际游戏状态（tick 是否推进、DB 连接）回应负载均衡器的探测请求，并一起上报服务器负载值。
运维团队要做的事: 把健康检查改为确认实际游戏响应的方式；按服务器负载分配；监控各服务器连接数的差异。
监控图上: 仅部分偏高 · 各服务器的连接数、CPU 使用率
查看位置: 把负载均衡器后面每台服务器的连接数（ss -s）和 CPU 使用率叠加在同一张图上看，并把负载均衡器上目标的健康状态（AWS 为 CloudWatch 的 HealthyHostCount、UnHealthyHostCount）与游戏服务器的实际状态对比
确认依据: 只有一两台服务器的连接数、CPU 明显高于其他服务器；或 tick 已停住的服务器健康状态仍为“正常”，继续接收新连接
排除依据: 各服务器连接数均匀，却只有一个分线慢，看该分线内部的负载（“单线程区域过载（热点）”）
确认手段: 运维工具即可确认（无需游戏代码）
真实案例: AWS 2025: AWS us-east-1 DynamoDB DNS 故障与漫长的恢复

出处

Load Balancing in the Datacenter Google
简单轮询会让各任务的 CPU 使用量相差最多 2 倍；后端在响应和健康检查中附带负载信息的加权分配；表示不再接收请求的 lame duck 状态
Health checks for Network Load Balancer target groups AWS
健康检查默认间隔 30 秒，失败 2 次即被移除；UDP 服务要用 TCP、HTTP 健康检查来确认，建议配置成能反映实际服务状态
CloudWatch metrics for your Network Load Balancer AWS
HealthyHostCount、UnHealthyHostCount：被判定为正常、不正常的目标数