RPG和SNS类游戏的cache server设计和实现区别随笔

sea_bug

博客：O1高地

把平时对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类的游戏。