游戏服务器端所完成的事四.doc

游戏服务端所完成的事情（四） 游戏世界状态的维护方式 2.1数据服务的定位 　　游戏世界的状态可以简单分为两个部分，一部分是需要存档的，比如玩家数据；一部分是不需要存档的，比如场景状态。 　　对于访问较频繁的部分，比如场景状态，会维护成纯内存数据；对于访问较不频繁的部分，比如玩家存档，就可以考虑维护在第三方。这个第三方，就是数据服务。 　　数据服务与之前所提到的场景服务、IM服务等都属于应用层的概念。数据服务通常也会依赖于一种基础设施抽象，那就是缓存。 　　传统MMO架构中，数据服务的概念非常模糊。 　　我们还是先通过回顾发展历史的形式来厘清数据服务的定义。回到场景进程的发展阶段，玩家状态是内存中的数据，但是服务器不会一直开着，因此就有了存盘（文件或db）需求。但是随着业务变复杂，存盘逻辑需要数据层暴露越来越多的存储API细节，非常难扩展。因此发展出了Db代理进程，场景进程直接将存档推给Db代理进程，由Db代理进程定期存盘。　　这样，存储API的细节在Db代理进程内部闭合，游戏逻辑无须再关注。场景进程只需要通过协议封包或者RPC的形式与Db代理进程交互，其他的就不用管了。　　Db代理进程由于是定期存盘，因此它相当于维护了玩家存档的缓存。这个时候，Db代理进程就具有了数据服务的雏形。　　跟之前的讨论一样，我在这里又要开始批判一番了。　　 　　很多团队至今，新立项的项目都仍然采用这种Db代理进程。虽然确实可以用来满足一定程度的需求，但是，存在几个致命问题。 第一，Db代理进程让整个团队的代码复用级别保持在copy-paste层面。玩家存档一定是项目特定的，而采用Db代理进程的团队，通常并不会将Db代理进程设计成普适、通用的，毕竟对于他们来说，Db代理进程是场景进程和存盘之间的唯一中间层。举个例子，Db代理进程提供一个LoadPlayer的RPC接口，那么，接口实现就一定是具体游戏相关的。 第二，Db代理进程严重耦合了两个概念：一个是面向游戏逻辑的存储API；一个是数据缓存。数据缓存本质上是一种新的基础设施抽象，kv发展了这么多年，已经涌现出无数高度成熟的工业级缓存基础设施，居然还有新立项游戏对此后知后觉。殊不知，自己对Db代理进程再怎么做扩展，也不过是在feature set上逐渐接近成熟的KV，但是在可用性上就是玩具和工业级生产资料的差距。举个最简单的例子，有多少团队的Db代理进程能提供一个规范化的容忍多少秒掉线的保证？ 第三，Db代理进程在分区分服架构下通常是一区一个的，一个很重要的原因就是Db代理进程通常是自己YY写出来的，很少能够解决扩容问题。如果多服共用一个Db代理进程，全局单点给系统增加不稳定性的问题暂且按下不表，负载早就撑爆了。但是只是负责缓存玩家存档以及将存档存盘，这跟之前讨论过的全局IM服务定位非常类似，又有什么必要分区分服？ 　　我们可以构建一个数据服务解决这些问题。至于依赖的具体缓存基础设施，我之后会以redis为例。 　　redis相比于传统的KV比如memcache、tc，具有不同的设计理念，redis的定位是一种数据结构服务器。游戏服务端开发可以拿redis当缓存用，也可以直接当一个数据库用。 　　数据服务首先要解决的就是玩家存档问题。redis作为一个高性能缓存基础设施，可以满足逻辑层的存档需求。同时还可以实现额外的落地服务，比如将redis中的数据定期存回mysql。之所以这样做，一方面是因为redis的定位是高性能缓存设施，那就不希望它被rdb、aofrewrite机制拖慢表现，或者卡IO；另一方面是对于一些数据分析系统，用SQL来描述数据查询需求更合适，如果只用redis，还得单独开发查询工具，得不偿失。 　　数据服务其次要解决的问题是可以做到服务级别的复用。这一点我们可以借助企业应用开发中的ORM来设计一套对象-kv-关系映射。也就是数据服务是统一的，而不同的业务可以用不同的数据结构描述自己的领域模型，然后数据服务的配套工具会自动生成数据访问层API、redis中cache关系以及mysql中的table schema。也就是说，同样的数据服务，我在项目A中引用并定义了Player结构，就会自动生成LoadPlayer的API；在项目B中定义User同理生成LoadUser的API。 　　 　　这两个问题是比较容易解决的，最关键的还是一个思路的转换。 　　下面看一种non-trivial的实现。Phial中的DataAccess部分，Phial的Model代码生成器。 　　实际上，数据服务除去缓存基础设施的部分，都属于外围机制。在有些设计中，我们可以看到还是存在缓存服务与逻辑服务的中间层。这种中间层的单点问题很容易解决——只要不同的逻辑服务访问不同的中间层节点即可。中间层的意义通常是