2.4 持续在线世界型游戏问题模型

持续在线世界（Persistent World）游戏与房间制游戏的根本区别在于：游戏世界是持久存在的，玩家下线后世界仍然运行，其他玩家仍然在互动。这意味着世界状态不能像房间那样在内存中临时创建、用完销毁。

典型游戏：MMORPG（魔兽世界、最终幻想14、梦幻西游、黑色沙漠）、沙盒生存（Rust、ARK）、社交平台（第二人生、VRChat）。

三个核心问题

问题1：大量实体在共享空间中的可见性管理——AOI

问题的本质：在一个共享世界中，可能有成百上千个实体（玩家、NPC、怪物、掉落物）同时存在。但每个玩家只需要看到自己视野范围内的实体。如果服务器把所有实体的状态都广播给每个玩家，带宽和计算量会随实体数量的平方增长——这在 MMO 中是不可接受的。

AOI（Area of Interest）就是解决“哪些实体在谁的视野范围内“这个问题的数据结构和算法。

九宫格算法（Grid-based）

最常用的 AOI 算法。核心思想：将世界划分为等大小的格子，每个实体根据坐标属于某个格子。查询某实体附近的实体时，只需检查它所在格子及其相邻格子（共9个，所以叫“九宫格“）。

格子大小的选择：通常等于玩家的最大视野半径，这样一个九宫格恰好覆盖一个玩家的视野
实体移动时，只需从旧格子移到新格子，O(1) 更新
查询附近实体时，遍历9个格子中的实体，与总实体数无关

适用于实体分布相对均匀的场景。

四叉树（Quadtree）

将空间递归地四等分，直到每个叶子节点中的实体数量低于阈值。

适用于实体分布不均匀的场景（如主城密集、野外稀疏）
查询和更新的复杂度都是 O(log n)
但频繁移动的实体会导致频繁的树结构更新，实现比九宫格复杂

十字链表（Cross-list）

维护两条有序链表（X轴和Y轴），每个实体在两条链上都有一个节点。查询视野范围内的实体时，在两条链上分别找到视野边界的节点，取交集。

适用于实体稀疏分布的场景
但实现复杂，边界情况多

参考：关于 AOI 算法的系统性比较，业界公开的详细分析较少。GAMES104 课程（现代游戏引擎：理论与实践）Lecture 18 的讲义中涵盖了 MMO 中 AOI 的基本原理。 — https://games-1312234642.cos.ap-queue.myqcloud.com/course/GAMES104/GAMES104_Lecture18.pdf ¹

AOI 的实际影响：

AOI 不仅影响广播效率，还影响安全。如果 AOI 实现有 bug，可能把不应该看到的信息（如视野外的敌人位置）发送给客户端，被外挂利用。因此 AOI 的正确性和效率同等重要。

问题2：服务器分片（Sharding）——单台机器承载不了整个世界

一台服务器进程能承载的玩家数量有物理上限（CPU、内存、网络带宽）。MMO 的目标是支持远超单机承载能力的在线玩家。因此需要将世界拆分到多个服务器进程上。

三种分片策略：

按区域（地理）分片

将游戏地图划分为多个区域，每个区域由一台服务器进程管理。玩家跨区域时，从一个服务器迁移到另一个。

[大陆A服务器] [大陆B服务器] [副本服务器1] [副本服务器2]

魔兽世界就是这种架构：两个大陆各自由不同服务器集群管理，副本由独立的实例服务器处理。

优点：逻辑清晰，区域间天然隔离缺点：玩家倾向于聚集在热门区域（主城），导致负载极度不均衡

按功能（服务）分片

将游戏的不同功能模块拆分到独立的服务器上。

[登录服务器] [聊天服务器] [交易服务器] [战斗服务器] [世界服务器集群]

玩家同时连接多个服务器：世界服务器处理移动和视野，聊天服务器处理社交，交易服务器处理经济操作。

优点：各服务可独立扩展缺点：跨服务交互的延迟和一致性管理更复杂

动态分片

根据实时负载动态调整分片边界。当某个区域玩家过多时，将该区域进一步细分，分配更多服务器。

这是最理想但也最复杂的方案。需要在运行时迁移玩家、转移实体状态、维护跨分片一致性。

参考：腾讯游戏学院专家 Wade 在“经典游戏服务器端架构概述“中详细描述了 MMO 的两种典型部署架构——“分区分服”（传统国服模式，每个区服独立）和“全区全服“（所有玩家在同一逻辑世界，靠分片支撑）。 — https://zhuanlan.zhihu.com/p/336195014 ²

参考：CCP Games 在 GDC 演讲 “The Server Technology of EVE Online” 中讲解了 EVE Online 的单世界（Single-Shard）架构。EVE 是极少数真正做到“所有玩家在同一个世界“的 MMO，其技术代价极高——需要专门的硬件和极致的优化。 — https://gdcvault.com/play/1030721/The-Server-Technology-of-EVE ³

参考：IT Hare 的 “Server-Side MMO Architecture” 系统讲解了 MMO 的经典部署架构，从最简单的单体到复杂的分布式集群，包含清晰的架构图。 — http://ithare.com/chapter-via-server-side-mmo-architecture-naive-and-classical-deployment-architectures/2/ ⁴

