数据库选择历程

我们的项目一直使用MySQL作为数据库。无论是从C++的服务器，还是到Golang服务器。 当年搞服务器时，看大部分人都是用SQL(MySQL/SQLServer)，而Mongo感觉像邪教一样，再加上服务器还是Linux比较正统，所以果断选了MySQL。

刚开始感觉，游戏服务器的数据存储其实应该是蛮神圣的过程。那么多的数据， 需要按照MySQL一样分表，分字段存储，为了查询，还要乖乖的学一下SQL的语法。

就这么折腾了几年，在云DB的蒙蔽下，一直认为MySQL就是做游戏服务器存储的专业技术。分布式和存储压力一定交给云DB来做。直到真正试了下NoSQL在游戏服务器开发里的思路。

用了Golang，才发现同步写逻辑是多么的优雅。

用了NoSQL系列的数据库，才意识到: 游戏服务器的数据存储和游戏服务器的存盘两个概念差异其实蛮大的。

MySQL中，背包其实跟角色完全没有关系，只是通过1个角色id映射过去，人为的割裂了数据的关联性。还硬生生的整出个概念叫结构化查询让你学。

NoSQL中，只是把数据库当成是存储点，每个角色的数据是完整的一块。里面怎么存随你便。每个角色通过id来查询，其他都没有了。

于是乎，游戏开发变得异常简单。MySQL角色进门查询4~5次才能搞定要的数据。而NoSQL一口气全查出来，手机号出售平台存盘也无需增量，直接存盘就可以了。

所以现在觉得，NoSQL的思路对于游戏服务器存储来说简直是完美的！

NoSQL数据库方案对比

NoSQL下实现方案很多，游戏常用的就这么3家: mongo， redis， memcached

下面说下优缺点

mongo

磁盘映射内存数据库

value为document类型，基于BSON的value序列化

应用场景:

适合多写少读，例如日志和备份

redis

内存数据库

单核

value限制512M

多种value类型，游戏用途使用私有的序列化协议(例如protobuf)

支持落地(bgsave)

用户: 新浪，淘宝，Flickr，Github

应用场景: 适合读写都很高，数据处理复杂等

memcached

内存数据库

多核

value限制1M

不支持落地(持久化)

用户: LiveJournal、hatena、Facebook、Vox

应用场景: 动态系统中的缓冲，适合多读少写

个人评价

memcached 适合网页缓冲，游戏里很少有使用。目前只有腾讯云支持云memcached。

redis非常适合游戏的内存数据库，但是落地策略会比较复杂，需要具体分析，可以参考后面的链接看下云风怎么处理这个问题。

mongo数据库在早期还是非常不错的NoSQL的数据库。工具比较方便，可视化。但是随着近年来游戏的并发度越来越高， 所以为了一次到位，很多人还是选择了redis。