游戏卡顿白皮书 › L13 服务器架构与运维
登录排队上限/重连保留不足 Login queue cap / no reconnect grace
原因 ID in-login-queue · 主责 研发团队·服务器开发 · 配合 研发团队·客户端开发, 运维团队·系统运维
在含图示和实验的完整版中打开此卡片 →
上线、维护结束后连接集中涌入时，登录排队达到上限，开始拒绝新的排队；正在排队的玩家只要短暂断开一下就会丢掉位置，回到队尾。
起因 想登录的人多于登录服务器一次能接纳的人数，于是设置排队；队伍太长时，为了保护服务器而拒绝新的排队 → 结果 队伍越长，等待时间越久，这期间 Wi-Fi、移动网络只要短暂断一下，就会丢掉排队位置 → 画面表现 连不上/无限加载，排队中报错并退出游戏，又要从队尾重新排
- 症状
- 连不上/无限加载, 掉线
- 因素
- 停顿
- 谁会遇到
- 全服, 只有我
- 何时出现
- 刚登录/维护结束后, 晚高峰
- 负责方
- 主责 研发团队·服务器开发 · 配合 研发团队·客户端开发, 运维团队·系统运维
- 研发团队要做的事
- 服务器：把排队上限设在登录服务器实际能处理的量上；为排队中断开的玩家保留位置一段时间（重连保留）；显示排队序号和预计等待时间；把队列长度、拒绝次数、排队中断开次数记为指标。客户端：排队中断开时不退出游戏，自动重连回原来的位置；重试间隔用指数退避加抖动打散。
- 运维团队要做的事
- 服务器/OS：上线前做压测，测出登录、大厅服务器的处理上限；上线时准备好能随时加上的备用机器；把排队指标与连接尝试次数放在同一张监控图上看。
- 数值参考
- 2021 年 FINAL FANTASY XIV 资料片上线时，每个逻辑数据中心的排队人数超过 17,000 人就拒绝新的排队（Error 2002）。排队中断开时，大厅服务器会等待几十秒到 1 分钟，在此期间重新连上就从队列中原来的位置继续排。
- 监控图上
- 触顶后走平 · 登录排队长度，因达到上限而拒绝的次数，排队中断开次数
- 查看位置
- 把登录、大厅服务器记录的队列长度、平均等待时间、因达到上限而拒绝的次数、排队中断开次数，与连接尝试次数放在同一张监控图上看
- 确认依据
- 上线、维护结束后队列长度触顶走平期间拒绝次数增加，排队中断开集中在 Wi-Fi、移动网络玩家身上
- 排除依据
- 队列很短但登录慢，看 DB（db-login-storm）或操作系统的连接队列（so-backlog）
- 确认手段
- 需要游戏服务器/客户端的日志和指标
- 深入了解
- 登录集中导致 DB 变慢的情况，看“登录激增与 N+1 查询”；操作系统的连接队列溢出，看“连接队列（backlog）溢出”。这里讲的是游戏有意设置的登录排队在设计上的问题。排队上限是保护登录服务器的安全机制，不能去掉。尽早拒绝超出的请求，才能持续处理能处理的请求。关键在于减少拒绝和断开给玩家带来的损失；队伍越长，错误越集中到 Wi-Fi、移动网络这类线路不稳定的玩家身上。
- 真实案例
- Square Enix 2021: FINAL FANTASY XIV 资料片上线时的拥挤与登录排队错误
出处
- Response to Congestion (as of Dec. 11) Square Enix
每个逻辑数据中心排队人数超过 17,000 人时，为防止登录服务器宕机而拒绝新的排队（Error 2002）；排队中断开时，大厅服务器等待几十秒到 1 分钟，在此期间重连就从队列中原位置继续，超时则回到队尾 - Using load shedding to avoid overload Amazon Builders' Library
尽早拒绝超出的请求，以持续处理能处理的请求（减载，load shedding）
相关原因
同一层：L13 服务器架构与运维
其他层中同样导致“连不上/无限加载”的原因
查看含图示和实验的原卡片