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

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

    在大量玩家登陆游戏服务器时，由于有大量的数据库访问请求，即便是有自己实现的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队列的优先级的问题等等。

     PS:这篇文章里的架构其实就是一个GAMEDB服务器，里面的逻辑处理就是GAMEDB的逻辑处理。你可以把这篇文章理解成：一个GAMEDB服务器 的实现思路。。。