一种资源动态部署方法、装置、服务器及存储介质与流程

本发明涉及互联网技术领域，尤其涉及一种资源动态部署方法、装置、服务器及存储介质。

背景技术：

在互联网技术领域，通常会出现服务器进程瞬时接收到大量网络请求，使得服务器进程无法承载的情况，对于一些对实时性要求较高的应用场景，如果服务器不能及时响应这些网络请求，将会导致服务延迟卡顿，从而影响用户体验。

现有的技术方案中提供了一种部署方法，即在服务器进程启动前，预估各场景中的在线目标对象数量，根据预估的数据部署各进程和各分线，并设置进程和分线的负载上限。这种静态部署方案是在进程启动前就固定的，其缺点是无法精确预估各进程在线情况，在线预判难度高，各进程负载均衡不理想。

技术实现要素：

本发明所要解决的技术问题在于，提供一种资源动态部署方法、装置、服务器及存储介质，能够根据真实负载情况动态创建分线，实现了各进程动态负载均衡。

为了解决上述技术问题，第一方面，本发明提供了一种资源动态部署方法，包括：

获取各预设进程中各分线的分线信息及分线负载，其中，每个所述预设进程中均包括若干所述分线；

根据所述分线信息确定与每个场景对应的若干关联分线；

遍历各场景，在每个场景中，当所述场景的各个所述关联分线的分线负载均满足第一预设条件时，获取各预设进程的进程负载；

在所述进程负载最小的所述预设进程中为该场景创建新分线。

第二方面，本发明提供了一种资源动态部署装置，包括：

分线数据获取模块，用于获取各预设进程中各分线的分线信息及分线负载，其中，每个所述预设进程中均包括若干所述分线；

场景分线确定模块，用于根据所述分线信息确定与每个场景对应的若干关联分线；

场景遍历模块，用于遍历各场景，在每个场景中，当所述场景的各个所述关联分线的分线负载均满足第一预设条件时，获取各预设进程的进程负载；

分线创建模块，用于在所述进程负载最小的所述预设进程中为该场景创建新分线。

第三方面，本发明提供了一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上述第一方面所述的资源动态部署方法。

第四方面，本发明提供了一种计算机存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、所述代码集或指令集由处理器加载并执行以实现如上述第一方面所述的资源动态部署方法。

实施本发明实施例，具有如下有益效果：

本发明通过获取各预设进程中各分线的分线信息及分线负载，从而根据所述分线信息确定与每个场景对应的若干关联分线；遍历各场景，在每个场景中，当所述场景的各个所述关联分线的分线负载均满足第一预设条件时，获取各预设进程的进程负载，并在进程负载最小的所述预设进程中为该场景创建新分线。本发明根据各进程的真实负载信息以及各分线负载信息，确定是否需要创建新分线，当需要创建新分线时，在进程负载最小的所述预设进程中创建新分线，实现了分线的按需动态创建以及各进程的负载均衡。

附图说明

图1是本发明实施例提供的应用场景示意图；

图2是本发明实施例提供的一种资源动态部署方法示意图；

图3是本发明实施例提供的一种分线动态创建方法示意图；

图4是本发明实施例提供的一种进程负载状态确定方法示意图；

图5是本发明实施例提供的一种分线负载状态判断示意图；

图6是本发明实施例提供的一种分线分配方法示意图；

图7是本发明实施例提供的另一种资源动态部署方法示意图；

图8是本发明实施例提供的一种服务器架构图；

图9是本发明实施例提供的一种为玩家分配分线流程示意图；

图10是本发明实施例提供的一种资源动态部署装置示意图；

图11是本发明实施例提供的场景遍历模块示意图；

图12是本发明实施例提供的分线分配装置示意图；

图13是本发明实施例提供的分线分配模块示意图；

图14是本发明实施例提供的另一种资源动态部署装置示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。而且，术语“第一”、“第二”等适用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

请参见图1，其示出了本发明的应用场景示意图，包括若干终端设备110和服务器120，所述终端设备110包括但不限于：智能手机、平板电脑、笔记本电脑、台式电脑等终端设备；所述服务器120可以是由若干台服务器组成的服务器集群，或者是一个云计算服务中心。服务器120可以通过网络与终端设备110建立通信连接，该网络可以是无线网络，也可以是有线网络。

