概念所谓状态就是业务数据——玩家的会话、血量、位置、购物车内容都是状态。MMO游戏中边界划分经典 MMO如《魔兽世界》《梦幻西游》是典型的有状态巨兽一个 100 人房间的状态包括 100 个玩家的位置/血量/技能 CD、场景中的 NPC/物体、物理引擎状态全部驻留内存每帧刷新延迟要求 1ms。如果照搬微服务无状态外部存储的模式每次游戏逻辑都去 Redis/DB 拉状态——内存内函数调用是纳秒级跨网络 RPC 是毫秒级差了 4~5 个数量级。所以游戏服务器不能全面无状态化。业界的做法是混合架构——把无状态和有状态的边界按服务类型重划┌─────────────────────────────────────────────┐ │ 接入层 (Gateway) │ │ ✅ 无状态 │ │ 职责TCP/UDP 连接管理、协议编解码、路由 │ │ 扩容随意水平扩容K8s HPA 友好 │ ├─────────────────────────────────────────────┤ │ 逻辑层 (GameServer / SceneServer) │ │ ⚠️ 有状态内存态 │ │ 职责玩家状态、移动同步、技能、AI、副本 │ │ 扩容按世界分区分片一致性哈希路由 │ ├─────────────────────────────────────────────┤ │ 公共层 (CommonService) │ │ ✅ 完全无状态 │ │ 职责匹配、跨服邮件、排行榜、全局事件总线 │ │ 扩容K8s 随意扩缩 │ ├─────────────────────────────────────────────┤ │ 数据层 (DBProxy) │ │ ⚠️ 有状态但职责单一 │ │ 职责DB 读写代理、缓存、事务协调 │ │ 扩容分库分表 Redis Cluster │ └─────────────────────────────────────────────┘常见问题与解决方案问题 1粘性会话导致的扩容困境现象玩家 A 登录到场景服 Node1所有请求必须路由到 Node1因为 Node1 内存里有玩家 A 的对象。Node1 挂了或过载玩家 A 就得掉线或卡死。解决方案一致性哈希路由defget_target_node(player_id,node_list):一致性哈希玩家 ID - 固定节点hash_valhashlib.md5(str(player_id).encode()).hexdigest()# 将 hash 环映射到 node_listring_posint(hash_val[:8],16)%len(node_list)returnnode_list[ring_pos]# 扩容时只迁移少量玩家一致性哈希 vs 取模的优势# 取模N-N1几乎所有玩家都要迁移# 一致性哈希只迁移 1/N 的玩家问题 2节点宕机导致内存态丢失现象场景服 Node3 崩溃上面 2000 个玩家的内存对象全部丢失——等级、背包、未存盘的经验全部回档到上次存盘点。解决方案状态外置 快照 热备--Skynet 场景服中的状态外置设计--热数据内存 Player Object纳秒级访问--温数据Redis秒级跨节点共享--冷数据MySQL分钟级持久化--定时快照每30秒 function periodic_snapshot()forplayer_id,playerinpairs(active_players)doifplayer.dirty then--1.写 Redis快速恢复用 redis.setex(player:..player_id,3600,cjson.encode(player))--2.标记待刷 MySQL mark_dirty_for_mysql(player_id)player.dirtyfalse end end end--节点崩溃后恢复 function recover_from_redis(player_id)local cachedredis.get(player:..player_id)ifcached thenreturncjson.decode(cached)--最多丢失30秒数据elsereturnload_from_mysql(player_id)--最坏情况从 DB 加载 end end问题 3扩容时的状态迁移成本现象Node1 承载 5000 玩家CPU 90%需要把其中 2000 玩家迁移到新节点 Node5。但玩家对象在 Node1 内存里迁移意味着序列化 → 网络传输 → 反序列化 → 重定向连接。无状态网关 有状态逻辑服的协作现象网关是无状态的任意实例可处理任意连接但玩家数据在有状态的场景服里。网关收到消息后怎么知道转发给哪个场景服解决方案两级路由classGateway:def__init__(self):self.routing_table{}# player_id - scene_node_addrdefon_message(self,player_id,msg):# 1. 查路由表本地缓存或 Redistargetself.routing_table.get(player_id)ifnottarget:# 2. 一致性哈希计算目标场景服targetconsistent_hash(player_id,scene_nodes)self.routing_table[player_id]target# 3. 转发到有状态场景服forward_to_scene(target,player_id,msg)问题 5跨服交互的状态一致性现象玩家 A 在场景服 S1玩家 B 在场景服 S2A 要给 B 送礼物。礼物数据是有状态的且分布在两个节点。解决方案无状态公共层 MQ 解耦这种模式下场景服 S1/S2 保持有状态内存操作跨服通信走无状态的 MQ 公共层既保证了场景内性能又实现了跨服解耦边界重划的核心原则有状态逻辑收敛到少数核心进程场景服、战斗服、玩家逻辑服——这些必须内存态的服务尽量减少数量、明确边界无状态能力推到周边/接入层网关、匹配、排行榜、支付、邮件——这些可以无状态化的服务大胆用微服务/K8s状态外置作为兜底内存态是性能需要但 Redis/DB 必须作为备份保证故障可恢复路由策略因服务而异无状态服务 → 随机/轮询路由有状态服务 → 一致性哈希按 player_id / room_id 分片混合架构优于纯无状态游戏公司的不愿微服务化不是技术落后而是游戏的状态模型决定了必须混合