Gate和MQ实现了不同的pattern集合。当然，正如之前所说，Gate本质上也是一种MQ，但是由于我们对这两种基础设施抽象的定位不同，所以在实现各自的Adaptor的时候也限定了各自支持的pattern。比如，Gate不能支持notify，MQ不能支持ask-sync。

 

　　我在示例实现中没有加入MQ对客户端组播的支持。主要原因是考虑到client是通过MQTT协议跟MQ通信，相当于组维护是client发起的。对于聊天这种的可能还好，对于其他的可能会有隐患。

引入新的问题

　　到目前为止，我们总结出了如下几种与游戏服务端有关的消息pipeline：

client -> MQ -> service

service -> MQ -> client

service -> MQ -> service

service -> MQ -> service*

　　这基本上已经能涵盖游戏中的大部分需求了，因此我们对消息流的讨论就到此为止。

 

　　接下来讨论游戏世界的状态维护。

　　维护游戏世界状态的职责同样由一种服务负责，这种服务下面称为数据服务。

　　但是数据服务所说的服务与之前所提的作为dynamic parts的Phial服务不太相同，实际上是一些基础设施抽象和Phial服务的组合。

 

　　有了数据服务，我们还可以更加明确client与service走Gate与MQ究竟有什么本质区别。

 

4 游戏世界状态的维护方式

 

4.1数据服务的定位

 

　　游戏世界的状态可以简单分为两个部分，一部分是需要存档的，比如玩家数据；一部分是不需要存档的，比如场景状态。

　　对于访问较频繁的部分，比如场景状态，会维护成纯内存数据；对于访问较不频繁的部分，比如玩家存档，就可以考虑维护在第三方。这个第三方，就是数据服务。

　　数据服务与之前所提到的场景服务、IM服务等都属于应用层的概念。数据服务通常也会依赖于一种基础设施抽象，那就是缓存。

 

4.1.1 传统架构中的数据服务

 

　　传统MMO架构中，数据服务的概念非常模糊。

　　我们还是先通过回顾发展历史的形式来厘清数据服务的定义。回到场景进程的发展阶段，玩家状态是内存中的数据，但是服务器不会一直开着，因此就有了存盘（文件或db）需求。但是随着业务变复杂，存盘逻辑需要数据层暴露越来越多的存储API细节，非常难扩展。因此发展出了Db代理进程，场景进程直接将存档推给Db代理进程，由Db代理进程定期存盘。
　　这样，存储API的细节在Db代理进程内部闭合，游戏逻辑无须再关注。场景进程只需要通过协议封包或者RPC的形式与Db代理进程交互，其他的就不用管了。
　　Db代理进程由于是定期存盘，因此它相当于维护了玩家存档的缓存。这个时候，Db代理进程就具有了数据服务的雏形。

　　跟之前的讨论一样，我在这里又要开始批判一番了。
　　

　　很多团队至今，新立项的项目都仍然采用这种Db代理进程。虽然确实可以用来满足一定程度的需求，但是，存在几个致命问题。

　　我们可以构建一个数据服务解决这些问题。至于依赖的具体缓存基础设施，我之后会以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代码生成器。

 

　　实际上，数据服务除去缓存基础设施的部分，都属于外围机制。在有些设计中，我们可以看到还是存在缓存服务与逻辑服务的中间层。这种中间层的单点问题很容易解决——只要不同的逻辑服务访问不同的中间层节点即可。中间层的意义通常是进行RPC到具体缓存协议API的转换，在我的实现中，由于已经有了数据访问API的自动生成，因此没有这种中间层存在的必要。所有需要访问数据服务的逻辑服务都可以直接通过数据访问API访问。

 

　　其中还有几点细节：

数据访问层API的调用规范与RPC的调用规范保持了统一，都是基于async/await模式。

通过数据服务对任意存档进行增加或修改都会记录一个job，由落地服务定期检查job进行落地。

引入新的问题

　　目前仍然遗留了几个问题：

redis单实例的性能确实很强悍，但是如果全区全服只开一个redis实例确实是存在问题的，这个问题需要解决。

数据服务对于传统MMO架构来说可以无缝替换掉丑陋的Db代理进程，但是，既然数据服务已经能提供抽象程度如此高的存储接口，那是否还可以应用在其他地方？

  4.1.2 无状态服务中数据服务的定位

 

定义问题

　　之前提到过，游戏世界的状态除了需要存档的玩家数据，还有一部分是不需要存档的逻辑服务的状态。

　　数据服务如果只是用来替代MMO中的Db代理进程的，那么它的全部职责就仅仅是为需要存档的数据提供服务。从更高的抽象层次来看的话，数据服务相当于是维护了client在服务端的状态。