游戏思考15：全区全服和分区分服的思考

文章目录

一、全区全服特点
- 1）架构图
- 2）特点
- 3）关于拆分多进程业务的作用
二、分区分服特点
- 1）架构图
- 2）特点
三、两者的对比选择
- 1）尽量选择`全区全服`的设计方式，优点如下：
- 2）两者在架构上的区别
- 3）后台压力的区别
四、随意留言

一、全区全服特点

1）架构图

2）特点

1）全区全服就只有一个DB
2）全区全服没有分区的概念，但它会有一个中心通信模块，并且整个大区在逻辑上只有一个DB
3）全区全服画出了很多业务进程

3）关于拆分多进程业务的作用

多进程当业务进程的必要性

二、分区分服特点

1）架构图

2）特点

1）分区分服的每个服都有独立的DB
2）分区分服模型一般在前端会有一个导航模块，用于区服选择
3）区与区之间如果需要通信的话，往往会使用跨服模块,对于一些需要跨服的功能，比如包含所有区的排行榜，可能还会为此增加一个公共DB(或直接存在对应服务器的内存上)。
4）从业务逻辑来看，分区分服架构里每个区只画了一个「World」
5）分区分服架构下，大家认为每个区玩家数量比较少，也有可能受限于开发时间、开发资源、技术储备等原因，没有把业务逻辑拆分得足够细，因此一般只有一个「World」，或者把游戏逻辑放在少数几个进程当中。
6）分区分服中单机容量可能受限，我们建议要适当考虑平行扩容相关的设计。像刚才说的单个「world」做平行扩容比较困难，是不是可以把核心逻辑拆分出来，也做成单个进程做单种业务的服务器
7）全区全服可以共享机器。我们知道，游戏后台会有很多进程，但每个进程的资源消耗其实不一样。而我们虽然会有很多区，但做运营活动时，每个区参与的用户数量可能会有所区别。如果采用全区全服的方式，我们就可以共享机器资源(会导致对资源调度、动态扩缩容和容灾备份的要求较高)

三、两者的对比选择

1）尽量选择`全区全服`的设计方式，优点如下：

①后续运营运维成本会比较低，因为它物理上只有一个环境，我们投入的运维人力更可控。
②全区全服可以共享机器。我们知道，游戏后台会有很多进程，但每个进程的资源消耗其实不一样。而我们虽然会有很多区，但做运营活动时，每个区参与的用户数量可能会有所区别。如果采用全区全服的方式，我们就可以共享机器资源
缺点：

这也会导致对资源调度、动态扩缩容和容灾备份的要求较高。

2）两者在架构上的区别

（1）存储方式的不同，导致需要在DB层做区分：全区全服就只有一个DB，但是分区分服的每个服都有独立的DB。
（2）游戏类型的不同，导致数据互通性不同；逻辑服务器页游必要作区分，比如各个平台需要独立运营，独立结算，开服活动只能针对特定服等等；
（3）单服承载的玩家数量级不同，导致架构上调整：全区全服所有玩家在一个服，分区分服玩家分摊在各个不同服，单服玩家数量不在一个级别，导致架构上的考量不同。

3）后台压力的区别

（1）DB层承载压力不同：分区分服DB承载单服压力，一般游戏单服PCU是千级，甚至百级，DB读写压力小，采用MySQL基本满足要求；全区全服DB承载所有玩家，PCU达到百万级别，读写压力大，单一的MySQL不能满足读写压力，需要因为读写并发高的DB组件，比如互娱的Tcaplus，TEG的CMem等等。
（2）平滑扩容：全区全服的扩容是因为整个游戏后台，在外网不停机扩容中，需要考虑扩容对整个后台的影响，而分区分服因为面临扩容机会少，有开服情况，也是独立的新建整个服，对其他服基本无影响；
（3）容灾方面：全区全服在某个服务器进程出现问题时，该模块的压力可能会偏向同等功能的其他进程，需要处理雪崩情况，避免影响全服。而分区分服因为天然的服与服之间的隔离性，在这一块压力小很多；

四、随意留言

有的腾讯游戏会利用tredis去做全区全服，redis的读写速度如果磁盘是500MB/s，真正的读写速度能达到480-490MB/s，但是之后一段时间的存储io写磁盘的卡顿，会掉到50-80MB/s，这样的速度才能满足单DB对于全区全服服务器的要求，但是普通小公司就没有tredis这种随时宕机都能恢复数据的平台工具，一般都会采用mysql去存，而mysql集群的存储速度也会控制在500MB/s，需要做成协程配合进程的方式，如果不能改成异步协程链接mysql，那就需要做成多进程连接mysql或开线程池连接mysql的方式