http://blog.csdn.net/herm_lib/article/details/8171196
本文就介绍游戏服务器的数据缓存和持久化的设计策略。基本上各种类型的游戏服务器都适用，包括全区全服、分区分服的SNS类、ACG或者RPG。数据的缓存和持久化从技术角度来讲是比较容易实现？做过几个类似的功能模块后，渐渐地会有一种模块重用的想法，有一个公共的中间件可以容易支持我们游戏服务器各种缓存和持久化需求。目前有类似开源的项目，我们以前的公司有类似的项目。项目组如果利用可靠的中间件，还是可以提高开发效率的。
本文缓存和持久化中间件的设计目标
限定游戏服务器领域，但基本上满足所有类型的游戏需求。我不废话，直接从需求场景引出要支持哪些功能。
缓存和持久化中间件几个元素
(1) 访问中间件的接口
这块主要在写数据到cache的策略，实时写或者定时写；
定时写数据的优先级， 比如重要数据立即写，非重要数据，隔很长时间才写；
分布式的访问策略，取漠或者一致性hash定位cache。
(2) cache
中间件本身要不要做cache，如果使用cache，有没有某种淘汰策略(如LRU)；
cache持久化或者非持久化；
实时持久化或者定时持久化；
定时持久化的优先级；
分布式策略。
(3) 持久化
数据持久化的格式；
持久化的目标设备；
分布式策略。
需求场景一
logicd [cache] ---------------> storage
logicd就逻辑服务器，storage是我们数据持久化的存储设备(DB，文件之类的)。
有的游戏一个逻辑服务器，玩家在游戏的过程中不会切换服务器。这种情况，cache最好作为一个模块(so/lib)内嵌到游戏逻辑进程中。
因为logicd已经缓存了数据，cache模块就不做缓存了，否则就双份缓存，cache模块相当于简单持久化接口。
cache的接口定时写到cache；
没有缓存的话，cache利用host进程的内存，采用定时的时持久化策略；或者只要接口有数据过来，马上持久化，让数据落地。
需求场景二
logicd1 + logicd2 --------->cahced------>storage
这个场景在实际的游戏服务器设计中是蛮多的，就是玩家可能会在两个逻辑服务器上切换，从logicd1切到logicd2的时候，从cached拉最新的数据。
logicd的访问接口一般是优先级定时写到cahced；
cached要做缓存，采用类似LRU的淘汰算法或者不淘汰，优先级定时地持久化到storage。
需求场景三
logicd1 + logicd2 + otherd ------->cached
这个场景模型在sns类的游戏中可见，比如sns类的可有可无的好友消息动态之类的内容，某几种服务器产生消息，直接写到cached；其他服务器可能要从cached去读。
logicd的访问接口一般是优先级定时写到cahced，这个定时时间间隔可以开得长一些；
cache肯定做缓存采用类似LRU的淘汰算法或者不淘汰，不持久化，机器重启数据就没了。
就简单地写这些，下篇准备总结一下具体理想化的实现，同时放出herm cached的源码实现。