地图负载均衡的方法、装置、设备及计算机可读存储介质与流程

本申请涉及计算机技术领域，具体而言，本申请涉及一种地图负载均衡的方法、装置、设备及计算机可读存储介质。

背景技术：

网络游戏也称在线游戏，一般指多名玩家通过电脑网络互动娱乐的电子游戏。rpg（角色扮演游戏，role-playinggame）是一种游戏类型。在游戏中，玩家扮演虚拟世界中的一个或者几个队员角色在特定场景下进行游戏。通常这类游戏都是由玩家扮演冒险者在游戏世界中漫游，而一路上的各种遭遇，则是玩家人物成长及游戏进行的重要关键所在，其中，各种遭遇例如战斗、交谈、会见重要人物等。

mmorpg（massivemultiplayeronlinerole-playinggame，大型多人在线角色扮演游戏）是网络游戏的一种；在所有角色扮演游戏中，玩家都要扮演一个虚构角色，并控制该角色的许多活动。mmorpg地图类型丰富多样，每个地图和地图之间的玩家数量和玩法特性也差异很大，因为有上述这个特点，mmorpg服务器会出现地图对应的场景进程的负载不均衡的问题；有的场景进程的负载比较高，玩家在游戏过程会出现卡顿；有的场景进程的负载很低，没有充分利用计算能力。

技术实现要素：

本申请针对现有的方式的缺点，提出一种地图负载均衡的方法、装置、电子设备及计算机可读存储介质，用以解决地图对应的场景进程的负载不均衡的问题。

第一方面，本申请提供了一种地图负载均衡的方法，包括：

获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载；

根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度；

根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，并根据各场景进程的负载进行负载均衡。

可选地，获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载，包括：

获取各场景进程分别对应的每一个地图的负载单元信息，负载单元信息包括玩家角色数量、玩家角色权重、非玩家角色数量和非玩家角色权重；

针对每一个地图，根据预计的玩家角色数量、预计的玩家角色权重、预计的非玩家角色数量和预计的非玩家角色权重，确定每一个地图的预计负载。

可选地，根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度，包括：

针对一个地图，将一个地图划分为n个格子，并根据一个地图的负载单元信息包括的玩家角色数量和格子数n，确定n个格子中每个格子的玩家角色数量；

根据一个地图中各个格子的玩家角色数量，确定一个地图的平均聚集程度，n为正整数。

可选地，根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，包括：

针对一个场景进程，根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图的负载；

计算一个场景进程对应的每一个地图的负载之间的和，得到一个场景进程的负载，至少一个地图包括每一个地图。

可选地，根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图的负载，包括：

针对一个地图，根据一个地图的平均聚集程度和预设参数，得到加权后的平均聚集程度；

根据一个地图的负载单元信息包括的玩家角色数量、玩家角色权重、非玩家角色数量和非玩家角色权重，确定一个地图的实际负载；

根据加权后的平均聚集程度和实际负载，得到加权后的实际负载；

根据加权后的实际负载和一个地图的预计负载，确定一个地图的负载。

可选地，根据加权后的实际负载和预计负载，确定一个地图的负载，包括：

将加权后的实际负载和一个地图的预计负载中的最大值确定为一个地图的负载。

可选地，根据各场景进程的负载进行负载均衡，包括：

根据各场景进程的负载，确定各场景进程中负载最小的场景进程；

指示负载最小的场景进程进行地图创建。

可选地，在获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和预计负载之前，还包括：

根据预设的时间阈值和预设的过载阈值，筛除不满足时间阈值和过载阈值中至少一项的场景进程。

可选地，根据预设的时间阈值和预设的过载阈值，筛除不满足时间阈值和过载阈值中至少一项的场景进程，包括以下至少一项：

当任一场景进程在时间阈值内没有上报数据，则确定任一场景进程不满足所述时间阈值，并将任一场景进程筛除；

当任一场景进程对应的处理器使用率和内存使用率中的至少一项大于过载阈值，则确定任一场景进程不满足过载阈值，并将任一场景进程筛除。

第二方面，本申请提供了一种地图负载均衡的装置，包括：

第一处理模块，用于获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载；

第二处理模块，用于根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度；

第三处理模块，用于根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，并根据各场景进程的负载进行负载均衡。

第三方面，本申请提供了一种电子设备，包括：处理器、存储器和总线；

总线，用于连接处理器和存储器；

存储器，用于存储操作指令；

