游戏服务器研究二：大世界的 scale 问题

单服大世界的 scale 是游戏服务器的经典难题，已经被很多人研究过了。我对 scale 类的问题很感兴趣，所以研究得也比较多。

本文不会探讨 MMO 类的网游提升单服承载人数有没有意义，只单纯讨论技术上如何实现。

像 moba、fps、棋牌、体育竞技等 “开房间类型的游戏”，scale 起来比较简单。此类游戏的 pvp 一般是相对较少的玩家在一个小场景里进行对战，以这种小场景为单位去做负载均衡就行了。所以，即使是千万级同时在线，也没啥特别的困难，我在另一篇文章 《游戏服务器工程实践一：百万级同时在线的全区全服游戏》 也描述过这方面的工程实践。

而像 mmo 这种大量玩家在同个场景的（这里称为大世界），scale 起来就比较困难。大世界本身就是一个整体，很难对它进行分割（partition）。无论怎么分割，它的各个部分之间都需要有交互，这种交互会带来工程实现上的诸多麻烦。

mmo 这里取广义的概念（ Massive Multiplayer Online ），不特指 mmorpg，所以像现在的各种 slg，也算是一种 mmo。

下文将大致总结一些相关的技术点。

1. 一些游戏的单服 pcu（最高同时在线）

坦克世界（world of tanks），自称是 mmo，但实际上并不是 mmo。它是 match based [1]，并不是一个大世界，相当于 moba 而已。官方说有 1M+ 的 pcu，但这也没啥特别的，毕竟这类游戏做负载均衡比较简单。另外，虽然它使用 bigworld engine 开发服务端，但并没有用到 bigworld 最拿手的动态负载能力。

eve online，这么多年下来，单服 pcu 纪录大概是 65000 左右 [2]。

wow，前段时间发了个测试数据，单服 pcu 能去到 12 万 [3]。

看起来还是 wow 最强？

2. scale 的方法

大致有两种方法，一种叫 zoning，一种叫 offloading。

zoning 是空间上的分割，把地图分割成多个区域，分散到多个线程（进程）进行负载。优点是分割效果好，可以达到很高的承载能力；缺点是存在大量的异步编程，复杂度高，开发效率低。

offloading 是逻辑上的分割，把相对独立的逻辑拆分到其他的线程（进程）去运算，主逻辑还是在一条线程上执行。优点是逻辑比较简单，开发效率较高；缺点是承载能力有限，主逻辑依然存在性能瓶颈。

2.1 zoning

zoning，即按地图区域进行分割。有两种方法进行分割：固定分割和动态分割。

固定分割，即在服务器运行前，预先按一定方式把地图分割成 n 个区域（cell），由若干个线程（进程）承载这些 cell，服务器运行起来之后这种分割就不变了。

动态分割，典型的实现是 bigworld，在服务器运行时进行动态分割，有一个全局的管理服务器（cellappmgr），根据整个地图上 entity（实体）的 cpu load 的分布情况，尽量平衡的对区域进行分割，分割出来的区域分散到各个 cell 服务器上（cellapp）。

有些文章会说 bigworld 的实现是一种分布式 aoi，但看过代码就知道了，它就是对地图区域进行动态分割而已。

2.1.1 zoning 固定分割

固定分割没什么好讲的，它的大体结构就是这样，下图取自韦易笑老师（ 知乎大佬：