在实际应用中，用户通过终端设备110向服务器120发送服务接入请求，服务器120根据接收到的接入请求，将用户接入到服务器进程中的某条分线上以接受在线服务。服务器120将接入服务器进程中的多个用户划分到若干的场景分线中，这些分线由若干进程共同承载。服务器120以预设的周期遍历各场景，对于每个场景，当该场景的各场景分线的分线负载均满足一定的条件时，服务器120为该场景动态创建新分线，以供后续请求接入服务器的用户使用。

请参见图2，其示出了一种资源动态部署方法，可以应用于服务器侧，所述方法包括：

s210.获取各预设进程中各分线的分线信息及分线负载，其中，每个所述预设进程中均包括若干所述分线。

预设进程可以提前在服务器上进行部署，由于服务器所能够承载的进程数量是有限的，具体部署的进程数量可根据实际情况进行确定。服务器对所有进程和分线进行监控，获取各预设进程中每条分线的分线信息和分线负载，这里的分线信息可以包括分线的序号以及分线所承载的场景信息，其中，所述分线的序号是在创建该分线时为该分线分配的序号；分线负载是指该分线上当前在线的目标对象的数量，目标对象可以是多个不同类型的对象。

s220.根据所述分线信息确定与每个场景对应的若干关联分线。

分线信息中会包括分线承载的场景信息，根据分线信息可以确定哪些分线是与当前场景相关的，即确定了与每个场景所对应的若干关联分线，需要说明的是，由于场景的具体运行情况以及分线的部署都是动态变化的，这里的场景与场景的关联分线的对应关系并不是固定不变的，即在不同时刻确定与该场景对应的关联分线有可能是不同的。

s230.遍历各场景，在每个场景中，当所述场景的各个所述关联分线的分线负载均满足第一预设条件时，获取各预设进程的进程负载。

服务器以预设的周期对部署的每个场景进行遍历，本实施例中，该周期可以为200ms，即每隔200ms遍历检查所有的场景，在每次遍历场景之后，根据每个场景的关联分线的分线负载信息，判断是否需要创建新分线，具体实现过程如下：

请参见图3，其示出了一种分线动态创建方法示意图，具体包括：

s310.对于该场景中的每条关联分线，当所述关联分线上的目标对象数量达到第一预设值时；或，当所述关联分线所在的预设进程处于第一预设状态时，判定该关联分线满足所述第一预设条件。

本实施例中，在判断某条分线是否满足第一预设条件时，主要涉及到两个方面的信息判断：一是对该分线上的目标对象的数量进行判断，二是对该分线所在的进程的状态进行判断。

对于第一方面信息的判断，通过获取当前分线上目标对象的数量，其中目标对象可以包括多个不同类型的对象，将目标对象的数量与第一预设值进行比较，当目标对象数量达到第一预设值时，判断第一方面的条件满足。

对于第二方面信息的判断，获取当前分线所在的进程的状态，这里关于进程状态的确定需要根据该进程中所有分线的分线负载来进行确定，即首先根据当前分线确定当前分线所在的进程，再获取该进程中所有分线的分线负载；具体地，可参见图4，其示出了一种进程负载状态确定方法示意图，所述方法包括：

s410.对该进程中所有分线上的目标对象进行分类统计，计算出各类型对象的总数。

对目标对象进行分类统计，多条分线上的相同类型的目标对象统计为一类数据。

s420.对不同类型对象的数量进行加权计算，得到该进程的进程负载。

这里对于各类目标对象权值可以是根据经验预设的权值，对于每一个进程，将该预设的各权值分配给各类型的目标对象进行加权计算，加权计算结果即为该进程的进程负载。

s430.根据所述进程负载确定该进程的进程状态。

对于每一个进程均有进程负载上限，其标识了该进程所能够承载的最大负载，在实际应用过程中，还会为每个进程设置负载临界值，即当进程的负载大于临界值时，判断该进程处于高负载状态。

应用于本实施例中，将计算得到的进程负载与负载临界值进行比较，当进程负载大于该临界值时，判断该进程处于高负载状态，此时判断第二方面的条件满足。

对于某一条分线，只需满足上述两方面条件的任一方面，就可判断该分线满足第一预设条件。其中，某条分线满足第一预设条件包括了以下几种情况：

1.关联分线上的目标对象数量达到第一预设值，但关联分线所在的预设进程不处于第一预设状态；

