全区分服游戏

传统意义上的游戏分区方式主要有两种：全区全服和分区分服。然而随着游戏设计的多样化发展，越来越多的分区分服游戏引入跨服的玩法、全区SNS的玩法，公司的很多游戏都基于分服架构上做了全区架构设计。本文暂且称这种架构是全区分服架构，对这种架构做设计上的探讨，试图找到一些可以通用的设计方案。

全区分服游戏

究竟什么是全区分服游戏？这类游戏有哪些特性？通常，在全区和分服上，这类游戏更侧重于后者，因为分服可以大大丰富游戏玩法，而全区玩法相对来说内容少很多。于是基于此前提，我们可以总结出以下全区分服游戏的特点：

1.      以分服玩法为主，全区玩法基于分服之上；

2.      需要全区同步的单个用户信息只占其完整数据的一小部分，否则分服意义不大；

3.      全区玩法包含跨服交互，会同时改变不同服上的用户数据。

 

数据层架构

由以上特点不难看出架构设计的主要问题在于数据层设计，跨区交互涉及到用户数据同步和一致性问题。首先是从现有的方案中做出选择，究竟用户数据是按照全区全服的方案，还是按照分区分服的方案？

图1 全局数据层

图1是全区全服的数据层架构，所有分区都读写同一份数据。此架构的优点是全局数据唯一，数据同步简单。但是在不同服写数据并发较高的情况下，容易产生数据冲突；另外对于玩法复杂的游戏来说分区需要缓存用户数据，那么缓存同步也是一个大问题。所以此架构通常适用于玩法相对不太复杂的游戏。

图2 分区数据层

图2是分区分服的数据层架构，数据按分区隔离。此架构的优点是数据不会产生写冲突，分区自己管理也方便做缓存。但是缺点也很明显，就是跨服数据同步比较难。虽然有一些缺点，但是此架构符合全区分服游戏的特点，即以分服玩法为主，这样就可以解决大部分问题，并且对于后期单个服内的玩法扩展也有很好的支持。

因此，公司一些项目选择以图2架构为基础进行扩展设计。设计的核心是引入全局服务承担跨服数据同步，根据全区分服游戏特点，将读数据和写数据分开处理，以下分别对这两方面展开讨论。

读数据方案

由于全区分服游戏中单个用户跨服同步的数据不多，可以推断出对此数据同步的实时性可以容忍一定的延迟。由此可以得出设计的大体思路是：不同分区将需要同步的那部分玩家数据上报到全局服务上，需要读时从这个全局服务拉取。

图3 读数据方案

图3是某款页游具体的读数据方案。其中AccountServer是负责同步用户数据的全局服务，每个分区通过用户改变数据的触发机制上报用户关键数据到AccountServer，AccountServer维护用户QQ号到不同分区角色数据的映射，这些映射关系和关键数据通过互娱服务TCaplus存储。AccountServer是无状态服务可以多点平行扩展。

此方案实现了每个分区读其他分区上用户的关键数据，实时性和一致性可以满足游戏玩法需求，系统复杂度很低，容灾和扩容相对较简单。

写数据方案

根据数据一致性的原则，写数据不使用全局服务存储的数据，而是直接对分区的数据进行操作。以上文所举页游的跨服PK玩法为例，用户可以直接向其他服上的好友发起挑战，挑战通过一次交互即可完成。因此，写数据设计的大体思路是不同分区之间通过一个全局路由服务进行直接交互。

图4 写数据方案

图4是该页游具体的写数据方案。其中ForwardServer是负责路由的全局服务，分区1向分区2发送挑战请求，逻辑计算在分区2完成，分区2本地写数据同时将结果返回分区1，分区1也写本地数据。

需要说明的是，为保证数据一致性，每个分区只负责写自己本区的数据，对于跨服的数据只是增量通知改变。比如分区2计算结果导致分区1上的玩家数据改变，那么分区2只将改变的那部分数据通知分区1，分区1本地处理后增量回写到玩家数据中。

此方案实现了从一个分区向其他分区发起写操作，实时性和一致性很强。由于只是写操作，分区之间直接交互并不复杂，系统复杂度很低，容灾和扩容相对较简单。

另外，对于后期复杂的多分区同时写操作，比如跨服争抢资源的玩法，该方案也支持扩展。可以将某个分区替换成一个全局逻辑服务负责计算争抢资源的逻辑，其他分区通过ForwardServer向此逻辑服务发起写数据请求。

总结

本文从数据一致性的问题出发探讨了全区分服游戏的架构设计，这也是分布式系统的一个主要问题。解决问题没有唯一的答案，但可以根据业务特性来做出针对性的设计。本着简单、实用的原则我们对全区分服游戏给出了一种读写分离的方案，读只需要满足弱同步，而写以增量更新的方式满足强同步。

 

https://gameinstitute.qq.com/community/detail/100008