游戏架构的一点思考

目前我们的游戏一直采用mysql做为数据的最终存储方式，但我们也知道这种关系型数据库对于游戏来说根本就用不着，而且很多时候还是负担，所以一般游戏都会采用key-value的方式在内存中存储游戏数据，由后台线程或进程回写数据到mysql，我想这是大家普遍所采用的方式，其实为什么我们为什么不能直接把在内存中的热点数据保存到磁盘呢？从而省去异步回写这一关，当然对于不断膨胀的数据不可能在内存中存尽，一般内存存放的都是热点数据，那我们只需要在热点数据失效的时候把热点数据按一定规则保存到文件系统即可，这时有人会问题mysql这种关系数据库保存下来的数据不是更好，直观，同时在做运营分析时我们也需要这种直观的数据，其实对于这点我们应该把游戏数据和运营数据从二个层面来分析，虽然有时这二个层面的数据大部分会有一种重叠，但我们仔细来看，这二种类型的数据的要求是不同的，对于游戏数据要求是不可丢失，要求能快速命中，快速操作，能快速方便的加载到内存等特性，对于数据的直观性来其实必不是那么重要，那么我们其实是不必要考虑把数据存放在mysql这为关系型数据库中，那最能满足以上特性的就是直接从内存把数据dump出来保存，不仅保存方便，加载也快，而且不易发生错误，而对于运营数据而言要求是对于最终分析的结果不会受影响，至于中间发生个别的数据没有保存到位其实不影响全局分析的，所以这类数据我们就更加好操作了，直接打log文件，最后在一个时间点上汇总分析入库就好。