游戏卡顿白皮书 › L13 服务器架构与运维
发布/重启 Deploy / rolling restart
原因 ID in-deploy · 主责 研发团队·服务器开发 · 配合 运维团队·系统运维
在含图示和实验的完整版中打开此卡片 →
为更新而重启服务器时，如果不迁移连接，这台服务器上的玩家都会掉线，关机前的存盘和随后的重连也会一下子挤在一起。
起因 发布热修复，按顺序重启服务器 → 结果 不把连接迁到其他服务器就直接关闭，这台服务器上所有玩家的存盘请求同时涌向 DB → 画面表现 没有预告的掉线，大量重连
- 症状
- 掉线, 连不上/无限加载, 操作延迟
- 因素
- 停顿
- 谁会遇到
- 全服, 特定地点/分线
- 何时出现
- 偶尔随机, 刚登录/维护结束后
- 负责方
- 主责 研发团队·服务器开发 · 配合 运维团队·系统运维
- 研发团队要做的事
- 排空功能（drain，只拦新连接，等现有玩家自行离开），把角色迁到其他服务器，关闭前分批存盘，重启后完成缓存加载和 JIT 预热再通知就绪，热重载在单独线程中提前读好数据，在两个 tick 之间一次性替换。
- 运维团队要做的事
- 发布工具逐台等排空完成后再重启，重启的服务器确认就绪（预热完成）后再接流量，提前公告发布时间。
- 数值参考
- 一台服务器上有 5,000 人时，关闭前几秒内会有 5,000 条存盘请求涌向 DB。
- 监控图上
- 连接成批断开 · 各服务器的连接数，DB 写入次数
- 查看位置
- 把发布工具的操作记录（各服务器的重启时刻）以竖线（标注）的形式叠加到连接数、断线数、DB 写入、登录请求的监控图上
- 确认依据
- 各服务器连接数在重启时刻逐台依次骤降，骤降前 DB 写入冲高，骤降后登录请求冲高
- 排除依据
- 断开时刻与发布、重启记录不重合，则是服务器崩溃或网络设备方面的问题
- 确认手段
- 运维工具即可确认（无需游戏代码）
- 深入了解
- 刚重新启动后的几分钟也会慢。缓存是空的，DB 查询集中涌来；Java、C# 服务器还没完成边运行边优化代码的过程（JIT 预热），同样的工作要花更多时间。不关服务器、重新读取脚本和数据表的方式（热重载）在读取期间 tick 也会停住，造成短暂停顿。
出处
- Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter Google
收到 SIGTERM 的服务器进入 lame duck 状态，把新请求转给其他服务器，只把进行中的请求处理完；重启后的几分钟还没有经过 JIT 优化，资源消耗更大，所以预热后再接流量 - Liveness, Readiness, and Startup Probes Kubernetes
用就绪检查（readiness）保证在连接建立、文件加载、缓存预热完成之前不发流量 - Edit target group attributes for your Network Load Balancer AWS
注销目标后不再向它发送新连接，现有连接则排空（drain，默认 300 秒）
相关原因
同一层：L13 服务器架构与运维
其他层中同样导致“掉线”的原因
查看含图示和实验的原卡片