游戏服务器中的数据库异步操作技术和游戏数据的保存机制

jaxecn

    原文：http://www.cppblog.com/jaxe/archive/2010/08/30/125258.html

    在游戏服务器中，处理玩家登陆需要向数据库查询玩家的账号和密码，玩家上线和下线需要对玩家的角色数据从数据库中读取和保存。可以说，相对于游戏逻辑处理来说，数据库操作是一种相对很慢的操作，即便你通过使用多个线程多个数据库连接来提高数据库操作的处理能力，但是，在高并发高负载的服务器应用中，这样仍然会是相当的负载瓶颈。设想这样一种设计方案，见下图：



    在大量玩家登陆游戏服务器时，由于有大量的数据库访问请求，即便是有自己实现的CACHE机制，还是会导致服务器耗尽所有的逻辑线程资源，服务器的处理能力将降低成DBMS的处理能力。
   
     为了不阻塞逻辑线程，可以采用异步数据库访问的方式，即数据库操作请求提交给专门的数据库处理线程池，然后逻辑线程不再等待数据库处理结果，继续处理其他，不再阻塞在这里。

     抽象的来看，对于一个需要持久化的游戏对象来说，可以考虑它有2个方法，读取和保存。那么我们抽象一个DBO接口：
   
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队列的优先级的问题等等。

yukun84

支持原创

zodane

缓存是个好东西 ，但是难度却很大。
关键就是缓存区数据的更新问题 。逻辑很复杂。
如果刷新频繁的 ，或者  不好判断，缓存是否更新的数据 ，就不适合写进缓存

ivanleo

内存型数据库！
好好搞
我看好你哟

zhcmeng

我觉得最好不要某个时刻统一全部玩家数据。
可以分区域、分数据类型以此提交
但是更好的方式可以根据当前DB线程池的处理压力动态提交，并且考虑想刚开服那几天压力非常大的情况下的特殊处理方案。

不过花费的精力肯定是很多的。

zhcmeng

对了，之前实习的时候公司里有用过SQLite内存数据库，可以参考下。

shirley0239

啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊

sunqitang

可以考虑有一个DBServer，在该服务器中设置一个Quene，缓存中的数据持续并且控制强度的向Quene中加入数据。

有一个线程池来不断去读取Quene中的数据，用来写入数据库。这也就等效于一个cahce（内存数据库）不断的去跟Db进行同步数据

DDR

整体提交更新有点浪费缓存的意义吧，打散存盘操作并平衡利用运行的空闲时间来保存感觉作用更大些

路人源

每个玩家登陆一个线程 该线程定时回写。玩家登陆看缓存中是否还有，没有才load数据库。如果要用到全服数据(排名)，则保存到另一个缓存，服务器关闭的时候才进行回写，或定时回写。达到数据一致。