《游戏服务端编程实践》思考01：为什么游戏服务器必须是有状态的？能否设计成无状态架构？

By Leeting Yan

October 30, 2025

引言：从“Hello World”到百万并发的演进
第一章：什么是状态（State）？从哲学到计算机的定义
第二章：状态与游戏世界的本质联系
第三章：有状态架构的必然性与代价
第四章：无状态架构的理想与局限
第五章：游戏服务器中的状态类型与生命周期
第六章：分布式状态管理的演进与实践
第七章：无状态化的尝试与折中策略
第八章：未来趋势——Serverless、边缘计算与游戏状态的解耦
结语：在“状态”与“无状态”之间寻找平衡

引言：从“Hello World”到百万并发的演进

当我们谈论游戏服务器时，我们实际上在谈论对世界的模拟。

一个 Web 服务的请求生命周期通常是这样的：

HTTP Request → 解析参数 → 查询数据库 → 返回 JSON → 结束

而一个游戏服务器的生命周期可能是：

玩家登录 → 创建房间 → 战斗同步 → 状态广播 → 结算奖励 → 存档 → 下线

这两者最大的差异是：

Web 服务处理的是“事件”——一次请求对应一次响应；

游戏服务器处理的是“过程”——一个持续存在的世界。

这就引出了我们今天的核心主题：

为什么游戏服务器几乎都必须是“有状态”的？
是否有可能，像 HTTP 服务那样，设计成完全无状态的分布式系统？

第一章：什么是“状态”（State）？

1.1 状态的哲学定义

“状态”是存在的瞬时特征，是一个系统在特定时间点上的全部信息集合。

在物理世界中，状态是粒子的位置、速度、能量；
在生物世界中，状态是生命体的代谢水平、神经信号；
在计算机系统中，状态是内存、缓存、磁盘中存储的全部变量与数据。

1.2 在软件系统中的定义

在计算机领域，状态（State）指：

程序执行过程中的数据上下文集合，它决定了程序在接下来如何响应外部输入。

例如：

Web 登录系统中，Session 是状态；
Redis 缓存中存储的用户金币数，是状态；
游戏房间中每个玩家的位置、血量、技能冷却时间，都是状态。

1.3 状态与“纯函数”的对立

无状态（Stateless）的系统通常等价于纯函数式系统：

Output = f(Input)

如果输出仅由输入决定，不依赖历史上下文——系统即为无状态。

然而，游戏逻辑往往是：

NewState = f(CurrentState, Input)

也就是说，输入相同，状态不同，结果可能完全不同。

举个例子：

玩家A攻击B → 如果B当前血量是100，会剩50；
如果B当前血量是60，则直接死亡。

因此，状态是游戏逻辑的核心存在。

第二章：状态与游戏世界的本质联系

2.1 游戏服务器的“权威性世界观”

在大多数在线游戏中，服务器拥有逻辑权威（Authoritative Server）：

客户端只是输入与显示终端，游戏的“真实状态”由服务器维护。

这是为了防止：

客户端作弊；
状态不同步；
多人交互不一致。

2.2 状态的三层含义

层次	含义	示例
世界状态	世界整体数据（地图、NPC、天气）	SLG 地图格局、经济系统
玩家状态	个人数据（背包、任务、血量）	RPG 玩家角色属性
临时状态	短期上下文（战斗、技能冷却）	MOBA 房间临时变量

在任何一种多人互动游戏中，这三类状态都必须被维护、更新与广播。

2.3 为什么状态无法丢弃

如果服务器不保存这些状态，将导致：

玩家每次操作都需全量读取；
无法判断因果关系；
无法实现逻辑验证（防作弊）；
无法在断线重连时恢复现场。

这就像一个世界失去了记忆——时间仍在前进，但一切都变得无意义。

第三章：有状态架构的必然性与代价

3.1 有状态带来的必要性

