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

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