谈谈陌陌争霸在数据库方面踩过的坑（前篇）

陌陌争霸 这个项目一开始不叫这个名字，它在 2013 年中的时候，还只是一个我们公司 用来试水移动游戏的试验项目。

最开始的目标很明确，COC 是打动我的第一款基于移动平台网络游戏，让我看到了和传统 MMO 不同的网络游戏设计方向。我觉得只需要把其中最核心的部分剥离出来，我们很快可以做出一个简单的却不同于以往 MMO 的游戏，然后就可以着手在此基础上发展。

至于后来找到陌陌合作，是个机缘巧合的故事。

我们的试验项目完成，却没想好怎么推给玩家去玩（而这类游戏没有一定的玩家群体基本玩不起来），而陌陌 游戏平台刚上线，仅有的一款产品（类似泡泡龙的游戏）成绩不佳。因为我们公司和陌陌的创始人都曾经在网易工作，非常熟悉。这款游戏也就只花了一个月时间就 在陌陌游戏平台发布了。

一开始我们只把刚完成狂刃 启动器项目的阿楠调过来换掉我来做这个项目，我在做完了初期的图形引擎工作后，就把游戏的实现交给了他。我们只打算做客户端，因为只有这部分需要重新积累技术经验；而服务器不会和传统 MMO 有太大的不同。而我们公司已经围绕 skynet 这套服务器框架开发有很长一段时间了，随时都可以快速把这个手游项目的服务器快速搭建起来。

到 2013 年夏天，感觉应该开始动手做服务器部分了。晓靖在斗罗大陆的端游项目中积累了不少服务器开发的经验，也是除我之外，对 skynet 最为熟悉的人；如果这个试验项目只配备一个程序来开发服务器的话，没有更好的人选了。

从那个时候起，我们开始考虑服务器的结构，其中也包括了数据库的选型和构架。

skynet 有自己的 IO 模型，如果要足够高效，最好是能用 skynet 提供的 socket 库自己写 DB 的 driver 。因为 redis 的协议最简洁，所以最先我只给 skynet 制作了 redis 的 driver 。而我们代理的游戏狂刃的开发方使用的是 MongoDB ，为了运营方便，我们的平台也使用它做了不少东西，我便制作给 skynet 制作了初步的 mongodb driver 。到服务器开始开发时，我们有了两个选择。

十多年的游戏行业从业经验告诉我，数据库在实时交互性较强的在线游戏中，主要起的是一个数据备份容灾的作用。很少会将其用于数据交换。而在其它领域，很多开发者则选择把数据库作为业务模块间的数据交换，带着这个思路来做游戏，往往会带来很严重的性能问题。

简单说，理论上，由于游戏服务器往往 7 * 24 小时持续工作，且玩家具有强交互性，大部分游戏世界里的数据都一直存在于内存中。当服务器启动后，一旦数据加载完毕，大部分不再需要退出内存。服务器只是 在不断的创造新数据并让这些数据在内存中流通而已，它没有任何需要从外部读取数据。如果内存无限大，且服务器永远不会当机，数据库这个设施没有存在的必要。

当然这两个前提条件都不可能成立。

对于内存无限大这个条件，传统 MMORPG 游戏需要消耗的内存是 O(n) 的，n 和总用户数相关。虽然同时玩游戏的用户数（活跃用户数）有限，很难持续增长；但总用户数的确是随时间增长的。我们只要把 n 从总用户数变成活跃用户数后，基本就能维持内存的需求。

最简单的做法是，当一个用户不活跃后，就把这部分数据落地（写入磁盘），当他有一天又变得活跃后，再从磁盘加载回来。在端游早期，用户活跃的标准就 是他是否在线。我们在用户上线的时候加载他的数据，离线的时候将数据落地即可。从开发角度看，数据如何保存，最简单的方法不是使用数据库，而是以用户 id 为文件名，把用户数据序列化成文本写入文件系统即可。这也就是网易早期游戏的通用做法。

对于服务器稳定性的要求，我们不可能作到 100% 不当机，所以数据还是要定期存盘的。可以是按时间为周期保存，也可以是在关键操作发生时保存。这样在灾难发生的时候可以恢复回来。

btw, 一个系统所需要管理的数据总量小于系统总的内存量这一点，不仅仅在游戏领域，其实很多别的系统也存在。所以 redis 这种纯内存数据库才有了广泛的应用空间。redis 的 BGSAVE 以及 BGSAVE 的两种模式，也对应了上面所指的数据落地策略。

至于，如何操作这些数据的问题，既然数据都在你系统的内存中，总可以写出对应的算法去处理它们吧？明白了这一点，就能明白为什么在大多数在线游戏系统中，选用怎样的数据库就不是什么重要的问题了。

当然，一个在线游戏的运营还是需要大量的游戏内数据分析的。本着不同的业务逻辑尽量分离的原则，我们还是需要把游戏内的数据输出出来，交给专业的系统，专业的人来处理。这一部分的数据量远大于游戏系统为玩家服务时所需要的量。我认为它的空间复杂度是 O(n * m) 的。其中有两个维度，一是玩家的总数，二是运营的时间。游戏服务器需要把运营过程中的数据吐出，保存到可以处理这么大数据量的数据库中去。我们把这部分数 据称为运营 log ，这个名称我觉得不太合适，因为它容易和程序输出的供调试分析的错误 log 相混淆，不过历史上在网易工作时大家都这么叫，我也不打算起个新名词了。

陌陌争霸在服务器方面的选型和构架按着这个思路做出来：

我们用 redis 保存玩家的数据，考虑到玩家数量可能很多，一个 redis 仓库可能不够，我们使用了 32 个 redis 仓库，按玩家 id 分开存放。在部署方面，可以在用户数量较少的时候，把多个 redis 仓库部署在同一台物理机上，再随着用户规模扩大而分开部署。如果 32 个仓库不够的话，进一步细分也不会是难事。

在前三个月，我们不用太考虑冷热数据的问题，这个期间还谈不上流失玩家，所有玩家数据都是热数据。由于开发时间紧迫，我们把冷数据处理留到后期再处理。

至于数据落地的问题，redis 已有 bgsave 的能力，我们只需要细调就好了。

而运营 log 和一些随时间自然增长的数据，比如战斗录像，我们选择了不受内存限制，且易于做数据分析的 mongodb 。由于担心数据量过大，使用了 mongos 分片。

初期的设计就是这样了，只到今天，也没有在结构上做什么调整。但是在操作过程中踩了许多坑，都是值得好好记录下来的经验。