修改自己游戏服务器中的数据库,游戏服务器中的数据库异步操做技术和游戏数据的保存机制...

在游戏服务器中，处理玩家登录须要向数据库查询玩家的帐号和密码，玩家上线和下线须要对玩家的角色数据从数据库中读取和保存。能够说，相对于游戏逻辑处理来讲，数据库操做是一种相对很慢的操做，即使你经过使用多个线程多个数据库链接来提升数据库操做的处理能力，可是，在高并发高负载的服务器应用中，这样仍然会是至关的负载瓶颈。设想这样一种设计方案，见下图：

在大量玩家登录游戏服务器时，因为有大量的数据库访问请求，即使是有本身实现的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服务器 的实现思路。。。