一种新型的游戏服务器架构CDDE

1.传统的数据模式以整个实体数据读出，处理完成后，整体数据再写入。而在游戏行业，对同一数据的操作频繁性，使得传统处理方式更容易的暴露所在的瓶颈，所有的业务逻辑都压在数据库的负载上，导致可用性以及响应速度的下降。

 

为了解决这类问题，常规的做法就是在数据库之前防止一层缓存层，减少对同一数据的读取操作，以缓解对资源的竞争。这样处理之后，数据库的权重能力下降，因为缓存中的数据可能更新，那么数据库中的数据可能落后N个版本，要么直接放弃数据库中的数据，仅仅为一个持久化存在。那么这时，数据的核心转移到缓存层。缓存虽然高效但是可靠性并没有数据库那么高，而游戏玩家的数据敏感度又是非常高的，经常的数据回滚也就成为了家常便饭。这会使运营成本增加以及维护成本增加。

 

2.数据局部更新请求，游戏的逻辑往往是有众多关联的，在一个逻辑中可能修改涉及到数个表，为了防止某个操作失败，在数据库上的做法是采用事务方式进行。然后修改成功后，涉及到UI交互更新部分，又需要根据各个逻辑进行各个区别返回。

 

曾经我们尝试过一种做法，我们一次性返回所有数据，一颗巨大的用户信息树，包含着当前用户的所有信息，当客户端觉得自己需要返回什么数据的时候，从树中直接获取。为了减少数据传输量，我们在树返回上加了一些过滤规则，用于返回特定关心的数据。这样的返回模式，相对比较通用，没有了协议协商过程。UI需求的改变也相对独立。

 

看起来是完美的，但是这个对性能导致了极大的影响，这意味着每次请求，不管什么都得查出所有的东西，后来我们把树切小，分成几个部分再加上缓存。才能勉强支撑。</