处理器，用于通过调用操作指令，执行本申请第一方面的地图负载均衡的方法。

第四方面，本申请提供了一种计算机可读存储介质，存储有计算机程序，计算机程序被用于执行本申请第一方面的地图负载均衡的方法。

本申请实施例提供的技术方案，至少具有如下有益效果：

获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载；根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度；根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，并根据各场景进程的负载进行负载均衡。如此，通过地图的平均聚集程度考虑了不同玩法之间的差异，以及不同玩家行为之间的差异，从而可以准确评估地图对应的场景进程的负载，使场景进程的负载更加均衡；同时可以合理的预留负载，提高资源利用率，给玩家带来更加流畅的游戏体验。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的系统架构的示意图；

图2为本申请实施例提供的一种地图负载均衡的方法的流程示意图；

图3为本申请实施例提供的一种地图负载均衡的示意图；

图4为本申请实施例提供的一种地图负载均衡的示意图；

图5为本申请实施例提供的一种地图负载均衡的示意图；

图6为本申请实施例提供的一种地图负载均衡的示意图；

图7为本申请实施例提供的一种地图负载均衡的示意图；

图8为本申请实施例提供的另一种地图负载均衡的方法的流程示意图；

图9为本申请实施例提供的处理器cpu使用率标准差的示意图；

图10为本申请实施例提供的下行流量标准差的示意图；

图11为本申请实施例提供的一种地图负载均衡的装置的结构示意图；

图12为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使得本申请的发明目的、特征、优点能够更加的明显和易懂，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而非全部实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面详细描述本申请的实施例，该实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

云技术（cloudtechnology）是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术（cloudtechnology）基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

云游戏（cloudgaming）又可称为游戏点播（gamingondemand），是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备（thinclient）能运行高品质游戏。在云游戏场景下，游戏并不在玩家游戏终端，而是在云端服务器中运行，并由云端服务器将游戏场景渲染为视频音频流，通过网络传输给玩家游戏终端。玩家游戏终端无需拥有强大的图形运算与数据处理能力，仅需拥有基本的流媒体播放能力与获取玩家输入指令并发送给云端服务器的能力即可。

为了更好的理解及说明本申请实施例的方案，下面对本申请实施例中所涉及到的一些技术用语进行简单说明。

副本：副本为游戏副本，游戏副本是可以让你和队友们在一个私人区域，不受他人干扰地进行探索、冒险或完成任务的场所，不是你的队友就无法进入你所在的这个私人区域。

地图：地图是游戏内虚拟的一个场景，玩家在地图内进行游戏体验。

actor：游戏中玩家控制的角色。

npc：npc是non-playercharacter的缩写，是游戏中一种角色类型，意思是非玩家角色。

网络游戏客户端（gameclient）：网络游戏客户端是指与网络游戏服务器相对应，为客户提供本地服务的程序。一般安装在普通的用户机上，需要与服务端互相配合运行。

网络游戏服务器（gameserver）：网络游戏服务器是指与网络游戏客户端相对应，安装在idc（internetdatacenter，互联网数据中心）中，为网络游戏客户端提供数据转发与逻辑处理服务的软件程序。由于安装在玩家机器上的客户端容易被破解而被利用作弊，所以在网络游戏中，复杂与关键的逻辑，都需要在网络游戏服务器上进行计算。

下面以具体的实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

本申请实施例提供的一种系统架构的示意图如图1所示，该系统架构包括：网络游戏客户端110和网络游戏服务器120。网络游戏服务器120可以为云端服务器、mmorpg服务器架构等。为了营造大世界环境，支持更多的玩家同时在线体验游戏，即支持更多的网络游戏客户端110；mmorpg服务器架构通常会分为世界world进程和场景scene进程；其中，世界world进程负责角色登录、地图创建、地图负载均衡等功能，场景scene进程负责承载具体的地图。

本申请实施例中提供了一种地图负载均衡的方法，该方法的流程示意图如图2所示，该方法包括：

s101，获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载。

可选地，负载单元信息包括玩家角色数量、玩家角色权重、非玩家角色数量和非玩家角色权重。

可选地，玩家角色数量包括战斗的玩家角色数量和非战斗的玩家角色数量中的至少一项；玩家角色权重包括战斗的玩家角色权重和非战斗的玩家角色权重中的至少一项；非玩家角色数量包括战斗的非玩家角色数量和非战斗的非玩家角色数量；非玩家角色权重包括战斗的非玩家角色权重和非战斗的非玩家角色权重。

