疯狂了！当游戏爱上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有如此多的适合于游戏开发场景的特性，还等什么呢？