如何在不同服务器之间维护用户和游戏状态？

针对你的多人问答游戏扩容场景，核心思路是状态与应用服务器完全解耦，禁止将任何需要跨节点共享的状态存储在单台应用服务器的本地内存或磁盘中，具体实现分层如下：

1. 持久化玩家数据层 #

• 玩家账号信息、历史战绩、总积分、资产等永久存储的核心数据，统一存入共享的MySQL集群即可，所有应用服务器共用同一套MySQL访问入口，可搭配主从读写分离架构分摊查询压力，无论用户请求落到哪台应用服务器，都能直接拉取到完整的永久数据。
• 禁止在单台应用服务器本地存储任何持久化用户数据。

2. 实时会话与游戏状态层 #

这是解决你提到的掉线重连场景的核心部分：

• 用Redis集群做统一的实时状态共享存储，替换PHP默认的本地文件Session存储，将用户登录态、对局临时进度、当前局积分、匹配队列状态等实时性要求高的临时数据全部存在Redis中，以玩家ID/对局ID作为键名，设置与业务匹配的过期时间（比如单局最大时长+10分钟）。
• 无需在负载均衡层配置会话粘滞（Session Sticky），玩家掉线重连后无论被分发到哪台应用服务器，都可以直接通过玩家ID到Redis中拉取到之前的实时状态，直接恢复游戏进度。
• Redis本身支持集群水平扩容，完全可以匹配你的autoscaler扩缩容节奏，不会成为性能瓶颈。

3. 状态一致性保障 #

• 关键业务状态变更（比如答题得分、道具消耗、对局结束结算），采用「同步写Redis + 异步回写MySQL」的策略：同步写Redis保证实时性，异步队列（直接用Redis的list结构即可实现轻量队列）回写MySQL保证数据持久化，避免Redis故障丢失核心数据。
• 可开启Redis的RDB+AOF混合持久化，做额外的数据兜底。

可选优化项 #

如果你的游戏采用房间制对局，可在负载均衡层增加基于房间ID的一致性哈希路由规则，将同一个房间的所有玩家请求分发到同一台应用服务器，减少跨节点拉取状态的开销，但该方案仅为性能优化，不能替代统一的状态存储层，否则应用节点宕机或autoscaler缩容时依然会丢失房间数据。

内容的提问来源于stack exchange，提问作者ankit_vd