举例说明，玩家角色为actor，非玩家角色为npc。

需要说明的是，场景进程承载的最小单位是地图实例，场景进程是容器，容器的负载由容器承载的地图所决定；地图的负载由地图的负载单元信息来决定。每张地图都有预计负载，预计负载可以预先占用，这样可以解决压力滞后的问题；其中，压力滞后是指一些主线地图上玩家角色数量可能刚开始比较少，但是随着玩法或者活动的开启，会有大量的玩家角色进入这些地图，导致压力变的很大；例如，一个地图预计可以支撑1000个玩家，但是平时该地图实际玩家角色的数量比较少，压力比较小，到玩家角色活跃高峰期这个地图才会有1000名玩家角色，压力有滞后性。

可选地，获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载，包括：

获取各场景进程分别对应的每一个地图的负载单元信息，负载单元信息包括玩家角色数量、玩家角色权重、非玩家角色数量和非玩家角色权重；

针对每一个地图，根据预计的玩家角色数量、预计的玩家角色权重、预计的非玩家角色数量和预计的非玩家角色权重，确定每一个地图的预计负载。

可选地，预计的玩家角色数量包括预计的战斗的玩家角色数量和预计的非战斗的玩家角色数量中的至少一项；预计的玩家角色权重包括预计的战斗的玩家角色权重和预计的非战斗的玩家角色权重中的至少一项；预计的非玩家角色数量包括预计的战斗的非玩家角色数量和预计的非战斗的非玩家角色数量；预计的非玩家角色权重包括预计的战斗的非玩家角色权重和预计的非战斗的非玩家角色权重。

可选地，每一个地图的预计负载payload可以通过公式（1）得到，公式（1）如下所示：

预计负载payload=预计的非战斗的actor数量非战斗的actor权重+预计的战斗的actor数量战斗的actor权重+预计的非战斗的npc数量非战斗的npc权重+预计的战斗的npc数量战斗的npc权重公式（1）

其中，actor为玩家角色，npc为非玩家角色，非战斗的actor权重与预计的非战斗的actor权重相同，战斗的actor权重与预计的战斗的actor权重相同，非战斗的npc权重与预计的非战斗的npc权重相同，战斗的npc权重与预计的战斗的npc权重相同。

s102，根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度。

可选地，一个场景进程对应m个地图，根据m个地图中的每个地图的负载单元信息，确定每个地图的平均聚集程度，m为正整数。

可选地，根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度，包括步骤a1-a2：

步骤a1，针对一个地图，将一个地图划分为n个格子，并根据一个地图的负载单元信息包括的玩家角色数量和格子数n，确定n个格子中每个格子的玩家角色数量。

举例说明，如图3所示，将地图a划分为16个格子，地图a的16个格子中的每个格子内都存在玩家角色，其中，n为16。地图a的负载单元信息包括的玩家角色数量为204，n为16，根据玩家角色数量和n，场景进程会实时统计地图a的16个格子中的每个格子内的玩家角色数量，如图4所示，统计得到地图a的16个格子中的每个格子内的玩家角色数量分别为：8、16、12、9、12、31、29、12、8、25、21、11、2、9、5和3。

举例说明，如图5所示，将地图b划分为16个格子，地图a的16个格子中的15个格子内都存在玩家角色，有一个格子内不存在玩家角色其中，n为16。地图b的负载单元信息包括的玩家角色数量为196，n为16，根据玩家角色数量和n，场景进程会实时统计地图a的16个格子中的每个格子内的玩家角色数量，如图6所示，统计得到地图b的16个格子中的每个格子内的玩家角色数量分别为：0、16、12、9、12、31、29、12、8、25、21、11、2、9、5和3。

步骤a2，根据一个地图中各个格子的玩家角色数量，确定一个地图的平均聚集程度，n为正整数。

举例说明，如图4所示，将地图a的16个格子中的每个格子内的玩家角色数量之间求和，得到16个格子中的玩家角色总数量204。将玩家角色总数量与存在玩家角色的格子的总数16之间相除，得到16个格子中的每个格子内的平均玩家数量，即平均聚集程度。

举例说明，如图5所示，将地图a的16个格子中的每个格子内的玩家角色数量之间求和，得到16个格子中的玩家角色总数量196。将玩家角色总数量与存在玩家角色的格子的总数15之间相除，得到15个格子中的每个格子内的平均玩家数量，即平均聚集程度。

