把平时对cache这块内容的思考、实践总结一下。
游戏的cache server的设计和实现策略由游戏逻辑特点决定。RPG和SNS类用户(这里用户指游戏中的玩家帐号和角色)行为特征不一样，他们的cache server实现策略也存在不同。
RPG类的cache server实现起来比较简单一些。
大部分情况以玩家帐号和角色ID作为key，处理查增改删的功能。
查询
先看cache中有没有对应key的数据，有，直接返回；没有从持久化设备处查询，查到了，更新cache。
增加和更新
很多时候，这两个功能要一起实现。增加一条记录大部分情况要有返回值。
应用要增加一条记录，要确定一下，他是否存在了，存在的话，就更新一下cache。同时记录一下，这条记录已经改过的(一般称为"脏数据")，经过一定的时间后，会被同步到持久化设备中。
如果新增的记录确实不存在，往cache里增加一条记录，也把这条记录做个标记，过段时间将数据写到持久化设备中。
这里说一下针对不同数据采用不同写入持久化设备优先级的方法。我用的方法比较直接简单，启用多个队列，不同的队列代表不同的写入优先级。有更新的数据，将其放到某个优先级队列中，到了时间，这些改变的数据将会被写到持久化设备。
删除
先把cache中的数据拿掉，接着删除持久化设备的数据。
接下来说一下SNS类游戏的cache server实现策略
SNS类游戏和RPG不同地方：
(1) A会直接操作R，改变R的某些数据；有时候，B也会同时改变R的数据。
(2) 很多时候，游戏服务器上的R在某些数据被其他角色改变后，须要知道哪些数据被改变了，保证在一定的时间拿到新数据。
针对上面两点，cache server还要提供增量改变数据和提供改变通知的功能。
一种是，R数据变了，只要R在线就通知R。
另外一个种是，R告诉cache server要通知的数据，这样cahce server上的R的数据被改了，如果R在线，而且确定改的数据是要通知的数据，才要告诉R，哪些数据被改了。
根据上面的介绍，图方便的开发人员，可以看看有没有现成的第三方cache server可以直接用，比如memcache,redis之类能否满足业务要求。
总结一下，SNS类的cache server的功能是RPG类的cache server超级。能用到sns类的通用cache server也可以满足RPG类的游戏。