2.关联分线上的目标对象数量达到第一预设值，且关联分线所在的预设进程处于第一预设状态；

3.关联分线上的目标对象数量没有达到第一预设值，但关联分线所在的预设进程处于第一预设状态。

s320.当该场景的所述关联分线均满足所述第一预设条件时，根据获取的所述各预设进程的进程负载，确定进程负载最小的所述预设进程。

根据步骤s420所述的进程负载的计算方法，分别计算出各预设进程的进程负载，并从中选择出进程负载最小的进程。其中，有部分进程是上述场景中涉及到的进程，对于进程负载的值在判断进程负载状态时已计算过，此时可以直接获取到；可能还有部分进程是上述场景中没有涉及到的，此时需要对剩余的相关进程进行进程负载的计算，最终可以得到所有进程的进程负载，根据各进程负载确定进程负载最小的进程。

其中，关于对关联分线的分线负载进行判断的具体过程可参见图5，其中，当遍历到某个场景中存在不符合第一预设条件的分线时，则不需要为该场景中创建新分线，即该场景中存在这样一条分线：该分线上的在线目标对象的数量没有达到第一预设值，且该分线所在的进程不处于高负载状态，该分线还可以容纳若干的目标对象，此时服务器还可以将相关目标对象接入到该分线上，以提供相关的在线服务。

s240.在所述进程负载最小的所述预设进程中为该场景创建新分线。

选择进程负载最小的预设进程创建新分线是为了确保各进程的负载均衡，不至于出现某个进程的负载过大或者某个进程的负载过小的情况。

在创建新分线时，为所述新分线分配序号，其中所述序号大小根据创建分线的先后顺序依次递增。

这里创建新分线是一种预创建模式，即当场景分线状态满足预设条件时，进行新分线的创建，创建的新分线可用来备用，以满足可能到来的用户接入请求。

上述的资源动态部署方法，通过监控各进程和各分线的负载状态，根据场景中的真实负载情况判断是否需要创建新分线，并在需要创建新分线时，选择在进程负载最小的进程中为该场景创建新分线，以此来为更多的用户提供在线服务，并且实现了各进程的负载均衡。

本实施例上述的一种资源动态部署方法主要是服务器通过以预设的周期遍历各场景，从而根据进程负载进行相关场景分线的动态创建，所述资源动态部署方法还可以包括将分线分配给用户来提供相关的在线服务，具体可参见图6，其示出了一种分线分配方法示意图，所述方法包括：

s610.响应于目标场景切换请求，确定所述目标场景的预占位信息以及与所述目标场景对应的若干目标分线，其中，每条所述目标分线均有与其对应的分线序号。

本实施例中的场景切换主要包括用户在登录时，需要将用户分配到某一个场景分线中，具体可以是用户上次离开时所在的场景分线；以及用户请求从当前场景切换到另一个场景时，需要根据用户的切换请求，将用户分配到目标场景的分线中。其中，各用户请求切换的目标场景不一定相同。

在接收到目标场景切换请求时，需要根据切换请求确定待接入目标对象的数量及占位信息，其中占位信息可包括各场景待接入目标对象的数量，根据占位信息以及进程负载和分线负载的真实情况，确定当前分线状态是否能够承载待接入的负载。

s620.按照所述分线序号由小至大的顺序，遍历所述若干目标分线。

s630.根据遍历结果和所述预占位信息，为用户分配分线。

当在所述若干目标分线中找到符合所述预占位信息的分线时，将所述分线分配给用户；当在所述若干目标分线中没有找到符合所述预占位信息的分线时，为所述目标场景创建新分线，将所述新分线分配给用户。

在某个场景中，按分线序号由小至大的顺序，判断当前分线是否达到负载上限，若当前分线没有达到负载上限且当前分线所在的进程也不处于高负载状态，则根据实际情况，将待接入目标对象分配到该分线；当目标对象均分配到分线时，停止遍历；当只有一部分目标对象分配到分线时，继续遍历序号更大的分线；这里的接入分线的顺序可以是根据用户发送接入请求的顺序进行依次接入。

根据预占位信息，综合当前分线在线目标对象数量和当前待接入目标对象数量，确定当前场景所对应的分线是否能够满足当前的切线请求，当不能够满足时，及时为该场景重新创建新分线。具体创建新分线的方法可参见本实施例上述的步骤s230～步骤s240。

