logo

作者:云风 点评:本文结合实际游戏案例,谈到了MongoDB,redis的配合使用以及为什么这么用。

陌陌争霸 这个项目一开始不叫这个名字,它在 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 分片。

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

今天要去吃饭了,明天接着写。

预告:陌陌游戏平台的第二款游戏:陌陌劲舞团先于陌陌争霸半个月上线。上线后不到两天就宣布停服,停服时间一再延长,一直拖了一周。传言说问题就出在数据库这块。下篇打算八卦一下这个事情。

来源:http://blog.codingnow.com/2014/03/mmzb_db.html

0 回复
需要 登录 后方可回复, 如果你还没有账号你可以 注册 一个帐号。