原文地址-Mason'sBlog：http://www.bugclosed.com/post/12背景在游戏行业这几年，出现了各种Rolling服务器游戏，包括页游、手游、H5游戏等。滚动服务器游戏和大服务器游戏的区别在于同时玩的玩家数量。大型服务器游戏有很多用户一起玩，甚至有数千万玩家。滚服游戏一般都有一个游戏在线限制，比如3000，当达到限制后，会开启一套新的服务器，引导用户进入新的区域。滚动服务器模式是由游戏类型、技术架构、急功近利的赚钱策略等因素决定的。大型服务器游戏包括大多数端到端游戏，以及像COC这样的游戏。另外，虽然英雄联盟、王者荣耀等游戏也有分服结构，但这并不是我理解的“滚服游戏”。首先，虽然他们分服了，但是每个服的上限都可以高达几十万，他们不会有频繁的服务器合并。滚服游戏更多的是通过游戏策略来设计，鼓励玩家花钱走捷径来透支游戏生命周期，甚至在几天内称霸一个服务器。结果，其他玩家无法赶上。就算花钱赶上，性价比也极低。最好进入一个新的服务器并重新开始。这就导致了新服一开，玩家们就蜂拥而至，争先恐后的升级升级装备，以求尽快登上排行榜的前列。如果你努力了，发现你落后了，你可能要等下一个新服务器了。这也导致了新服的暴增，老服逐渐变成人口枯槁的村服，甚至是无人的死服。为了节省服务器带宽资源，让剩下的少数玩家可以玩，需要经常进行合服，将几个不相关的服务器玩家合并到一个服务器；这开启了另一波玩家的比拼和收获。上面提到的服务器合并的两种模式是滚动服务器和大服务器。无论是哪种模式，都该合并服务器了。需要将多个服务器的游戏数据合并在一起。无论数据库使用mysql、redis还是mongodb，数据库表的合并都需要在合并多台服务器的数据后不冲突不遗漏的兼容性问题。比如mysql在合并表的时候需要保证主键不冲突。如果商家有昵称不重复的设置，也要保证昵称不重复。有时合并时需要删除僵尸数据。这时候需要注意被删除数据之间的逻辑关系是否也被清除了，以免造成数据不一致。残留关系。单服务器架构业务模型将在一定程度上决定技术选择。在滚动服务器模型中，游戏的在线玩家数量比较低，通常单进程架构就足以支持。所谓单服务器架构，并不一定是整个后台只有一个服务器进程，可能还有其他辅助进程，但主要的游戏逻辑只会有一个进程。同时该架构不支持扩展游戏进程，达到进程或物理服务器的上限，即从运营的角度，重启服务器，引导新玩家进入新区域。单机架构可以简单理解为如下架构模型：从图中可以看出，每组服务器都有自己独立的游戏进程和数据库，不同服务器之间的用户是物理连接的。孤立。这种架构的优点是简单易开发，各服务器独立隔离。如果需要停止一组服务器进行调整或停机，不会影响其他服务器。劣势还来自于单台服务器的独立部署。每次开新服，都要重新部署整个数据库和游戏服务的环境。合并服务器时，需要对数据库进行物理合并和迁移。单机架构下的服务器合并，需要对物理数据库表进行硬合并，需要注意主键字段是否冲突。防止主键冲突的方法有两种：合并服务器时，修改所有的主键，尤其是uid，保证它们来自不同的空间。设计之初就考虑了服务器合并的问题，这样当数据分配了唯一的uid时，可以为每个服务器切分，从一开始就保证每个服务器的主键uid不会冲突。服务器合并的步骤和操作一般比较固定，成熟后可以针对自己特定的业务模型和表结构编写脚本统一处理。大型服务器架构大型服务器架构不同于单机架构，它可以承载更多的在线玩家，同时也具有一定的可扩展性。在一定程度上，可以通过不断部署新的服务器来扩展在线容量。在滚动服务器模式的游戏中，也可以采用大服务器的设计思路和架构，大大方便了运维管理和服务器集成。结构图如下：当然，原理图和端游的分布式架构图类似，但是也有区别，因为这里的业务场景是在滚动服务器游戏中使用的。本架构为原理示意图，并非线上运行架构。不同的开发人员会有不同的具体想法和设计偏好。比如有类似的朋友、工会等就不一一列举了。这里只分析原理解释。从图中可以看出有很多不同的角色，分别解释如下：数据库，整个架构只有一个DB，所有的数据都集中存储；DBServer，对数据库的所有操作都通过DBServer进行，保证业务逻辑与数据库设计细节分离；Account/Name，保证用户ID或昵称的唯一性，本服务全区唯一；GameServer，游戏逻辑服务，这里每个GameServer都是一个逻辑服务器，通过不断部署新的GameSever实现服务器的开通；登录、登录逻辑和路由选择赋值，这里是一键集成服务器的关键。服务器集成策略配置中，保存哪个游戏服务器游戏进程地址分配到哪个服务器，只需要调整该策略配置即可控制用户进入的GameServer进程；大服架构用户登陆流程：用户可以在客户端登陆界面选择3服入口，点击进入游戏。Login模块接收到用户进入s3的请求，从服务器合并策略配置中查询s3的GameServer入口地址，返回。客户端收到s3的GameServer地址，直接向s3发起链接请求。GameServer3处理登录请求，从DBServer获取用户信息返回给用户，没有信息则创建新角色。登录后，就进入了s3服务器。与单机架构的服务器合并不同，单机架构的服务器合并对数据的处理和迁移主要有两个原因：每个服务器的数据库处于独立的状态，需要在物理上进行融合在一起。需要进行数据库修复处理。由于这两个原因，单台服务器合并需要进行大量的数据处理、导出、复制、迁移等，增加了流程复杂度和服务器合并操作出错的可能性。从大服务器架构图可以发现，单机架构下合并服务器的两个难点自然就解决了。账户分配唯一ID，在DB中存储自然不会冲突；并且数据已经存储在库中，因此无需迁移。一键合并服务器通过上面的分解，我们可以发现现在合并服务器非常方便；无需修改和迁移数据，甚至无需停止服务器。只需要使用工具修改服务器合并策略配置库中的路由信息??，修改用户登录的游戏服务器即可。比如提供一个web修改页面，选择s1、s2、s3服务器进行合并，默认合并后gameserver1提供服务，gameserver2和gameserver3停止下架。只需要一个http请求就可以将s2和s3的gameserver地址修改为gameserver1。即合并完成。合服后用户登录流程：用户依然选择3号服务器入口登录游戏。Login模块获取到用户要进入s3服务器，查询服务器合并策略配置，获取s3服务器的服务地址，即gamesrver1，返回。用户获取到gameserver1的地址，发起链接请求，登录。