状态是“连续性”的载体。
游戏是一个“连续的故事”，不是独立的请求。

如果服务器是无状态的，那么：

每个请求都必须包含完整上下文；
状态无法共享，交互就会失效。

例如，一个 FPS 对战：

服务器每 50ms 广播所有玩家坐标；
玩家移动、攻击、死亡都依赖上一次帧的状态；
若无状态，服务器必须在每次请求中重建整个场景——计算量无法承受。

3.2 有状态架构的典型形态

典型的有状态游戏服务器结构：

玩家请求
   ↓
逻辑服（Stateful）
   ↓
内存状态表（玩家、房间、战斗）
   ↓
定时持久化（数据库 / Redis）

3.3 有状态的代价：扩展与容灾困难

问题	说明
扩展困难	状态无法轻易在节点间转移
负载均衡复杂	必须保证请求命中持有该状态的节点
宕机风险高	状态丢失会导致玩家回档或战斗异常
同步成本高	多节点之间状态一致性维护复杂

在 MMO、MOBA、SLG 等游戏中，这些问题尤为突出。

第四章：无状态架构的理想与局限

4.1 无状态架构的理想

无状态架构的核心思想：

每个请求独立，不依赖历史，不保存上下文。

其优点在于：

易于水平扩展；
容灾与自动恢复简单；
负载均衡器可任意分配请求；
开发与测试更模块化。

4.2 Web 世界的无状态典范

HTTP 是典型的无状态协议。
每次请求独立存在，状态靠 Cookie / Token 补充。

然而，游戏并非如此：

它有持续连接（WebSocket / TCP）；
有实时性；
有复杂的“事件链”；
有同步的“物理时间”。

4.3 无状态架构在游戏中的失败案例

如果一个游戏服务器尝试无状态化：

玩家移动 → HTTP 请求 → 计算新位置 → 响应

问题立刻出现：

延迟过高，无法实时；
每次都需加载玩家数据；
状态回溯不可行；
同步频率太高。

因此，游戏的“过程性”和“实时性”让无状态架构几乎无法成立。

第五章：游戏服务器中的状态类型与生命周期

游戏服务器中的状态，不是单一概念，而是复杂的分层结构。

5.1 状态类型分类表

类别	示例	存储介质	生命周期
会话状态（Session）	玩家连接信息	内存	在线期间
实体状态（Entity）	玩家角色、NPC、怪物	Redis / 内存	场景持续期间
世界状态（World）	地图格局、建筑状态	数据库	长期
临时状态（Transient）	技能CD、Buff、战斗帧	内存	毫秒~秒级
持久状态（Persistent）	背包、任务、装备	数据库	永久

5.2 状态生命周期

[创建] → [更新] → [广播] → [持久化] → [释放]

生命周期管理策略的设计决定了服务器的性能与可靠性。

5.3 状态一致性问题

在分布式环境中，状态同步面临三种一致性挑战：

逻辑一致性（玩家看到相同结果）
时序一致性（状态更新顺序一致）
数据一致性（持久化结果一致）

不同游戏根据类型（FPS、MMO、SLG）选择不同一致性模型：

类型	一致性策略
FPS	最终一致性（延迟补偿）
MMO	强一致性（锁定机制）
SLG	弱一致性 + 事务补偿

第六章：分布式状态管理的演进与实践

6.1 从单服到分区服

早期游戏（如《传奇》、《魔兽世界》）采用“单服+分区”模式：

每个区服独立；
玩家状态本地维护；
数据分隔天然防止冲突。

优点：状态集中，逻辑简单。
缺点：跨服交互难、负载不可伸缩。

6.2 分布式状态与一致性协议

现代游戏引入：

Redis Cluster；
Raft / Paxos 一致性协议；
Actor 模型（Akka、Orleans、Skynet）。

通过将状态局部化 + 拆分为独立 Actor，实现逻辑隔离与消息同步。