跨服务器交互的核心难题：

无论哪种分片方式，都需要处理“分片边界“问题：

玩家跨区域移动：需要将玩家状态从一个服务器迁移到另一个，迁移过程中不能丢失操作
跨区域可见性：玩家站在两个区域的边界上时，需要看到对面的实体。这意味着相邻区域的服务器需要交换实体信息
跨区域交互：玩家A在区域X攻击区域Y的玩家B，需要跨服务器判定和状态同步

这些问题的通用解法是“服务器间消息总线“——每个服务器将自己边界附近的实体信息广播给相邻服务器，相邻服务器将这些“影子实体“展示给本区域的玩家。

问题3：持久化——海量玩家数据的存储和加载

与房间制游戏不同，MMO 的玩家数据是永久存储的，而且需要在玩家上线时快速加载。

数据特点：

量大：每个玩家的数据可能包含数百个字段（装备、技能、任务进度、社交关系等），一个成熟 MMO 的单服玩家数据可达 TB 级
读写模式：上线时大量读取，游戏中频繁小量写入，下线时大量写入
一致性要求：涉及货币和物品的操作必须保证事务性（不能凭空产生或消失）

常见的持久化架构：

游戏服务器（内存中维护玩家状态）
    │
    ├── 操作日志（WAL）→ 定期刷盘，用于崩溃恢复
    │
    ├── 定时存档 → 每隔 N 秒将内存状态写入数据库
    │
    └── 关键操作即时写 → 货币变动、物品获得/消耗等

关键设计决策：

定时存档的间隔：太频繁会影响数据库性能，太稀疏会丢失更多数据（服务器崩溃时丢失自上次存档以来的所有数据）。通常 30秒到5分钟。
操作日志：记录所有关键操作的日志（类似数据库的 WAL），崩溃后可以重放恢复到最新状态
冷热分离：活跃玩家的数据在内存中，长期不上线的玩家数据只存数据库，上线时再加载

参考：prdeving 的 “MMO Architecture: Source of Truth, Dataflows, I/O Bottlenecks” 深入分析了 MMO 中数据 I/O 的瓶颈所在——瓶颈往往不在数据库本身，而在游戏服务器与数据库之间的数据流设计。 — https://prdeving.wordpress.com/2023/09/29/mmo-architecture-source-of-truth-dataflows-i-o-bottlenecks-and-how-to-solve-them/ ⁵

架构总览

客户端
  │
  ▼
网关/代理层（负载均衡、认证）
  │
  ├──▶ 世界服务器集群
  │     ├── 区域A服务器（管理区域A内的实体、AOI）
  │     ├── 区域B服务器
  │     └── 实例服务器（副本）
  │
  ├──▶ 聊天服务器
  │
  ├──▶ 交易/拍卖行服务器
  │
  └──▶ 数据库层
        ├── Redis（缓存 + 热数据）
        ├── MySQL/PostgreSQL（持久化）
        └── 操作日志存储

与房间制游戏的对比

维度	房间制游戏	MMO
状态生命周期	对局期间	永久
扩展方式	加房间服务器	分片 + 加功能服务器
状态一致性范围	单房间内	跨服务器
峰值处理	匹配排队	动态分片 + 弹性扩容
数据持久化	只存结果	全量持续存储
AOI	通常不需要（房间内广播即可）	核心组件
崩溃恢复	对局作废，重开	必须恢复到崩溃前状态

小结

AOI 是 MMO 的基础组件，解决“谁看到谁“的问题。九宫格算法是工业实践中最常用的方案
分片是 MMO 扩展性的关键。按区域分片最常见，按功能分片是补充，动态分片是理想但复杂
持久化 的核心矛盾是性能与数据安全性的平衡——定时存档间隔、操作日志、冷热分离是三个关键决策
MMO 的架构复杂度远高于房间制游戏，核心原因是跨服务器一致性和持久化世界状态管理

下一节（2.5）将学习：长周期成长与异步交互型游戏问题模型。

参考文献

GAMES104, “Lecture 18: Networked Multiplayer in Game Engines”, https://games-1312234642.cos.ap-queue.myqcloud.com/course/GAMES104/GAMES104_Lecture18.pdf ↩
腾讯游戏学院专家 Wade, “经典游戏服务器端架构概述”, https://zhuanlan.zhihu.com/p/336195014 ↩
CCP Games, “The Server Technology of EVE Online: How to Cope with 300K Players”, GDC, https://gdcvault.com/play/1030721/The-Server-Technology-of-EVE ↩
IT Hare, “Server-Side MMO Architecture”, http://ithare.com/chapter-via-server-side-mmo-architecture-naive-and-classical-deployment-architectures/2/ ↩
prdeving, “MMO Architecture: Source of Truth, Dataflows, I/O Bottlenecks”, https://prdeving.wordpress.com/2023/09/29/mmo-architecture-source-of-truth-dataflows-i-o-bottlenecks-and-how-to-solve-them/ ↩

Keyboard shortcuts

游戏开发系统化知识地图