需要说明的是，不同玩法下玩家的聚集程度不一样，从而玩法计算开销也不一样，会导致不同玩法之间实际开销差距很大。如图7所示，地图为副本地图，承载15个副本地图的场景scene进程，这15个副本地图中的每个副本地图都有20人，即20个玩家角色；副本地图例如挑战地图、剧情地图等。承载1个副本地图的场景scene进程，这个副本地图有300人，即300个玩家角色；副本地图例如帮派战斗地图。这两个场景进程的玩家角色数量相同，但实际开销差距很大。通过平均聚集程度表征不同玩法下玩家的聚集程度，从而可以准确评估实际开销。

s103，根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，并根据各场景进程的负载进行负载均衡。

可选地，一个场景进程对应s个地图，根据s个地图中的每一个地图的平均聚集程度、每一个地图的负载单元信息和每一个地图的预计负载，确定每一个地图对应的场景进程的负载，其中，s为正整数。

可选地，根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，包括步骤b1-b2：

步骤b1，针对一个场景进程，根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图的负载。

可选地，一个场景进程对应s个地图，根据s个地图中的每一个地图的平均聚集程度、每一个地图的负载单元信息和每一个地图的预计负载，确定每一个地图的负载，其中，s为正整数。

可选地，根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图的负载，包括步骤c1-c4：

步骤c1，针对一个地图，根据一个地图的平均聚集程度和预设参数，得到加权后的平均聚集程度。

可选地，一个地图的平均聚集程度为bc_average，加权后的平均聚集程度为bc_ratio，预设参数为bc_threshold_factor，加权后的平均聚集程度为bc_ratio的计算公式（2）如下所示：

公式（2）

其中，预设参数bc_threshold_factor为一个可调整参数，例如预设参数取值为50。

步骤c2，根据一个地图的负载单元信息包括的玩家角色数量、玩家角色权重、非玩家角色数量和非玩家角色权重，确定一个地图的实际负载。

可选地，一个地图的实际负载payload可以通过公式（3）得到，公式（3）如下所示：

实际负载payload=非战斗的actor数量非战斗的actor权重+战斗的actor数量战斗的actor权重+非战斗的npc数量非战斗的npc权重+战斗的npc数量战斗的npc权重

公式（3）

其中，actor为玩家角色，npc为非玩家角色。玩家角色数量包括战斗的玩家角色数量和非战斗的玩家角色数量中的至少一项；玩家角色权重包括战斗的玩家角色权重和非战斗的玩家角色权重中的至少一项；非玩家角色数量包括战斗的非玩家角色数量和非战斗的非玩家角色数量；非玩家角色权重包括战斗的非玩家角色权重和非战斗的非玩家角色权重。

步骤c3，根据加权后的平均聚集程度和实际负载，得到加权后的实际负载。

可选地，加权后的平均聚集程度为bc_ratio，加权后的实际负载可以通过公式（4）得到，公式（4）如下所示：

加权后的实际负载payload=实际负载payload(1+bc_ratio)(1+bc_ratio)公式（4）

需要说明的是，世界world进程在计算地图负载时，实际计算开销是随着加权后的平均聚集程度增加而呈平方增长，因此，加权后的实际负载payload也是随着加权后的平均聚集程度增加而呈平方增长。

步骤c4，根据加权后的实际负载和一个地图的预计负载，确定一个地图的负载。

可选地，根据一个地图的加权后的实际负载payload和该地图的预计负载payload，确定该地图的负载payload。

可选地，根据加权后的实际负载和预计负载，确定一个地图的负载，包括：

将加权后的实际负载和一个地图的预计负载中的最大值确定为一个地图的负载。

举例说明，一个地图的负载的计算公式（5）如下所示：

地图的负载payload=max（加权后的实际负载payload，预计负载payload）公式（5）

步骤b2，计算一个场景进程对应的每一个地图的负载之间的和，得到一个场景进程的负载，至少一个地图包括每一个地图。

可选地，场景进程的负载就是场景进程对应的全部地图的负载之和。

可选地，根据各场景进程的负载进行负载均衡，包括：

根据各场景进程的负载，确定各场景进程中负载最小的场景进程；

指示负载最小的场景进程进行地图创建。

可选地，世界world进程在创建地图后选择一个负载最小的场景进程，并指示该负载最小的场景进程进行地图创建，就可以达到负载均衡的目标。