以上的分线分配方法能够支持多场景多分线的系统，在高并发切线的情况下，也能实现各进程动态负载均衡，在用户登录及切换场景时根据分线负载情况为用户分配合适的分线，给不限场景不限人数的用户切线提供了最大自由度。

这里的预占位信息可以用于根据待接入目标对象的数量，确定分线的分配策略，综合考虑在线目标对象数量和预占位对象数量，当分线分配不够时，及时进行新分线的创建。预占位机制消除了从分配分线到待接入对象进入分线的时间差造成的负载误判，既保证瞬时高并发切线时能预判各进程负载并快速部署分线，又保证给用户分配分线是不会超出分线设定的上限。

在具体实施过程中，本实施例上述图6的分线分配方法可以单独进行实施，也可以与图2中所述的资源动态部署方法联合实施，具体可根据实际情况而定。

以上实施例中的资源动态部署方法主要是说明根据场景遍历结果进行场景分线的动态部署过程，以及在分配分线过程中进行分线动态部署，此外，在具体实施过程中，在图2所示的资源动态部署方法的基础上，图7示出了另一种资源动态部署方法，所述方法还可以包括：

s710.在遍历各场景的过程中，当某个场景中存在负载分线满足第二预设条件的关联分线时，回收该关联分线。

具体可以为：当该分线上的目标对象的数量为0时，回收该分线。需要说明的是，在回收分线的过程中，需要对该场景中涉及的分线按序号从大到小的顺序进行查找，并优先回收序号大的分线。通过回收序号大的分线，节约了系统资源。

本实施例上述的方法可以应用于提供在线服务的应用场景，下面将以游戏场景为例对本申请的具体实施方式进行说明，首先，请参见图8，其示出了应用于游戏场景的服务器架构图，示例性地，其中包括接入模块tconnd、服务器进程zonesvr以及中心控制节点worldsvr，服务器进程zonesvr包括：zonesvr1、zonesvr2、zonesvr3和zonesvr4，其分别部署在两台机器上，每台机器上均有接入模块tconnd。如图8所示，客户端client通过服务器的接入模块tconnd连接到服务器集群上接受游戏服务，客户端client的所有请求都通过接入模块tconnd转发到某个服务器进程zonesvr上；中心控制节点worldsvr统一控制何时在哪个进程zonesvr上动态创建分线，以及把玩家分配到哪个分线上。需要说明的是，中心控制节点worldsvr可以不用独立的进程实现，而是在所有zonesvr中选一个进程作为主进程，替代worldsvr实现的相关功能。

在游戏中，所有玩家及npc的行走、打斗、做任务等玩法都在进程zonesvr上进行，npc是指不受玩家操控的角色，包括怪物、交互角色等。每个玩家和npc都处于某个zonesvr上的某个场景的某个分线中。每个zonesvr可以动态创建新分线，由worldsvr通知创建，创建的分线数量没有限制。由于cpu及网络流量的限制，每个进程能承载的玩家数及npc数量都有一定上限。同样由于cpu及网络流量的限制，每个机器能承载的进程数也有限，本实施例中根据实际情况在两个机器上分别部署了四个zonesvr进程，即zonesvr1、zonesvr2、zonesvr3和zonesvr4。

每个进程zonesvr定时把自己各分线的玩家和npc数量等影响进程负载的信息上报到中心控制节点worldsvr，worldsvr维护所有进程及分线的负载信息，这些信息作为创建、回收、分配分线的依据，本实施例中，可以将进程zonesvr进行信息上报的频率设置为没3s上报一次。worldsvr实时检查四个zonesvr各分线的玩家数量及npc数量来决定是否要创建和回收分线，以及在哪个zonesvr进程上创建分线；如果要创建和回收分线，worldsvr通知到对应的zonesvr进行处理。

玩家登录及切线时，需要通过zonesvr到worldsvr上请求分配分线，worldsvr会根据各分线的玩家数量及npc数量给玩家分配最优的分线。

在某游戏中，假设场景a是新手村场景，在游戏开服的时候会有大量玩家涌入场景a，高峰时达到15000人左右。为了保证用户体验，希望每个场景a分线的人数不超过2000人。玩家在场景a做任务升到一定级别后，会分流到场景b、场景c、场景d等场景，用户分流情况难以预估，同时一些场景玩法也会导致玩家迅速集中在某个场景，用户在场景中迁移的群体行为复杂多变。

