网络游戏中的worker多进程模型通过分离状态与计算、统一redis存储、connection_id会话绑定及coordinator动态负载调度，实现高并发下上下文一致性与弹性伸缩。

在网络游戏场景中，Worker 多进程代理模型本身不直接“保持会话上下文”，而是通过架构协同与外部机制共同实现动态负载均衡下的上下文一致性。关键在于：**分离状态与计算、统一状态存储、配合会话路由策略**。单纯靠 Worker 进程数量或轮询调度无法解决玩家会话连续性问题——这恰恰是高并发游戏服务最容易出错的环节。

会话上下文必须外置，不能依赖 Worker 进程内存

每个 Worker 是独立进程，重启、扩容、故障时内存状态必然丢失。若把玩家登录态、房间数据、操作序列缓存在某个 Worker 内存里，一次进程崩溃或请求被调度到其他 Worker，就会导致“掉线”“状态错乱”“重复进房”等问题。

• 所有会话级数据（如玩家 token、房间 ID、操作时间戳、技能冷却状态）必须存入共享存储：Redis 是最常用选择，支持原子操作、过期 TTL、Pub/Sub 通知
• 避免使用本地文件或进程内变量保存玩家状态；即使使用内存数据库（如 Redis），也要确保其高可用（主从+哨兵/Cluster 模式）
• Worker 启动时不做“加载用户数据”动作，而是在每次请求到来时按 session_id 或 user_id 实时查 Redis —— 这带来微小延迟，但换来强一致性与弹性伸缩能力

用连接标识绑定会话，而非依赖进程生命周期

玩家 TCP/WS 连接建立后，应立即生成唯一 connection_id，并与 user_id/session_id 建立映射，写入 Redis（带 5–10 分钟过期）。后续所有该连接的帧数据、心跳、指令都携带此标识。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 代理层（如 Nginx、Swoole Proxy、CloudRetro Coordinator）收到新连接时，解析鉴权信息，分配 connection_id，写入 Redis，再转发给某个 Worker
• Worker 处理消息前先校验 connection_id 是否有效、是否归属当前玩家；无效则拒绝并触发重连流程
• 当玩家断线重连，新连接仍携带原 token → 代理层查 Redis 找到旧 connection_id → 强制踢掉旧连接、复用会话上下文 → 玩家无感续接

Coordinator 主动协调 Worker 负载，而非被动轮询

纯轮询（如 Nginx 的 round-robin）或操作系统调度（如 Node.js cluster）在游戏场景下容易造成热点：某个 Worker 突然承载了 3 个满员副本，而其他 Worker 空闲。真正有效的动态均衡需要 Coordinator 层感知实时负载。

• 每个 Worker 定期上报指标：当前活跃连接数、平均响应延迟、CPU 使用率、内存占用 → 上报至 Coordinator 或 Redis Hash
• Coordinator 根据权重公式（例如：score = active_conn × 0.6 + latency_ms × 0.3 + cpu_pct × 0.1）计算各 Worker 综合负载分，分数越低越健康
• 新连接接入时，Coordinator 选择 score 最低的 Worker 建立后端通道；支持阈值熔断（如 score > 80 则暂不分配）
• CloudRetro 的 Coordinator 就采用此类策略，配合 Worker 心跳注册与主动驱逐机制，实现毫秒级负载再平衡

房间/战斗等强状态业务，需额外做状态分区与亲和调度

不是所有请求都适合随机分发。比如同一副本内的 4 名玩家，其操作必须由同一个 Worker 处理，否则会出现状态分裂（A 玩家血量减半写入 Worker1，B 玩家攻击逻辑在 Worker2 执行，结果不一致）。

• 房间 ID 或战场 ID 做一致性哈希（如 MurmurHash3），映射到固定 Worker 编号（例：worker_id = hash(room_id) % worker_count）
• 该映射关系也写入 Redis，供所有 Worker 和 Coordinator 查询；扩容时通过虚拟节点平滑迁移，避免全量重分
• 玩家加入房间请求，先查 Redis 获取目标 Worker 地址，再由 Coordinator 直接路由，绕过负载评分——这是“有状态路由”，优先于“无状态负载”
• Worker 内部可启动子协程/线程专责某房间，但整个房间生命周期绑定单个 Worker 进程，确保内存状态封闭且高效