可选地，在步骤s101获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和预计负载之前，还包括：

根据预设的时间阈值和预设的过载阈值，筛除不满足时间阈值和过载阈值中至少一项的场景进程。

可选地，场景scene进程定时向世界world进程上报数据，例如，场景scene进程每10秒向世界world进程上报一次数据，其中，数据包括战斗的玩家角色数量、非战斗的玩家角色数量、战斗的非玩家角色数量、非战斗的非玩家角色数量、场景进程对应的处理器使用率、玩家角色的内存使用率、非玩家角色的内存使用率等。在世界world进程创建地图时，世界world进程根据每个场景scene进程上报的数据、预设的时间阈值和预设的过载阈值，筛除不满足时间阈值和过载阈值中至少一项的场景进程；例如，预设的时间阈值为2分钟，过载阈值为80%。

可选地，根据预设的时间阈值和预设的过载阈值，筛除不满足时间阈值和过载阈值中至少一项的场景进程，包括以下至少一项：

当任一场景进程在时间阈值内没有上报数据，则确定任一场景进程不满足所述时间阈值，并将任一场景进程筛除；

当任一场景进程对应的处理器使用率和内存使用率中的至少一项大于过载阈值，则确定任一场景进程不满足过载阈值，并将任一场景进程筛除。

举例说明，预设的时间阈值为2分钟，过载阈值为80%。当一个场景进程在时间阈值2分钟内没有上报数据给世界world进程，则确定该场景进程不满足所述时间阈值，并将该场景进程筛除。当一个场景进程对应的处理器使用率和内存使用率中的至少一项大于过载阈值80%，则确定该场景进程不满足过载阈值，并将该场景进程筛除。

本申请实施例中，通过地图的平均聚集程度考虑了不同玩法之间的差异，以及不同玩家行为之间的差异，从而可以准确评估地图对应的场景进程的负载，使场景进程的负载更加均衡；同时可以合理的预留负载，提高资源利用率，给玩家带来更加流畅的游戏体验。

本申请实施例中提供了一种地图负载均衡的方法，该方法的流程示意图如图8所示，该方法包括：

s201，多个场景scene进程定时向世界world进程上报数据。

可选地，多个场景进程包括承载多个地图的场景进程、承载1个地图的场景进程等；地图的类型可以包括挑战地图、剧情地图、帮派战斗地图等。

可选地，数据包括战斗的玩家角色数量、非战斗的玩家角色数量、战斗的非玩家角色数量、非战斗的非玩家角色数量、场景进程对应的处理器使用率、玩家角色的内存使用率、非玩家角色的内存使用率等。

s202，世界world进程根据预设的时间阈值和预设的过载阈值，筛除不满足时间阈值和过载阈值中至少一项的场景进程。

可选地，预设的时间阈值为1分钟，过载阈值为70%。当一个场景进程在时间阈值1分钟内没有上报数据给世界world进程，则确定该场景进程不满足所述时间阈值，并将该场景进程筛除。当一个场景进程对应的处理器使用率和内存使用率中的至少一项大于过载阈值70%，则确定该场景进程不满足过载阈值，并将该场景进程筛除。

s203，获取场景进程对应的每一个地图的负载单元信息。

可选地，根据场景进程向世界world进程上报的数据，获取该场景进程对应的每一个地图的负载单元信息。场景进程同时满足时间阈值和过载阈值。

s204，针对场景进程对应的每一个地图，根据预计的玩家角色数量、预计的玩家角色权重、预计的非玩家角色数量和预计的非玩家角色权重，确定每一个地图的预计负载。

可选地，玩家角色为actor，非玩家角色为npc；通过每一个地图的预计负载可以合理的预留负载，提高资源利用率，给玩家带来更加流畅的游戏体验。

s205，针对每一个地图，将每一个地图划分为多个格子，根据多个格子中各个格子的玩家角色数量，确定每一个地图的平均聚集程度。

可选地，场景进程向世界world进程上报每一个地图的平均聚集程度。

s206，针对每一个地图，根据每一个地图的平均聚集程度和预设参数，得到每一个地图的加权后的平均聚集程度。

可选地，预设参数为一个可调整参数，例如预设参数取值为45。

s207，根据每一个地图的负载单元信息包括的玩家角色数量、玩家角色权重、非玩家角色数量和非玩家角色权重，确定每一个地图的实际负载。