在某个游戏玩法中，每天到某个时间点后，所有玩家都可以进入该游戏的几个场景中攻击某个boss，boss是指游戏中比较大的怪物，通常数量很少，拥有较高的数值输出，玩家击杀后获得较多奖励。该玩法有六个关卡，玩法开始所有参与玩家都进入第一个关卡场景，玩家共同击杀boss时，服务器会向所有玩家下发传送门，玩家点传送门后传送到第二个关卡。后面的关卡以此类推。该玩法高峰期有3000人参与，为了保证攻击boss时玩家不过于聚集，需要每个分线不超过200人。在击杀完一个关卡的boss后，会有大量玩家瞬时高并发切到下一关卡的分线。

基于上述的情况说明，可知此时单场景中的在线玩家数量可能超出后台单进程能承载的范围，同时玩家过于拥挤时也会影响游戏体验，因此需要把场景中的玩家划分到若干互相不可见的场景分线中，并且这些分线由若干进程共同承载。在这种情况下，游戏后台是一个分布式服务器集群承载的多场景多分线系统。玩家登录以及在不同场景中切换时，系统需要把玩家分配到某一个场景的分线中。给玩家分配分线的步骤为：先在服务器集群中找到合适的机器，再在机器上找到合适的进程，最后在进程中找到合适的分线。设计的分配分线的策略需要保证各机器、各进程负载均衡，同时保证一个分线人数达到设定的上限之后，再给玩家分配下一个新的分线。

给玩家分配分线的过程具体可包括：

玩家登录时，先选择任一zonesvr登录，到worldsvr上请求分线，worldsvr根据玩家上次下线所在场景分配好分线返回给客户端，客户端再到目标zonesvr登录。

玩家请求切场景时，原zonesvr把要切的目标场景告诉worldsvr，worldsvr分配好目标场景的分线告诉原zonesvr，原zonesvr再把玩家数据迁移到目标分线所在zonesvr。

玩家在登录或切线时，需要先到worldsvr分配分线，然后客户端需要5到10秒的时间加载新场景，再进入到目标分线中。如果分配分线时只考虑分线中的玩家数量，在大量玩家在5到10秒内内同时切线的情况下，就可能给某个分线分配了过多的玩家，解决方法是玩家请求切线时到worldsvr请求预占位，切线结束再取消占位，给玩家分配分线时综合考虑在线玩家数和预占位玩家数。

worldsvr给玩家分配分线时，会找出目标场景的所有分线，优先检查序号小的分线，如果分线未满员，并且分线所在的进程不是高负载状态，就把该分线分给玩家，否则再检查序号更大的分线决定是否分配。在每一个目标场景中，具体为玩家分配分线的过程可参见图9，包括：

s910.找到目标场景的所有分线。

对于每一个切换的目标场景，确定与该目标场景对应的分线。

s920.判断是否有未遍历的场景分线。

按分线序号从小到大的顺序遍历该场景的所有分线，并对每条分线进行判断。

s930.当有分线未遍历时，取序号最小的分线。

s940.判断当前分线中是否满员。

若当前分线没有满员，执行步骤s950；若当前分线满员，执行步骤s920。

s950.判断当前分线所在的进程是否处于高负载状态。

若当前分线所在的进程没有处于高负载状态，执行步骤s960；若当前分线所在的进程处于高负载状态，执行步骤s920。

s960.为玩家分配该分线。

s970.当遍历完该场景中的所有分线时，为该场景动态创建新分线。

在给玩家分配分线的过程中，当存在满足分配条件的分线时，将该分线分配给玩家；当不存在满足分配条件的分线时，根据实际情况为该厂将动态创建分线并分配给玩家。通过以上方法，可以支持大量玩家同时的切换场景操作，同时实现了在切线之后仍保持服务器各进程的负载均衡，为游戏玩家的切换场景提供了更大的自由度。

另外，当某场景中分线序号大的分线玩家数量降为0时，worldsvr向zonesvr发送回收该分线的指令。

对于大量玩家同时从一个或多个场景瞬间切换到另一个目标场景，目标场景中的玩家数量突然暴增的情况，上述实施例提供了一种短时间内在各机器上动态部署分线及给玩家分配分线的方案，该方案既保证了各机器和进程负载均衡，又保证了每个分线中的玩家数量在合理范围内。

