谈谈陌陌争霸在数据库方面踩过的坑(前篇)
陌陌争霸 这个项目一开始不叫这个名字，它在 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 分片。
初期的设计就是这样了，只到今天，也没有在结构上做什么调整。但是在操作过程中踩了许多坑，都是值得好好记录下来的经验。
今天要去吃饭了，明天接着写。
预告：陌陌游戏平台的第二款游戏：陌陌劲舞团先于陌陌争霸半个月上线。上线后不到两天就宣布停服，停服时间一再延长，一直拖了一周。传言说问题就出在数据库这块。下篇打算八卦一下这个事情。
Comments
楼上这就不对了，将高超的技术应用在各种产品中是我们的责任，而产品是什么不应该影响我们发挥技术的水平。说到底游戏只是游戏，好坏都有人喜欢，我们不应该轻易的去评价他们。
Posted by: aoz | (15) November 12, 2014 11:08 AM
做着垃圾一样的手游，还好意思说是做游戏的，人的蜕变真可怕……
Posted by: B9_bank | (14) March 8, 2014 09:56 AM
从开发角度看，数据如何保存，最简单的方法不是使用数据库，而是以用户 id 为文件名，把用户数据序列化成文本写入文件系统即可
将玩家数据序列号为json数据存储在key-value数据库中
Posted by: lee | (13) March 3, 2014 12:51 PM
Redis 只用来做排行榜数据量很少，复杂度也很低，其他数据还是使用SQL+缓存，你这边已经全部使用Redis 代替数据库了吗
Posted by: 黄牛 | (12) March 2, 2014 09:37 PM
而运营 log 和一些随时间自然增长的数据，比如战斗录像，我们选择了不受内存限制，且易于做数据分析的 mongodb
是把log存到mongo里面吗？这样可能坑会很大，mongo存的数据量我看是没有多大性价比的。
如果存log，我觉得现在的
logstash+elasticsearch 比较好
Posted by: memorybox | (11) March 2, 2014 04:57 PM
用了一段时间mongodb，感觉用起来很好很方便，但有两个地方还是不太满意。
一是他内存的占用，实在是太贪得无厌了。
另外就是它数据的存储，比原始数据膨胀了10倍不止。
不过它灵活的sharding和存储方式，实在是让人爱不释手哦
Posted by: memorybox | (10) March 2, 2014 04:55 PM
分享下玩家匹配吧，如何用redis完成呢？
Posted by: Anonymous | (9) March 2, 2014 02:40 PM
都是干货，谢谢分享
Posted by: smallghost | (8) March 2, 2014 11:13 AM
关注后续~
Posted by: gegewu | (7) March 2, 2014 01:10 AM
请教您一个问题，陌陌争霸的redis数据落地你们具体是怎么操作的呢？
Posted by: xiongli | (6) March 1, 2014 09:27 PM
在玩家分片的情况下，排名系统是咋实现的呢？ 是玩家的分数 更新了就去修改 一个单独维护的 排名序列么？
Posted by: Anonymous | (5) March 1, 2014 09:12 PM
我想听这八卦事情啊！另外云风哥你说的id切，是指hash分布在32个库吗？还是指id段来切？感觉两种切法都存在一些问题
Posted by: lelong | (4) March 1, 2014 08:58 PM
我想听这八卦事情啊！另外云风哥你说的id切，是指hash分布在32个库吗？还是指id段来切？感觉两种切法都存在一些问题
Posted by: lelon | (3) March 1, 2014 08:58 PM
Redis发展迅猛，走入千家万户了。三年前redis基本的tcp连接维护都有问题，内存碎片也很严重...
Posted by: technerd | (2) March 1, 2014 07:21 PM
期待八卦
Posted by: wesom | (1) March 1, 2014 07:03 PM