可选地，玩家角色为actor，非玩家角色为npc；玩家角色数量包括战斗的玩家角色数量和非战斗的玩家角色数量中的至少一项；玩家角色权重包括战斗的玩家角色权重和非战斗的玩家角色权重中的至少一项；非玩家角色数量包括战斗的非玩家角色数量和非战斗的非玩家角色数量；非玩家角色权重包括战斗的非玩家角色权重和非战斗的非玩家角色权重。

s208，根据每一个地图的加权后的平均聚集程度和每一个地图的实际负载，得到每一个地图的加权后的实际负载。

s209，将每一个地图的加权后的实际负载和每一个地图的预计负载中的最大值确定为每一个地图的负载。

s210，计算每一个场景进程对应的每一个地图的负载之间的和，得到每一个场景进程的负载。

s211，世界world进程指示负载最小的场景进程进行地图创建。

本申请实施例中，世界world进程在多个场景进程中先筛除掉不满足时间阈值和过载阈值中至少一项的场景进程，得到同时满足时间阈值和过载阈值的多个场景进程，通过每个场景进程中每个地图的平均聚集程度考虑了不同玩法之间的差异，以及不同玩家行为之间的差异，从而可以准确评估地图对应的场景进程的负载，并指示负载最小的场景进程进行地图创建，从而使场景进程的负载更加均衡；通过每一个地图的预计负载可以合理的预留负载，提高资源利用率，给玩家带来更加流畅的游戏体验。

为了更好的理解本申请实施例所提供的方法，下面结合具体应用场景的示例对本申请实施例的方案进行进一步说明。

本申请实施例所提供的方法应用于云游戏，例如mmorpg。mmorpg的游戏玩法类型丰富多样，例如副本玩法、大型多人对抗玩法、任务玩法、装备玩法、竞技玩法等。不同玩法之间导致的场景进程的负载差异很大；在同一个玩法下，不同玩家角色之间的行为也有差异，例如有的玩家角色在移动，有的玩家角色在战斗，不同玩家角色之间的行为差异导致场景进程的负载也不一样。针对mmorpg的游戏玩法导致的场景进程的负载差异，本申请实施例所提供的方法使场景进程的负载更加均衡，资源得到高效利用；同时对于玩家来说，可以有更好的游戏体验，避免卡顿等问题。

举例说明，场景进程之间的处理器cpu使用率标准差如图9所示，图9中的优化前表示传统方案，图9中的优化后表示本申请方案；使用本申请方案，处理器cpu使用率标准差与优化前相比有明显下降，说明本申请实施例所提供的方法使场景进程的负载更加均衡。

举例说明，场景进程之间的下行流量标准差如图10所示，图10中的优化前表示传统方案，图9中的优化后表示本申请方案；使用本申请方案，下行流量标准差与优化前相比有明显下降，说明本申请实施例所提供的方法使场景进程的负载更加均衡。

基于相同的发明构思，本申请实施例还提供了一种地图负载均衡的装置，该装置的结构示意图如图11所示，地图负载均衡的装置30，包括第一处理模块301、第二处理模块302和第三处理模块303。

第一处理模块301，用于获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载；

第二处理模块302，用于根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度；

第三处理模块303，用于根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，并根据各场景进程的负载进行负载均衡。

可选地，第一处理模块301，具体用于获取各场景进程分别对应的每一个地图的负载单元信息，负载单元信息包括玩家角色数量、玩家角色权重、非玩家角色数量和非玩家角色权重；针对每一个地图，根据预计的玩家角色数量、预计的玩家角色权重、预计的非玩家角色数量和预计的非玩家角色权重，确定每一个地图的预计负载。

可选地，第二处理模块302，具体用于针对一个地图，将一个地图划分为n个格子，并根据一个地图的负载单元信息包括的玩家角色数量和格子数n，确定n个格子中每个格子的玩家角色数量；根据一个地图中各个格子的玩家角色数量，确定一个地图的平均聚集程度，n为正整数。

可选地，第三处理模块303，具体用于针对一个场景进程，根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图的负载；计算一个场景进程对应的每一个地图的负载之间的和，得到一个场景进程的负载，至少一个地图包括每一个地图。

可选地，第三处理模块303，具体用于针对一个地图，根据一个地图的平均聚集程度和预设参数，得到加权后的平均聚集程度；根据一个地图的负载单元信息包括的玩家角色数量、玩家角色权重、非玩家角色数量和非玩家角色权重，确定一个地图的实际负载；根据加权后的平均聚集程度和实际负载，得到加权后的实际负载；根据加权后的实际负载和一个地图的预计负载，确定一个地图的负载。

