SNS类游戏cache server设计浅析
发表于2016-10-23
游戏的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类的游戏。
在游戏服务器中，处理玩家登陆需要向数据库查询玩家的账号和密码，玩家上线和下线需要对玩家的角色数据从数据库中读取和保存。可以说，相对于游戏逻辑处理来说，数据库操作是一种相对很慢的操作，即便你通过使用多个线程多个数据库连接来提高数据库操作的处理能力，但是，在高并发高负载的服务器应用中，这样仍然会是相当的负载瓶颈。设想这样一种设计方案，见下图：
在大量玩家登陆游戏服务器时，由于有大量的数据库访问请求，即便是有自己实现的CACHE机制，还是会导致服务器耗尽所有的逻辑线程资源，服务器的处理能力将降低成DBMS的处理能力。
为了不阻塞逻辑线程，可以采用异步数据库访问的方式，即数据库操作请求提交给专门的数据库处理线程池，然后逻辑线程不再等待数据库处理结果，继续处理其他，不再阻塞在这里。
抽象的来看，对于一个需要持久化的游戏对象来说，可以考虑它有2个方法，读取和保存。那么我们抽象一个DBO接口：
1 2 3 4 5 | struct IDbo { virtual bool SaveToDB(DB*)=0; virtual bool LoadFromDB(DB*)=0; }; |
然后把设计方案改成下面这种：
改成数据库异步处理后，在想想现在的游戏数据的保存机制应该是怎样改进的，为了保障数据安全，我们希望不只是玩家下线的时候才会保存玩家数据，而是希望每隔一段时间统一保存所有在线玩家的数据，那么，可以考虑这样的思路：假设我们有一个GAMEDB服务器，GAMEDB缓存了所有在线玩家的角色数据，每到保存时间，GAMEDB就将所有在线玩家的数据(DBO）的副本都统一提交给DB线程池，让它保存数据，提交的过程很快，提交完后，GAMEDB的逻辑线程仍能继续处理游戏服务器的更新和读取CACHE的请求。为什么要保存副本呢，DB线程的执行保存队列的过程也许很耗时，但是队列中的数据都是GAMEDB提交DBO那个时刻的数据，这样就能保证玩家的游戏数据的完整性。
当然，我这里提的这只是个思路，这里面还有很多细节没有讨论，例如如果DB线程池正在保存九点钟时刻保存的数据，到了十点钟新的保存时刻时，DB线程池还没保存完九点钟时刻的DBO副本队列，这时应该怎么处理；DBO对象的划分粒度的问题；DBO队列的优先级的问题等等。
腾讯GAD游戏程序交流群：484290331