游戏服务器热更

在线游戏停服维护一次，玩家的耐心和口碑就消耗一分。热更新（不中断服务完成更新）是游戏服务端架构的核心能力，分两个层次：

• 配置热更新：改数值表、活动配置、掉落率。配置或数据库实时加载，服务端监听变更即可；
• 逻辑热更新：改业务代码、修 Bug、加功能。这才是真正的难题。

无状态服务：滚动更新

无状态服务的热更新简单，标准流程：

1. 编译新版本可执行文件；
2. 启动新进程，负载均衡器把流量逐批切过去；
3. 旧进程流量归零后关闭。

整个过程对客户端透明，服务持续可用。这是 Go 服务最常见的部署方式。

有状态服务：状态迁移的难题

游戏进程里缓存着大量玩家状态，整批迁移代价惊人：

网络类型	带宽	1GB 状态迁移耗时
万兆网络	10Gbps	0.8–1.2 秒
千兆局域网	1Gbps	8–10 秒
典型云服务	500Mbps	16–20 秒
普通互联网	100Mbps	80–100 秒

典型规模：1000–10000 个玩家 × 每玩家约 1MB = 1GB–10GB 缓存。就算万兆网也要 1 秒，玩家明显感知卡顿。结论：整批迁移不可行，必须细化迁移粒度。

方案：Router + 玩家级精细化迁移

以单个玩家（约 1MB）为迁移单元，普通网络下只需几毫秒到几十毫秒，单个玩家几乎无感知。引入 Router 服务作核心协调组件，维护 userId → serverId 映射。迁移流程：

1. 把该 userId 标记为”迁移中”，暂停处理其请求；
2. 请求暂存到消息队列，不丢失；
3. 把该玩家状态迁移到新进程；
4. 更新路由映射指向新进程；
5. 恢复处理该玩家请求。

每个玩家只经历几十毫秒中断；不同玩家可并行迁移，整体更新窗口大幅缩短。

技术实现要点

• 状态序列化：用高效序列化（如 Protobuf）减小迁移数据量；
• 消息队列：迁移期间请求可靠暂存，保证不丢消息；
• 一致性：迁移前后状态校验，防止”旧进程还在改、新进程已接管”造成的状态分叉；
• 回滚：迁移失败自动回滚到旧进程，请求继续由旧进程处理；
• 监控：实时观测迁移进度、成功率、单玩家中断时长。

总结

游戏服务端热更新的本质：无状态靠滚动，有状态靠细粒度迁移。基于 Router 的玩家级迁移，用”单玩家几十毫秒中断”换整个服务不停机，是大规模在线游戏的主流选择。