不是目录导览
文档按架构决策组织，每章固定覆盖设计目标、调用链、线程归属、源码取舍和验证边界。
BigWorld 引擎架构研究从源码证据链学习 MMO 服务器设计
重点分析线程、网络、Tick、通信、序列化、热更新、扩缩容与故障恢复，并给出源码证据、取舍和验证边界。
Skip to content
研究主线：BigWorld 不是普通 Python 项目，而是 C/C++ 主导、嵌入 Python 2.7 的分布式 MMO 服务器引擎。学习它的价值不在“照搬旧代码”，而在理解一个成熟商业 MMO 引擎如何在当时的平台约束下处理网络、实体、空间、负载、脚本和运维。
当前样板章
研究方法
先建立证据分级，避免把源码事实、时代推断和主观猜测混在一起。
进程拓扑
从 BaseApp、CellApp、DBApp、Mgr、LoginApp、Reviver 的职责边界理解分布式架构。
事件循环
分析主 Reactor、Timer、FrequentTask、Network 的执行顺序和 Tick 公平性。
网络模型
分析 select、poll、epoll、批量 UDP、SO_REUSEPORT、io_uring 与 Mercury 执行模型的边界。
可靠 UDP
分析 Mercury Channel 的 ACK、重发、窗口、piggyback、indexed channel 与版本语义。
通信与序列化
解释 InterfaceElement、Bundle、RPC、EntityDef 契约、BinaryStream、DataType 和 DataDescription。
运行时工程
覆盖线程架构、后台任务、Python GIL、热更新、测试时间控制、动态扩展和容灾。
游戏状态治理
分析 Base/Cell/Client、AOI/Witness/Ghost、Cell 分区、实体迁移和 DB 持久化。
工程质量
补齐安全限流、加密、Watcher/Profiler/日志、内存生命周期、构建依赖与 MMO 架构边界。
阅读顺序
- 研究方法与证据分级
- 进程拓扑与职责切分
- 主循环、Tick 与事件分发
- 网络 I/O 模型选择
- Mercury 可靠 UDP
- 通信抽象与 RPC
- 序列化与 EntityDef
- 网络背压与故障注入
- 实体模型：Base / Cell / Client
- EntityDef 契约与协议生成
- AOI、Witness 与 Ghost
- Cell 分区与负载均衡
- 实体迁移与 Offload
- 实体生命周期状态机
- 持久化与 DB 线程模型
- 登录、会话与 Proxy 接管
- 线程架构与后台任务
- 脚本热更新与迁移
- 测试体系与可控时间
- 动态扩展与容灾
- machined 控制面与进程发现
- 测试体系、故障注入与覆盖边界
- 安全、限流与加密
- Watcher、Profiler 与日志
- 内存、对象生命周期与资源管理
- 构建、平台与依赖治理
- MMO 架构边界对比
- 完整专题大纲
核心判断
- BigWorld 的服务端核心是分布式多进程，而不是单体服务器。
- 每个主要进程内部更偏单 Reactor 主线程，后台线程用于阻塞 I/O、资源加载、数据库任务等，不是全逻辑多线程。
- Linux 网络后端使用
epoll，但保持类似select的 level-triggered 语义，不是 ET 或io_uring架构。 - Mercury 的 UDP Channel 是逻辑连接，不是一玩家一 socket，因此网络优化不能只按“百万 FD”思路套模型。
- Mercury 可靠层按消息和 Bundle 表达可靠性，支持 ACK、重发、乱序窗口、piggyback、indexed channel 和实体迁移版本号。
- EntityDef 序列化不是单纯网络编码，而是脚本、实体属性、方法参数、持久化、迁移和热更新共同依赖的类型契约。
- EntityDef 契约由
entities.xml、.def、组件、接口、脚本分布、消息范围和 digest 共同生成，实体顺序和 exposed 编号具有协议含义。 - 网络背压由接收预算、发送队列满等待、人工丢包/延迟和 Mercury 可靠层共同组成，不是单个 epoll 参数能解释。
- BigWorld 的实体模型是 Base/Cell/Client 三层权威域，Cell 内又区分 real 和 ghost。
- AOI 由 Witness 管理，包含 hysteresis、带宽预算、实体 alias、可靠位置和 SpaceData 同步。
- Cell 负载均衡调整的是空间 BSP 边界和实体归属，不是普通请求分发。
- 实体生命周期本质上是 Base、Cell real、Ghost、Offload、Onload、Destroy 和 Restore 的状态机。
- 持久化由 BaseApp 协调 Base/Cell 数据，DBApp 通过 IDatabase 和后台任务隔离阻塞数据库操作。
- 登录链路通过 LoginApp、DBApp、BaseAppMgr、BaseApp 和 Proxy 二次握手完成，成功回复会缓存，失败回复刻意不可靠以降低 DoS 风险。
- BigWorld 的线程模型主要是主 Reactor + 后台任务回主线程提交，不是全逻辑多线程。
reloadScript是开发调试导向的高风险迁移机制，源码明确警告不要用于生产环境。- 当前时间系统主要依赖真实
timestamp()，可控虚拟时间是可重复测试的重要缺口。 - 当前测试体系在 Mercury、EntityDef、Replay、Ghost buffering 上并不薄弱，但 cluster 级黑盒回归和统一 chaos 注入仍然不足。
- 动态扩展的核心是 Manager 接纳进程并驱动 Cell/Entity 状态迁移，不是简单拉起无状态副本。
- machined 提供进程注册、接口发现、birth/death listener 和启动组件能力，是 BigWorld 旧式控制面的基础。
- BigWorld 有明确的入口限流、消息预算和 Channel 加密抽象，但不是现代全链路安全体系。
- Watcher/Profiler/EntityProfiler 是理解运行时状态和负载治理的核心设施，也需要权限边界和指标导出。
- 对象生命周期依赖侵入式引用计数、Python 对象、Mercury Channel 和实体 real/ghost 转换，不适合机械替换成标准智能指针。
- 构建治理必须处理 CMake/Makefile、OpenSSL、嵌入式 Python、第三方库和 server/client/tools 多目标，而不是只改某个依赖版本号。