共计 1838 个字符，预计需要花费 5 分钟才能阅读完成。
| 导读 | 前端时间魔兽这个电影我相信大家都看过了哈，作为一个码农，有时候我也会去思考魔兽世界这个游戏背后他的一些设计和实现，比如他用什么数据库。当然真正用什么数据库这个我是不确定的，我们今天的主题是当游戏爱上 MongoDB，所以我们只聊游戏如果采用 MongoDB 作为数据库有哪些好处。 |
我们知道，游戏的一个特点是需求变化快，为了保持玩家一直有新鲜感，需要不停的往游戏中加入新的元素。就拿一些 MMO 游戏的装备（道具）系统为例，假如使用传统的关系型数据库来存放这些数据，可能会面临需要经常做表结构修改这样的 DDL 操作。那如果采用 MongoDB 的话就不会有这个问题，schema-free 的特性可以支持一个表（集合）内包含不同结构的文档。此外，MongoDB 直接使用 JSON 格式进行数据交互，这也是最接近对象模型的，对开发人员来说非常友好。关于如何使用 MongoDB 进行数据建模可以参考 TJ 写的 MongoDB 进阶模式设计。
现在很多游戏都走游戏免费道具收费的模式，有很多类似道具自动过期的功能，这可以通过 MongoDB 的 TTL 索引来轻而易举的实现。同样，现在很多游戏使用地理位置来作为社交系统的一部分，比如附近玩家这样的功能。这也可以直接利用 MongoDB 的地理位置索引来做。MongoDB 原生支持了这些功能，可以说非常方便。
以前玩魔兽世界的时候，每个礼拜二都要来一次停服维护。当时大家也习惯了，毕竟魔兽世界还是玩点卡的，游戏时间都是自己花钱买的。但对于现在的免费游戏来说，经常停服，可能玩家都会接受不了。对那些日流水好几位数字的游戏公司来说，时间就是金钱，停服维护可能就有种自己在不停烧钱的感觉。所以现在都要追求服务高可用，尽可能减少停服时间。数据库服务通常也是整个游戏服务中的一个重要环节。MongoDB 的副本集是一个相当成熟的高可用架构，它通过一主多备结构保证服务的可用性，当主宕机后还存活的备会自动选举出新的主。
阿里云数据库 MongoDB 在 MongoDB 自身高可用架构下做了进一步增强。采用一主一备一隐藏节点的经典 3 节点配置，对外暴露两个 VIP 提供用户访问，在某个节点宕机时自动进行 VIP 切换，保证用户始终有 2 个节点可用。需要注意的是，这必须是用户正确配置成副本集访问模式时才生效。
说完高可用，我们来说说高可扩展方面。同样还是魔兽世界，想必很多早期玩家都体验过排队，之所以要排队，主要是因为服务能力不够导致。当然，这通常和数据库无关，不过，一个好的架构师是不会允许有某个环节出现明显的瓶颈的。MongoDB 由于其数据相对独立的特性，相比于关系型数据库，较容易进行水平扩展。其 Sharding 架构已在很多生产环境中久经验证，业内有些公司对其进一步优化后已在管理上百 PB 的数据。对于运维人员来说也是相当友好，动态扩容和负载均衡都是自动进行的，用户只需要选一个好的 shard key 即可。
运营游戏有时候会面临不得不对游戏进行回档这样的痛苦选择。因为程序不可避免会有 bug 的存在，如果有某个 bug 被恶意利用，亦或者是人皆会犯错误，某个 GM 不小心手抖发了大量 RMB 道具，都可能导致较大的经济损失出现。如果游戏不是很完善，没有一个更好的解决方案的情况下，这时候可能就要考虑对游戏进行回档了。对于数据库数据的回档来说，MongoDB 提供了一个延迟副本集节点的设定来解决这个问题。即，将某个节点配置成落后于最新数据一定的时间量。
当然，这还是很粗粒度的，如果要精确回档到延迟时间内或者更早的时间点，甚至是任意时间点，就还要在备份恢复这块上做更多的工作。阿里云 MongoDB 近期会推出任意时间点恢复的功能，以满足包括这个场景在内的备份恢复需求，敬请关注。
现在是大数据时代，通过数据分析辅助运营决策是必不可少的。在数据分析方面，MongoDB 提供了 Aggregation pipeline 和 Map-Reduce 这两个强大的功能。其中 Aggregation pipeline 使用管道处理模型，提供了过滤、分组、排序等丰富的操作支持，具有较简单的操作性兼顾较好的性能，而 Map-Reduce 则可以使用 JavaScript 进行自定义处理，在灵活性上更胜一筹。
综上所述，MongoDB 有如此多的适合于游戏开发场景的特性，还等什么呢？