相比于现有技术中的分线机制：通过预估各场景高峰时的人数，把高在线场景和低在线场景搭配在一起，同时考虑玩家在不同场景的迁移导致进程的在线人数高峰情况，在进程启动之前对进程和分线进行部署，可见这种预部署的方式是固定的，不灵活的，一旦部署完成，难以更改；其次，无法精确预估个进程在线情况，各进程负载均衡不理想，也无法支持高并发切线。以上实施例所提供的资源动态部署方法降低了后台多进程多分线场景承载的部署复杂度，进行资源的灵活、按需部署，实现了各进程负载动态均衡，减少了各进程负载不均衡时部分服务器负载过高导致的服务延迟卡顿问题；同时支持不限场景不限人数的大量用户同时切线操作，在同时切线时及之后仍保证服务器的负载均衡，为用户切场景提供了更大的自由度。

本实施例还提供了一种资源动态部署装置，请参见图10，所述装置包括：

分线数据获取模块1010，用于获取各预设进程中各分线的分线信息及分线负载，其中，每个所述预设进程中均包括若干所述分线；

场景分线确定模块1020，用于根据所述分线信息确定与每个场景对应的若干关联分线；

场景遍历模块1030，用于遍历各场景，在每个场景中，当所述场景的各个所述关联分线的分线负载均满足第一预设条件时，获取各预设进程的进程负载；

分线创建模块1040，用于在所述进程负载最小的所述预设进程中为该场景创建新分线。

请参见图11，所述场景遍历模块1030包括：

判定模块1110，用于对于该场景中的每条关联分线，当所述关联分线上的目标对象数量达到第一预设值时；或，当所述关联分线所在的预设进程处于第一预设状态时，判定该关联分线满足所述第一预设条件；

进程确定模块1120，用于当该场景的所述关联分线均满足所述第一预设条件时，根据获取的所述各预设进程的进程负载，确定所述进程负载最小的所述预设进程。

请参见图12，所述装置还包括：

请求响应模块1210，用于响应于目标场景切换请求，确定所述目标场景的预占位信息以及与所述目标场景对应的若干目标分线，其中，每条所述目标分线均有与其对应的分线序号；

分线遍历模块1220，用于按照所述分线序号由小至大的顺序，遍历所述若干目标分线；

分线分配模块1230，用于根据遍历结果和所述预占位信息，为用户分配分线。

请参见图13，所述分线分配模块1230包括：

第一分配模块1310，用于当在所述若干目标分线中找到符合所述预占位信息的分线时，将所述分线分配给用户；

第二分配模块1320，用于当在所述若干目标分线中没有找到符合所述预占位信息的分线时，为所述目标场景创建新分线，将所述新分线分配给用户。

另外，请参见图14，在图10所示的资源动态部署装置的基础上还可以包括：

分线回收模块1450，用于遍历各场景，当某个场景中存在分线负载满足第二预设条件的关联分线时，回收所述关联分线。在创建新分线时，为所述新分线分配序号，其中所述序号根据创建分线的先后顺序依次递增。

上述实施例中提供的装置可执行本发明任意实施例所提供方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的方法。

本实施例还提供了一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如本实施例上述的任一方法。

本实施例还提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、所述代码集或指令集由处理器加载并执行以实现如本实施例上述的任一方法。

本申请的技术方案降低了后台多进程多分线场景承载的部署复杂度，做到了各进程负载动态均衡，减少了各进程负载不均衡时部分服务器负载过高导致的服务延迟卡顿问题；同时支持不限场景不限人数的大量用户同时切线操作，在同时切线时及之后仍保证服务器的负载均衡，为用户切场景提供了更大的自由度，解决了现有技术中无法精确预估各进程在线情况，在线预判难度高，各进程负载均衡不理想的技术问题。

本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤和顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或中断产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本实施例中所示出的结构，仅仅是与本申请方案相关的部分结构，并不构成对本申请方案所应用于其上的设备的限定，具体的设备可以包括比示出的更多或更少的部件，或者组合某些部件，或者具有不同的部件的布置。应当理解到，本实施例中所揭露的方法、装置等，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分仅仅为一种逻辑功能的划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元模块的间接耦合或通信连接。

基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员还可以进一步意识到，结合本说明书所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但这种实现不应认为超出本发明的范围。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。