可选地，第三处理模块303，具体用于将加权后的实际负载和一个地图的预计负载中的最大值确定为一个地图的负载。

可选地，第三处理模块303，具体用于根据各场景进程的负载，确定各场景进程中负载最小的场景进程；指示负载最小的场景进程进行地图创建。

可选地，第一处理模块301在获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和预计负载之前，第一处理模块301，还用于根据预设的时间阈值和预设的过载阈值，筛除不满足时间阈值和过载阈值中至少一项的场景进程。

可选地，第一处理模块301，具体用于当任一场景进程在时间阈值内没有上报数据，则确定任一场景进程不满足所述时间阈值，并将任一场景进程筛除；当任一场景进程对应的处理器使用率和内存使用率中的至少一项大于过载阈值，则确定任一场景进程不满足过载阈值，并将任一场景进程筛除。

应用本申请实施例，至少具有如下有益效果：

获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载；根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度；根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，并根据各场景进程的负载进行负载均衡。如此，通过地图的平均聚集程度考虑了不同玩法之间的差异，以及不同玩家行为之间的差异，从而可以准确评估地图对应的场景进程的负载，使场景进程的负载更加均衡；同时可以合理的预留负载，提高资源利用率，给玩家带来更加流畅的游戏体验。

基于相同的发明构思，本申请实施例还提供了一种电子设备，该电子设备的结构示意图如图12所示，该电子设备9000包括至少一个处理器9001、存储器9002和总线9003，至少一个处理器9001均与存储器9002电连接；存储器9002被配置用于存储有至少一个计算机可执行指令，处理器9001被配置用于执行该至少一个计算机可执行指令，从而执行如本申请中任意一个实施例或任意一种可选实施方式提供的任意一种地图负载均衡的方法的步骤。

进一步，处理器9001可以是fpga（field－programmablegatearray，现场可编程门阵列）或者其它具有逻辑处理能力的器件，如mcu（microcontrollerunit，微控制单元）、cpu（centralprocessunit，中央处理器）。

应用本申请实施例，至少具有如下有益效果：

获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载；根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度；根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，并根据各场景进程的负载进行负载均衡。如此，通过地图的平均聚集程度考虑了不同玩法之间的差异，以及不同玩家行为之间的差异，从而可以准确评估地图对应的场景进程的负载，使场景进程的负载更加均衡；同时可以合理的预留负载，提高资源利用率，给玩家带来更加流畅的游戏体验。

基于相同的发明构思，本申请实施例还提供了另一种计算机可读存储介质，存储有计算机程序，该计算机程序用于被处理器执行时实现本申请中任意一个实施例或任意一种可选实施方式提供的任意一种地图负载均衡的的步骤。

本申请实施例提供的计算机可读存储介质包括但不限于任何类型的盘（包括软盘、硬盘、光盘、cd-rom、和磁光盘）、rom（read-onlymemory，只读存储器）、ram（randomaccessmemory，随即存储器）、eprom（erasableprogrammableread-onlymemory，可擦写可编程只读存储器）、eeprom（electricallyerasableprogrammableread-onlymemory，电可擦可编程只读存储器）、闪存、磁性卡片或光线卡片。也就是，可读存储介质包括由设备（例如，计算机）以能够读的形式存储或传输信息的任何介质。

应用本申请实施例，至少具有如下有益效果：

获取至少两个场景进程中各场景进程分别对应的至少一个地图的负载单元信息和至少一个地图的预计负载；根据至少一个地图的负载单元信息，确定至少一个地图的平均聚集程度；根据至少一个地图的平均聚集程度、至少一个地图的负载单元信息和至少一个地图的预计负载，确定至少一个地图对应的场景进程的负载，并根据各场景进程的负载进行负载均衡。如此，通过地图的平均聚集程度考虑了不同玩法之间的差异，以及不同玩家行为之间的差异，从而可以准确评估地图对应的场景进程的负载，使场景进程的负载更加均衡；同时可以合理的预留负载，提高资源利用率，给玩家带来更加流畅的游戏体验。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本申请公开的结构图和/或框图和/或流图的框或多个框中指定的方案。

本技术领域技术人员可以理解，本申请中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本申请中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本申请中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。