游戏卡顿白皮书 › L13 服务器架构与运维
级联故障 Cascading failure
原因 ID in-cascade · 主责 研发团队·服务器开发 · 配合 运维团队·网络运维
在含图示和实验的完整版中打开此卡片 →
一个服务变慢，调用它的服务器都会因等待响应而被占住，连不相关的功能也会停摆。
起因 DB、认证等某一个服务变慢 → 结果 调用方服务器的线程和连接都在等待响应而被占住，失败请求的重试又增加负载 → 画面表现 看起来无关的功能也全部变慢或停摆
- 症状
- 卡住, 操作延迟, 连不上/无限加载
- 因素
- 停顿
- 谁会遇到
- 全服
- 何时出现
- 人多的时候, 偶尔随机
- 负责方
- 主责 研发团队·服务器开发 · 配合 运维团队·网络运维
- 研发团队要做的事
- 所有调用设超时，使用熔断器，按功能隔离（舱壁隔离，bulkhead），重试逐步拉长间隔并限制次数，健康检查的响应与繁重任务分开。
- 运维团队要做的事
- 负载均衡器的健康检查对失败次数和间隔留出余量，避免把只是暂时变慢的服务器立刻摘掉；限制同时被摘除的服务器数量。
- 监控图上
- 触顶后走平 · 各服务的响应时间、错误率，线程、连接的使用数
- 查看位置
- 把各服务的响应时间、错误率、重试次数按同一时间轴放在一个界面上，找出最先变慢的地方。在负载均衡器后面时，看目标响应时间（AWS ALB 为 TargetResponseTime）、目标返回的 5xx 数量（HTTPCode_Target_5XX_Count）、因异常被摘除的目标数（UnHealthyHostCount）
- 确认依据
- 某个服务的延迟先上升，随后调用它的一方线程、连接使用数顶到上限，错误扩散到其他服务，重试次数和被摘除的目标数同时增加
- 排除依据
- 多个服务在同一时刻一起变慢，先查公共资源（DB、网络、宿主机）故障
- 确认手段
- 运维工具即可确认（无需游戏代码）
- 深入了解
- 健康检查（确认服务是否存活的检查）也会放大级联。繁忙的服务器回应检查慢了，负载均衡器就会把本来正常的服务器摘掉，流量集中到剩下的服务器，下一台服务器也跟着变慢。
- 真实案例
- Riot Games 2020: League of Legends 欧洲、巴西服务器的边缘主机过载
Riot Games 2021: League of Legends EUW 5 小时故障：一个辅助 DB 导致全服停摆
Roblox 2021: Roblox 73 小时故障：服务发现（Consul）集群的争用问题
AWS 2021: AWS us-east-1 内部网络拥塞
AWS 2025: AWS us-east-1 DynamoDB DNS 故障与漫长的恢复
出处
- Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
过载服务器健康检查失败被摘除后，负载集中到剩下的服务器，重试又放大负载；建议限制重试次数、使用随机化指数退避、设置截止时间（deadline） - Circuit Breaker Pattern Microsoft Azure
一直阻塞到超时的请求占用线程和 DB 连接，导致不相关的功能也失败；在规定时间内失败累积到一定程度，就直接拒绝调用 - Timeouts, retries, and backoff with jitter AWS
Amazon Builders' Library。5 层调用中每层重试 3 次，DB 负载会变成 243 倍；只在一处重试，并用令牌桶限制 - CloudWatch metrics for your Application Load Balancer AWS
TargetResponseTime（请求离开负载均衡器到目标开始响应所花的时间）、HTTPCode_Target_5XX_Count（目标返回的 5xx 数）、UnHealthyHostCount（异常目标数）
相关原因
同一层：L13 服务器架构与运维
其他层中同样导致“卡住”的原因
查看含图示和实验的原卡片