在开发游戏服务器程序的过程中，好像大家都默认使用Mysql, 如果有性能问题，大不了再加个Memcached, 或者干脆使用Redis来做数据库。
但这么做是否真的对所有模式的游戏服务器都合适呢， 对于某些游戏模式，是不是有更好的选择？
这是我最近在看《MySql是怎样运行的》，突然想到的问题。
我挑了三款存储模式完全不同的数据库， 来对比一下它们的特点。
Mysql: 一款关系型数据库。
由于有RedoLog，UndoLog的存在, 支持事务，数据落地比较可靠。
存储引擎InnoDB采用B Tree作为存储结构, 而由于B Tree的性质以及RedoLog,BinLog,UndoLog等机制的存在，导致Mysql的写入性能远低于查询性能。
因此Mysql适用于查询压力大，但是写入压力小的场景。虽然这些复杂的机制拖慢了写入速度，但是MySql可以提供各种复杂的查询。
即使如此，由于Mysql的数据结构是严格和磁盘对应的，相比Memcached和Redis等，将数据以内存数据结构的方式完全存储在内存的程序来讲，Mysql的查询性能还是要差不少。
这也是为什么在一些读流量大的地方，有时候会加Memcached或Redis作为前端，以防止大流量将Mysql冲垮（还可以使用从机做读写分离）。
Redis: 一款读写性能都很卓越的NoSql内存数据库。
本质上Redis就是一个带持久化功能的内存缓存，所有的数据以最适合内存访问的方式存储，因此查询极快， 写入极快，不支持事务，仅支持键-值查询。
其持久化方式分为RDB和AOF两种方式：
RDB是通过定时将进程内存中的数据集快照写入磁盘文件，这种持久化方式性能较高, 但安全性较低。默认配置下，可能会丢失最近60s的数据，由于RDB每次都是重新写入全量数据集，随着持久化频率间隔的降低，会显著增加CPU和IO开销。
AOF是性能和可靠性的另一种折衷, 每一条修改命令都会尽可能快的(不是立即,Redis会在Sleep前才会尝试)写入到文件系统缓存。至于什么时机通知操作系统将文件系统的脏页刷新到磁盘上, Redis最高可以配置为每次写入到操作系统文件系统缓存时，都执行刷新操作，默认为每秒通知操作系统刷新。
AOF文件的大小会随着数据修改次数的增加而逐渐变大，当大到一定程度后，Redis会Fork一个进程对AOF文件进行重写，以达到减少AOF文件尺寸的目的。AOF的重写时机同样可以进行配置。
不管是AOF还RDF方案, 都有一个不可避免的缺点, 每次生成RDB文件或重写AOF文件时, 都会将内存中全量的数据写入文件, 在数据量很大的情况下, 会产生CPU峰值。
LevelDB: 一款写性能卓越的NoSql数据库。
LevelDB底层采用LSM数据结构来存储数据， 所以写入极快， 查询较慢, 不支持事务，仅支持键-值查询(还支持键的遍历)
与Redis相反，LevelDB将所有数据都存储在硬盘上，仅在自身内存中缓存热数据。
由于LSM数据结构的特殊性，LevelDB还需要WAL(Write Ahead Log)来保证数据的可靠性。
WAL的作用和MySql的RedoLog的作用几乎一样，都是用于在意外Crash时，恢复还没有写入磁盘的数据。
在LSM数据结构中， 所有数据都是存储在SSTable中, 而SSTable是只读的。
这意味着随着数据增删改次数的增加，SSTable会变的越来越大。这时LevelDB的后台线程会在合适的时机，合并SSTable，以达到减少SSTable文件的目的。
LevelDB在合并数据时，是以SSTable文件为单位进行的， 而每个SSTable文件的大小一般为2M。这保证了，即使在数据库存有超大规模数据时，其合并过程依然是可控的。
总的来讲，MySql适合查询场景复杂， 而且查询多于写入的场景。Redis适合单进程数据量不大，并且对查询和写入都要求极高的场景。而LevelDB则适合于写多，读少的场景。
不管是Redis的内存限制，还是RDB生成/AOF的重写机制，都限制了其单进程能处理的数据量要远低于Mysql和LevelDB。同时，Redis的查询和写入性能也是这三者之间最出色的。
在我们游戏中，玩家数据是需要长驻内存的，即使一个玩家下线，别的玩家还是可以影响他的所有数据（包括货币和英雄）。
这意味着，我们必须在开服期间，就要从数据库加载所有游戏数据到游戏进程。之后只需要操作进程内数据即可。
在不考虑数据安全的情况下，甚至我们都不需要数据库。
只需要在停服时，像Redis写入RDB一样，将每个系统的数据按照约定的格式写入到不同的文件，下次开服再加载回来。
使用数据库的理由是，它可以让我们按需写入数据，可以提高数据的安全性。
那么，我们对它的需求就只剩一点了：“写入要快，持久化要安全”。
从安全性上来讲，Mysql, LevelDB, Redis的AOF都满足要求。
就写入速度而言，显然MySql落选了，因为他是为查询设计的数据库系统。
就现在需求而言，而Redis和LevelDB在CPU和内存足够的情况下，其实差别不大，甚至Redis要优于LevelDB。
如果我们想再节约一点，就会发现LevelDB在内存和CPU峰值方面其实优于Redis, 同时他的写入性能要差于Redis, 因为LevelDB有WAL和SSTable两次写入。
ps. 这种取舍其实很像数据结构的优化，一份平均每写10次只查一次的数据，显然没有必要每次写入之后都对数据排一下序，选择时关键是还是要看清数据库的定位以及自己的需求。