6.3 实践案例：Skynet、Akka、Orleans

框架	特征	状态管理机制
Skynet (Lua)	轻量并发	Service 层局部状态，消息驱动
Akka (Scala/Java)	Actor 模型	每个 Actor 维护内部状态
Orleans (.NET)	虚拟Actor	状态自动持久化/唤醒

这些框架的共同点：

将“状态”封装为微隔离单元，由消息驱动触发变更。

第七章：无状态化的尝试与折中策略

虽然完全无状态的游戏服务器几乎不可能，但部分无状态化是可行的。

7.1 状态外部化（State Externalization）

将状态从逻辑层剥离：

逻辑服（无状态） → 状态存储层（Redis / Actor） → 客户端

逻辑服仅处理规则，状态由独立服务持有。

优势：

易于水平扩展；
宕机恢复快；
逻辑层可用 Serverless 运行。

劣势：

状态访问延迟；
网络调用成本高；
一致性难保证。

7.2 房间级无状态 + 状态同步

在部分 SLG、PVP 游戏中，采用：

战斗服临时有状态；
战斗结束即销毁；
结果异步持久化。

这种设计使战斗逻辑“短期有状态”，整体“长期无状态”。

7.3 Serverless 化的实验性架构

云厂商（AWS GameLift、Agones、Open Match）尝试用 Serverless / K8s 承载短时房间实例。

设计思路：

Matchmaker 分配玩家；
创建短时 Pod；
房间状态局部维护；
结束后回收。

结论：

游戏服务器的“有状态性”不可避免，但可以通过“短命化、隔离化、外部化”来降低耦合度。

第八章：未来趋势——Serverless、边缘计算与游戏状态的解耦

8.1 状态在边缘的重新分布

边缘计算（Edge Computing）让状态可以：

临时保存在边缘节点；
快速与中心同步；
降低延迟。

8.2 混合状态架构（Hybrid Stateful）

未来的游戏服务器可能采用：

层次	状态管理方式
客户端	局部预测（Local Prediction）
边缘节点	短时缓存状态（Edge Cache）
中心节点	最终权威状态（Authoritative State）

通过多层同步，实现既快又准的体验。

8.3 AI 与状态管理

AI 可以：

动态预测状态变更；
自适应状态同步频率；
优化一致性与性能。

未来的 AI 驱动服务器可能实现“智能状态压缩”、“自学习同步策略”。

第九章：结语——状态，是游戏世界的灵魂

“无状态的服务器，也许能承载一个网页；

但无法承载一个世界。”

游戏服务器之所以必须有状态，是因为：

游戏是一种持续的模拟；
玩家与世界的关系是时序因果的链条；
状态承载着公平、公正、真实性。

然而，

有状态 ≠ 不可扩展。

通过解耦、外部化、短命化、Actor化，我们可以让游戏服务器既保持“状态的权威性”，又拥有“系统的弹性”。

参考实践体系（以 Go + Akka + Redis 为例）

graph TD
    Client --> Gateway
    Gateway --> GameLogic
    GameLogic --> RedisCluster
    GameLogic --> MatchMaker
    GameLogic --> BattleRoom
    BattleRoom --> DB
    RedisCluster --> SnapshotService
    SnapshotService --> DB

Gateway：无状态，负责连接与负载；
GameLogic：半无状态，通过 Redis 持有关键上下文；
BattleRoom：临时有状态；
SnapshotService：周期性持久化；
RedisCluster：状态中心；
DB：最终存档。

这种混合模式，是当前主流 MMO、SLG、MOBA 架构的现实折衷方案。

全文总结

维度	有状态架构	无状态架构	折中策略
性能	高效实时	请求延迟	局部缓存
扩展	困难	容易	状态外部化
一致性	强	弱	最终一致
容灾	恢复困难	快	快照同步
场景适用	MMO、MOBA、SLG	Web小游戏、回合制	混合实时制

目录