游戏集群管理方法、装置、存储介质和电子设备.pdf

1、(19)中华人民共和国国家知识产权局 (12)发明专利申请 (10)申请公布号 (43)申请公布日 (21)申请号 202011074430.X (22)申请日 2020.10.09 (71)申请人 网易 （杭州） 网络有限公司 地址 310052 浙江省杭州市滨江区长河街 道网商路599号4幢7层 (72)发明人 杨晓波 (74)专利代理机构 深圳紫藤知识产权代理有限 公司 44570 代理人 远明 (51)Int.Cl. G06F 9/50(2006.01) A63F 13/55(2014.01) A63F 13/77(2014.01) (54)发明名称 游戏集群管理方法、 装置、 存储介

2、质和电子 设备 (57)摘要 本申请实施例公开了一种游戏集群管理方 法、 装置、 存储介质和电子设备； 本申请实施例， 在通过战斗节点运行指定游戏逻辑的过程中， 确 定当前游戏集群中各观战转发节点关联的观战 客户端数量， 其中， 观战转发节点被配置为用于 处理来源于战斗节点的战斗数据； 当检测到目标 客户端发送的观战请求时， 若所有观战转发节点 关联的观战客户端数量均达到上限值， 则在游戏 集群中创建目标观战转发节点， 并建立目标观战 转发节点与目标客户端之间的关联； 当检测到关 联的观战客户端数量少于预设值的空闲观战转 发节点时， 移除空闲观战转发节点。 本申请方案 根据实际情况按需消耗物理

3、资源， 避免因观战人 数波动造成资源浪费， 可合理调度集群资源， 提 升集群资源利用率。 权利要求书2页 说明书12页 附图3页 CN 112148495 A 2020.12.29 CN 112148495 A 1.一种游戏集群管理方法， 其特征在于， 包括： 在通过战斗节点运行指定游戏逻辑的过程中， 确定当前所述游戏集群中各观战转发节 点关联的观战客户端数量， 其中， 所述观战转发节点被配置为用于处理来源于战斗节点的 战斗数据， 所述战斗数据基于所述战斗节点运行所述指定游戏逻辑得到； 当检测到新增的目标客户端发送的观战请求时， 若所有观战转发节点关联的观战客户 端数量均达到上限值， 则在所述

4、游戏集群中创建目标观战转发节点， 并建立所述目标观战 转发节点与所述目标客户端之间的关联； 当检测到关联的观战客户端数量少于预设值的空闲观战转发节点时， 移除所述空闲观 战转发节点。 2.根据权利要求1所述的游戏集群管理方法， 其特征在于， 所述在所述游戏集群中创建 目标观战转发节点， 包括： 确定当前所述游戏集群中正在运行的游戏进程， 得到进程集合； 获取所述进程集合中每一游戏进程对应的负载； 根据所述负载的大小从所述进程集合中确定目标游戏进程； 通过所述目标游戏进程创建目标观战转发节点。 3.根据权利要求2所述的游戏集群管理方法， 其特征在于， 所述获取所述进程集合中每 一游戏进程对应的负

5、载， 包括： 确定所述进程集合中各游戏进程创建的观战转发节点的数量； 根据观战转发节点的数量确定各游戏进程对应的负载。 4.根据权利要求1所述的游戏集群管理方法， 其特征在于， 在建立所述目标观战转发节 点与所述目标客户端之间的关联之后， 还包括： 将所述目标客户端作为观战客户端， 并更新所述目标观战转发节点关联的观战客户端 数量。 5.根据权利要求4所述的游戏集群管理方法， 其特征在于， 还包括： 当接收到目标观战客户端发送的结束观战请求时， 解除所述目标观战客户端与对应观 战转发节点之间的关联， 并更新所述对应观战转发客户端关联的观战客户端数量。 6.根据权利要求1-5任一项所述的游戏集群

6、管理方法， 其特征在于， 还包括： 当检测到各观战节点和/或所述目标观战转发节点上存储有来源于战斗节点的战斗数 据时， 通过观战节点和/或所述目标观战转发节点向对应关联的观战客户端发送战斗数据。 7.根据权利要求6所述的游戏集群管理方法， 其特征在于， 所述游戏集群还包括： 一个 或多个观战转发中心节点， 观战转发中心节点被配置为用于处理战斗节点转发的战斗数 据， 每一观战转发节点关联至少一个战斗节点、 及至少一个观战转发节点； 在通过所述观战节点和/或所述目标观战转发节点向对应关联的观战客户端发送战斗 数据之前， 还包括： 通过战斗节点将战斗数据发送至关联的观战转发中心节点； 通过观战转发中

7、心节点将接收到的战斗数据转发至关联的观战转发节点。 8.根据权利要求7所述的游戏集群管理方法， 其特征在于， 所述战斗数据包括： 包含指 定视频帧数的合包数据； 所述通过战斗节点将战斗数据发送至关联的观战转发中心节点， 包括： 权利要求书 1/2 页 2 CN 112148495 A 2 每间隔预设时长通过战斗节点向关联的观战转发中心节点发送所述合包数据。 9.一种游戏集群管理装置， 其特征在于， 包括： 确定单元， 用于在通过战斗节点运行指定游戏逻辑的过程中， 确定当前所述游戏集群 中各观战转发节点关联的观战客户端数量， 其中， 所述观战转发节点被配置为用于处理来 源于战斗节点的战斗数据，

8、所述战斗数据基于所述战斗节点运行所述指定游戏逻辑得到； 创建单元， 用于当检测到新增的目标客户端发送的观战请求时， 若所有观战转发节点 关联的观战客户端数量均达到上限值， 则在所述游戏集群中创建目标观战转发节点， 并建 立所述目标观战转发节点与所述目标客户端之间的关联； 移除单元， 用于当检测到关联的观战客户端数量少于预设值的空闲观战转发节点时， 移除所述空闲观战转发节点。 10.一种计算机可读存储介质， 其特征在于， 所述计算机可读存储介质存储有多条指 令， 所述指令适于处理器进行加载， 以执行权利要求1-8任一项所述的游戏集群管理方法中 的步骤。 11.一种电子设备， 其特征在于， 包括处

9、理器和存储器， 所述存储器存储有多条指令； 所 述处理器从所述存储器中加载指令， 以执行根据权利要求1-8任一项所述的游戏集群管理 方法中的步骤。 权利要求书 2/2 页 3 CN 112148495 A 3 游戏集群管理方法、 装置、 存储介质和电子设备 技术领域 0001 本申请涉及通信技术领域， 具体涉及一种游戏集群管理方法、 装置、 存储介质和电 子设备。 背景技术 0002 随着互联网的发展和移动通信网络的发展， 同时也伴随着终端的处理能力和存储 能力的迅猛发展， 海量的应用程序得到了迅速传播和使用， 同时对相应服务器的要求也越 来越高。 0003 对于许多网络游戏而言， 尤其是竞技

10、类网络游戏， 实时观战功能是极为重要的。 观 战功能通常是将比赛内玩家的网络数据转发给观战玩家的客户端， 并由客户端模拟战斗场 景来实现的。 随着玩家数的增多， 观战系统需要承载大量玩家同时在线观战， 为了减轻服务 器的负载， 通常在用于玩家战斗的服务器集群之外， 独立创建用于玩家观战的服务器集群。 0004 然而， 由于游戏中能承载的最大同时观战玩家数量， 往往和承载观战业务的物理 机器数量呈正相关。 若观战集群的机器数量过少， 则当观战玩家数量急剧上升时， 将会导致 服务器压力过大； 若观战集群的机器数量过多， 则在无大型赛事时很多机器将处于空闲状 态， 造成机器资源的浪费。 发明内容 0

11、005 本申请实施例提供一种游戏集群管理方法、 装置、 存储介质和电子设备， 可以合理 调度集群资源， 提升集群资源利用率。 0006 本申请实施例提供一种游戏集群管理方法， 包括： 0007 在通过战斗节点运行指定游戏逻辑的过程中， 确定当前所述游戏集群中各观战转 发节点关联的观战客户端数量， 其中， 所述观战转发节点被配置为用于处理来源于战斗节 点的战斗数据， 所述战斗数据基于所述战斗节点运行所述指定游戏逻辑得到； 0008 当检测到新增的目标客户端发送的观战请求时， 若所有观战转发节点关联的观战 客户端数量均达到上限值， 则在所述游戏集群中创建目标观战转发节点， 并建立所述目标 观战转发

12、节点与所述目标客户端之间的关联； 0009 当检测到关联的观战客户端数量少于预设值的空闲观战转发节点时， 移除所述空 闲观战转发节点。 0010 相应的， 本申请实施例提供一种游戏集群管理方法， 包括： 0011 确定单元， 用于在通过战斗节点运行指定游戏逻辑的过程中， 确定当前所述游戏 集群中各观战转发节点关联的观战客户端数量， 其中， 所述观战转发节点被配置为用于处 理来源于战斗节点的战斗数据， 所述战斗数据基于所述战斗节点运行所述指定游戏逻辑得 到； 0012 创建单元， 用于当检测到新增的目标客户端发送的观战请求时， 若所有观战转发 节点关联的观战客户端数量均达到上限值， 则在所述游戏

13、集群中创建目标观战转发节点， 说明书 1/12 页 4 CN 112148495 A 4 并建立所述目标观战转发节点与所述目标客户端之间的关联； 0013 移除单元， 用于当检测到关联的观战客户端数量少于预设值的空闲观战转发节点 时， 移除所述空闲观战转发节点。 0014 在一些实施例中， 所述创建单元用于： 0015 确定当前所述游戏集群中正在运行的游戏进程， 得到进程集合； 0016 获取所述进程集合中每一游戏进程对应的负载； 0017 根据所述负载的大小从所述进程集合中确定目标游戏进程； 0018 通过所述目标游戏进程创建目标观战转发节点。 0019 在一些实施例中， 所述创建单元进一步

14、用于： 0020 确定所述进程集合中各游戏进程创建的观战转发节点的数量； 0021 根据观战转发节点的数量确定各游戏进程对应的负载。 0022 在一些实施例中， 所述装置还包括： 0023 更新单元， 用于在建立所述目标观战转发节点与所述目标客户端之间的关联之 后， 将所述目标客户端作为观战客户端， 并更新所述目标观战转发节点关联的观战客户端 数量。 0024 在一些实施例中， 所述装置还包括： 0025 处理单元， 用于当接收到目标观战客户端发送的结束观战请求时， 解除所述目标 观战客户端与对应观战转发节点之间的关联， 并更新所述对应观战转发客户端关联的观战 客户端数量。 0026 在一些实

15、施例中， 所述装置还包括： 0027 第一转发单元， 用于当检测到各观战节点和/或所述目标观战转发节点上存储有 来源于战斗节点的战斗数据时， 通过观战节点和/或所述目标观战转发节点向对应关联的 观战客户端发送战斗数据。 0028 在一些实施例中， 所述游戏集群还包括： 一个或多个观战转发中心节点， 所述观战 转发中心节点被配置为用于处理战斗节点转发的战斗数据， 每一观战转发节点关联至少一 个战斗节点、 及至少一个观战转发节点； 所述装置还包括： 0029 发送单元， 用于在通过所述观战节点和/或所述目标观战转发节点向对应关联的 观战客户端发送战斗数据之前， 通过战斗节点将战斗数据发送至关联的观

16、战转发中心节 点； 0030 第二转发单元， 用于通过观战转发中心节点将接收到的战斗数据转发至关联的观 战转发节点， 其中， 所述游戏集群中观战转发中心节点的数量少于观战转发节点的数量。 0031 在一些实施例中， 所述战斗数据包括： 包含指定视频帧数的合包数据； 所述发送单 元用于： 0032 每间隔预设时长通过战斗节点向关联的观战转发中心节点发送所述合包数据。 0033 本申请实施例还提供一种计算机可读存储介质， 所述计算机可读存储介质存储有 多条指令， 所述指令适于处理器进行加载， 以执行本申请实施例所提供的任一种游戏集群 管理方法中的步骤。 0034 本申请实施例还提供一种电子设备，

17、包括存储器存储有多条指令； 所述处理器从 所述存储器中加载指令， 以执行本申请实施例所提供的任一种游戏集群管理方法中的步 说明书 2/12 页 5 CN 112148495 A 5 骤。 0035 本申请实施例提供的方案， 在通过战斗节点运行指定游戏逻辑的过程中， 确定当 前游戏集群中各观战转发节点关联的观战客户端数量。 当检测到目标客户端发送的观战请 求时， 若所有观战转发节点关联的观战客户端数量均达到上限值， 则在游戏集群中创建目 标观战转发节点， 并建立目标观战转发节点与目标客户端之间的关联。 当检测到关联的观 战客户端数量少于预设值的空闲观战转发节点时， 移除空闲观战转发节点。 本申请

18、方案根 据实际情况按需消耗物理资源， 避免因观战人数波动造成资源浪费， 可合理调度集群资源， 提升集群资源利用率。 附图说明 0036 为了更清楚地说明本申请实施例中的技术方案， 下面将对实施例描述中所需要使 用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本申请的一些实施例， 对于 本领域技术人员来讲， 在不付出创造性劳动的前提下， 还可以根据这些附图获得其他的附 图。 0037 图1是本申请实施例提供的游戏集群管理方法的流程示意图。 0038 图2a是本申请实施例提供的游戏观战系统的结构示意图。 0039 图2b是本申请实施例提供的基于游戏观战场景的集群管理流程示意图。 004

19、0 图3是本申请实施例提供的游戏集群管理装置的结构示意图。 0041 图4是本申请实施例提供的电子设备的结构示意图。 具体实施方式 0042 下面将结合本申请实施例中的附图， 对本申请实施例中的技术方案进行清楚、 完 整地描述， 显然， 所描述的实施例仅仅是本申请一部分实施例， 而不是全部的实施例。 基于 本申请中的实施例， 本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施 例， 都属于本申请保护的范围。 0043 本申请实施例提供一种游戏集群管理方法、 装置、 存储介质和电子设备。 0044 其中， 该游戏集群管理装置具体可以集成在电子设备中， 该电子设备可以为由多 个服务器组成

20、的服务器集群。 0045 以下分别进行详细说明。 需说明的是， 以下实施例的序号不作为对实施例优选顺 序的限定。 0046 在本实施例中， 提供了一种游戏集群管理方法， 如图1所示， 该游戏集群管理方法 的具体流程可以如下： 0047 101、 在通过战斗节点运行指定游戏逻辑的过程中， 确定当前游戏集群中各观战转 发节点关联的观战客户端数量， 其中， 观战转发节点被配置为用于处理来源于战斗节点的 战斗数据， 战斗数据基于战斗节点运行指定游戏逻辑得到。 0048 具体的， 该游戏集群可由大量游戏进程组成， 这些进程可以分布在不同台服务器 上， 用于承载游戏玩家的游戏业务(如战斗业务)。 每台服务

21、器都可作为一游戏节点(如战斗 节点)， 每个游戏进程可根据其内部逻辑游戏节点的多少， 消耗所在物理机的物理资源。 0049 为了承载大量游戏玩家同时观战， 本实施例中， 将在游戏集群中划分一部分服务 说明书 3/12 页 6 CN 112148495 A 6 器资源用于搭建观战系统来处理网络消息， 如接收网络消息、 存储网络消息、 转发网络消息 等。 0050 其中， 观战转发节点关联的观战客户端， 即与该观战转发节点建立有通信连接的 观战客户端。 在本实施例中， 观战系统可由一台或多台服务器服务器组件而成， 一台服务器 可以作为一个转发节点。 实际应用中， 转发节点的数量将小于战斗节点的数量

22、。 观战转发节 点是战斗观战转发的最小逻辑单元， 也是底层的转发节点， 每一观战转发节点可以与客户 端建立通信连接， 实现将战斗节点转发的战斗数据转发至所有相连的客户端。 0051 在一实施例中， 为了避免因转发节点数量过多导致发起的广播数据过多造成服务 器内部的网络挤压的问题， 可以在战斗节点和底层转发节点之间引入一个中间层， 并通过 该中间层实现战斗节点与底层转发节点之间的通信。 具体的， 可以对上述转发节点划分为 多个层级， 相邻层级之间的转发节点可以建立通信连接。 需要说明的是， 与战斗节点直接建 立通信连接的转发节点可作为转发中心节点， 且转发中心节点所在层级的转发节点数量最 少，

23、其余层级中的转发节点逐层递增。 0052 例如， 可将转发节点划分为双层结构， 每一层包括多个转发节点。 第一层级中的转 发节点接收战斗集群中的被观战比赛转发来的网络消息， 第二层级中的转发节点接收第一 层级中转发节点转发来的网络消息， 并转发给观战客户端。 观战客户端以类似房间的形式 被第二层级中的转发节点管理， 第二层级中每个转发节点一部分观战客户端的消息转发。 需要说明的是， 第一层级中的转发节点数量小于第二层级中转发节点的数量， 其多层的结 构减少了服务器内部网络消息的挤压； 另外， 可通过增加每一层的节点数来增加观战集群 的最大承载玩家数。 0053 也即， 在一些实施例中， 游戏集

24、群还包括一个或多个观战转发中心节点， 观战转发 中心节点被配置为用于处理战斗节点转发的战斗数据， 每一观战转发节点关联至少一个战 斗节点、 及至少一个观战转发节点。 本实施例中， 该游戏集群中观战转发中心节点的数量少 于观战转发节点的数量。 0054 其中， 观战转发中心节点上维护的数据是每场战斗有哪些对应的底层观战转发节 点。 实际应用中， 同集群内可以有一组观战转发中心节点以分摊负载， 每个观战转发中心节 点负责一组战斗节点的数据转发， 可根据战斗节点ID的哈希(hash)值， 决定其战斗数据应 转发到的观战转发中心节点。 0055 102、 当检测到新增的目标客户端发送的观战请求时， 若

25、所有观战转发节点关联的 观战客户端数量均达到上限值， 则在游戏集群中创建目标观战转发节点， 并建立目标观战 转发节点与目标客户端之间的关联。 0056 其中， 该新增的目标客户端指未与该游戏集群中观战转发节点建立通信连接的客 户端。 具体可以是刚加入该游戏集群中的客户端(如刚登录游戏的客户端)， 也可以是从其 他游戏状态(如处于战斗状态)切换至观战状态的客户端。 该目标客户端通过向服务器集群 发起观战请求， 以实现查看以上战斗节点运行指定游戏逻辑时的具体游戏过程。 0057 本申请实施例中， 观战转发节点分布在游戏进程上， 充分利用游戏集群内空闲的 物理资源。 为了避免单个转发节点所在进程负载

26、过高， 每个观战转发节点将负责一场战斗 的一部分观战客户端， 并设定可承载客户端数量的上限值， 如200。 则当某一观战转发节点 连接的观战客户端数量满200时， 将无法再建立与其他客户端的通信连接。 说明书 4/12 页 7 CN 112148495 A 7 0058 若所有观战转发节点关联的观战客户端数量均达到上限值， 即目前游戏集群中不 存在可用的观战转发节点。 此时， 可利用游戏集群内空闲的物理资源创建新的观战转发节 点， 以使其他客户端可通过该新创建的观战转发节点实现游戏观战， 达到动态扩容的效果。 0059 实际应用中， 在建立目标观战转发节点与所述目标客户端之间的关联之后， 可将

27、 目标客户端作为观战客户端， 并更新目标观战转发节点关联的观战客户端数量。 0060 同样的， 当接收到目标观战客户端发送的结束观战请求时， 可解除目标观战客户 端与对应观战转发节点之间的关联， 并更新所述对应观战转发客户端关联的观战客户端数 量。 其中， 当观战客户端与观战转发节点之间的通信连接断开时， 可触发该结束观战请求。 0061 在一些实施例中， 在游戏集群中创建目标观战转发节点时， 可以包括以下流程： 0062 (11)确定当前游戏集群中正在运行的游戏进程， 得到进程集合； 0063 (12)获取进程集合中每一游戏进程对应的负载； 0064 (13)根据负载的大小从进程集合中确定目

28、标游戏进程； 0065 (14)通过目标游戏进程创建目标观战转发节点。 0066 具体的， 为了保证整个游戏集群的负载均衡， 可依据每一游戏进程对应的负载大 小， 来选择合适的进程来执行创建新的观战转发节点。 实际应用中， 可选择当前负载最小的 游戏进程作为目标游戏进程， 并通过该目标游戏进程动态创建目标观战转发节点。 0067 实际应用中， 在获取进程集合中每一游戏进程对应的负载时， 可以获取进程集合 中各游戏进程创建的观战转发节点的数量， 然后根据观战转发节点的数量来计算各游戏进 程对应的负载大小。 0068 103、 当检测到关联的观战客户端数量少于预设值的空闲观战转发节点时， 移除空

29、闲观战转发节点。 0069 具体的， 为了减少物理资源的浪费， 可以检测当前与观战转发节点建立通信连接 的观战客户端数量(即关联的观战客户端数量)， 当检测到有观战转发节点关联的观战客户 端数量少于预设值时， 可将该观战转发节点作为空闲观战转发节点并移除该空闲观战转发 节点， 从而释放物理资源， 达到动态缩容的效果。 0070 具体实施过程中， 可以在空闲观战转发节点未与任何客户端进行通信连接一段时 间以后， 延时销毁该空闲观战转发节点， 以避免游戏玩家频繁发起/退出观战造成观战转发 节点的频繁创建/销毁， 影响服务器性能。 0071 本实施例中， 当检测到各观战节点和/或目标观战转发节点上存

30、储有来源于战斗 节点的战斗数据时， 通过观战节点和/或目标观战转发节点向对应关联的观战客户端发送 战斗数据。 0072 具体实施时， 该战斗数据可以是直接由战斗节点转发至该目标观战转发节点而得 到， 也可以是由战斗节点发送至观战转发中心节点后， 并由该观战转发中心节点转发至该 目标观战转发节点而得到。 0073 在一些实施例中， 为了降低内网节点之间的通讯频率与流量， 降低服务器负载， 可 以对战斗数据进行定时合包再转发给观战系统。 也即， 战斗数据可以为包含指定视频帧数 的合包数据， 在通过战斗节点将战斗数据发送至关联的观战转发中心节点， 可以每间隔预 设时长通过战斗节点向关联的观战转发中心

31、节点发送所述合包数据。 0074 例如， 该战斗数据可以包括战斗玩家发出的所有指令消息， 以及战场定时的快照 说明书 5/12 页 8 CN 112148495 A 8 数据。 一个合包数据可以包含一段时间(如30s)的战斗数据。 每间隔30s， 战斗节点将合包向 观战系统发出近30s的战斗数据， 再通过观战系统转发至相应客户端。 客户端可以根据接收 到的合包数据， 恢复某游戏战斗的执行过程， 达到观战的效果。 0075 在一些实施例中， 若该观战系统存在观战转发中心节点(即对该观战系统进行了 节点层级划分)， 则在通过观战转发节点向各自对应关联的观战客户端发送战斗数据之前， 还可以先通过战斗

32、节点将战斗数据发送至关联的观战转发中心节点， 再通过观战转发中心 节点将战斗数据转发至对应关联的观战转发节点， 最后由观战转发节点向对应关联的客户 端发送战斗数据。 0076 由上可知， 本申请实施例提供的游戏集群管理方法， 在通过战斗节点运行指定游 戏逻辑的过程中， 确定当前游戏集群中各观战转发节点关联的观战客户端数量。 当检测到 目标客户端发送的观战请求时， 若所有观战转发节点关联的观战客户端数量均达到上限 值， 则在游戏集群中创建目标观战转发节点， 并建立目标观战转发节点与目标客户端之间 的关联。 当检测到关联的观战客户端数量少于预设值的空闲观战转发节点时， 移除空闲观 战转发节点。 本

33、申请在战斗集群内部实现了一种支持动态伸缩的观战模式， 一方面， 通过动 态伸缩完全按需消耗物理资源， 避免了因观战人数波动造成的资源浪费。 另一方面， 有效利 用战斗集群内闲置物理资源支撑观战业务， 避免了战斗集群内的资源浪费。 0077 本方案为游戏观战系统提供了动态扩容能力， 当观战人数暴增时可实时动态创建 观战转发节点， 提高系统的承载能力。 通过多级节点的转发和数据合包、 缓存策略， 降低了 服务器观战消息广播的负载。 另外， 所有的网络消息转发都在战斗集群内部， 降低了消息转 发的业务复杂性和风险， 提高观战系统稳定性。 此外， 当单个观战转发节点发生故障时， 可 快速销毁故障节点，

34、 新建观战转发节点， 将玩家迁移到新节点上， 玩家可无感持续观战， 提 高了系统容灾能力。 0078 本申请在游戏战斗集群内部实现了一种支持动态伸缩的游戏观战系统。 参考图 2a， 图2a是本申请实施例提供的游戏观战系统的结构示意图， 整个观战系统在战斗集群内 实现。 0079 其中， 战斗集群由大量游戏进程组成， 这些进程可以分布在不同的物理机上。 每个 进程根据其内部逻辑节点的多少， 消耗所在物理机的物理资源， 如CPU、 内存、 网络流量等。 0080 战斗节点是战斗集群中的一个逻辑单元， 可以分布在任意一个游戏进程上， 通常 游戏战斗集群内有大量战斗节点。 战斗节点负责承载游戏战斗逻辑

35、(即本申请中被观战战 斗所处逻辑单元)， 是观战数据的来源。 当有客户端发起观战请求时， 战斗节点会定时合包 将战斗玩家的网络数据转发至观战转发中心节点。 定时合包是为了降低内网节点之间的通 讯频率与流量， 来降低服务器负载。 0081 观战网络数据包括战斗玩家发出的所有指令消息， 以及战场定时的快照数据。 一 个网络数据包包含一段时间， 例如30s的战斗数据。 每30s战斗节点合包发出近30s的战斗数 据。 客户端最终根据快照数据， 可以恢复某一时刻的战斗场景， 根据之后指令消息数据， 可 以恢复战场的执行过程， 达到观战的效果。 0082 观战节点管理模块是观战系统支持动态伸缩的核心。 负

36、责管理所有的观战转发节 点， 其可将观战客户端分配到合适的空闲观战转发节点， 并根据集群内观战玩家的数量动 态创建/移除该空闲观战转发节点。 说明书 6/12 页 9 CN 112148495 A 9 0083 观战节点管理模块上包含两类数据， 一类数据是当前集群中所有被观战战斗和战 斗对应的观战节点， 以及每个节点上的客户端数， 数据来源是每次客户端请求/退出观战， 分配/销毁观战转发节点时， 都会在管理模块进行计数。 另一类数据是当前战斗集群中所有 游戏进程的负载信息， 数据来源是每次分配/销毁战斗节点或观战转发节点时都会计数。 根 据每个进程上节点数量的多少可以判断负载信息， 每次创建节

37、点都选择当前负载最小的进 程来创建， 从而保证整个集群的负载均衡。 0084 当客户端发起观战请求时， 观战节点管理模块将选择当前可用的观战转发节点， 并将该客户端任务分配给该观战转发节点。 如果当前无可用转发节点， 则根据负载均衡策 略， 选择当前负载最小的游戏进程动态创建转发节点， 并将客户端与该节点绑定。 0085 观战转发中心节点是观战网络数据转发的第一层节点， 同集群内可以有一组转发 中心节点以分摊负载， 每个中心节点负责一组战斗节点的数据转发， 根据战斗节点标识(如 ID)的哈希值(hash)取模， 决定该战斗的观战数据应该转发到哪一个中心节点。 观战转发中 心节点上维护的数据是每

38、场战斗有哪些对应的底层观战转发节点。 战斗节点的数据首先会 定时合包转发到一个中心节点， 并将数据广播到战斗对应的所有底层转发节点。 引入中心 节点相当于在战斗节点和底层观战转发节点之间引入一个中间层， 从而避免大量广播数据 造成服务器内部的网络挤压。 0086 观战转发节点是战斗观战转发的最小逻辑单元， 也是底层的转发节点。 观战转发 节点与客户端直接通信连接， 并可将接收到的观战数据转发到与其建立有通信连接的所有 客户端。 观战转发节点分布在游戏进程上， 充分利用战斗集群内空闲的物理资源。 每个观战 转发节点负责一场战斗的一部分观战客户端， 设定承载客户端数量上限。 以设定的客户端 数量上

39、限为200为例， 则当观战转发节点绑定的客户端数量达到200时将无法再加入观战客 户端， 只能动态创建新的观战节点。 通过这种方式可避免单个转发节点所在进程负载过高。 0087 当没有客户端相连一段时间以后， 观战转发节点会延时自行销毁， 释放资源， 达到 动态缩容的效果。 此处采用延时销毁， 目的是避免玩家频繁发起/退出观战造成观战转发节 点的频繁创建/销毁， 浪费服务器性能。 0088 在本实施例中， 战斗的网络数据会缓存在观战转发节点上， 这样新加入的客户端 可以直接从转发节点上获取历史网络数据， 无需再向战斗节点请求， 可减轻服务器负载。 根 据缓存数据， 客户端可以从任一历史时间节点

40、开始观看战斗过程。 同时， 缓存数据还可以防 止网络抖动造成的数据转发不及时而引发的客户端表现抖动问题。 0089 参考图2b， 图2b为本申请实施例提供的基于游戏观战场景的集群管理流程示意 图。 结合上述游戏观战系统结构， 该集群管理流程具体如下： 0090 201、 客户端发起观战请求。 0091 202、 服务端判断当前是否存在可用的观战转发节点。 0092 203、 若当前存在可用的观战转发节点， 则选择可用转发节点。 0093 204、 若不存在可用的观战转发节点， 则动态创建观战转发节点。 0094 205、 客户端与该观战转发节点绑定， 建立通信连接。 0095 206、 服务端

41、通过观战转发节点向客户端转发战斗数据。 0096 207、 客户端退出观战， 客户端与该观战转发节点的通信连接断开。 0097 208、 当退出观战的客户端所在观战转发节点无其余客户端处于通信连接时， 延时 说明书 7/12 页 10 CN 112148495 A 10 销毁观战转发节点。 0098 具体的， 当客户端请求观战某场比赛时， 服务器首先将请求转发至观战节点管理 模块， 管理模块中有所有底层观战转发节点上报的观战状态， 每场比赛的实时观战节点数、 观战人数等数据。 每个观战转发节点均有承载人数上限， 管理模块根据这些数据判断当前 是否有可用观战转发节点。 例如， 每个观战转发节点上

42、限承载200人， 如被观战比赛有对应 转发节点且节点连接客户端数不足200人， 即为可用转发节点。 0099 若存在可用观战转发节点， 则选择可用节点中观战人数最少的节点， 该节点记录 当前观战人数加1。 若不存在可用观战转发节点， 由于管理模块上有当前集群所有进程上报 的负载信息， 则根据负载均衡策略， 选择当前集群内游戏进程中当前负载最小的进程动态 创建一个转发节点， 并将该节点当前观战人数记为1。 0100 在完成观战节点的动态创建后， 将发起观战请求的客户端与该观战转发节点绑 定， 建立两者间的通信连接。 若当前转发节点上有缓存数据， 则客户端直接拉取缓存数据恢 复历史战斗场景。 后续

43、的网络数据由战斗节点定时合包转发， 经由观战转发中心节点、 观战 转发节点转发到客户端。 客户端可根据网络数据还原战斗场景， 实现在线观战的效果。 0101 当客户端退出观战， 将立刻断开与战斗集群中观战转发节点的通信连接。 同时上 报到观战节点管理模块该节点记录当前观战人数减1。 如果退出观战的客户端所在转发节 点此时无其余客户端连接， 则视为可释放资源， 一定延时后自行销毁， 不再占用服务器资 源， 达到动态缩容的效果。 0102 可知， 本申请在战斗集群内部实现了一种支持动态伸缩的观战模式， 一方面， 通过 动态伸缩完全按需消耗物理资源， 避免了因观战人数波动造成的资源浪费。 另一方面，

44、 有效 利用战斗集群内闲置物理资源支撑观战业务， 避免了战斗集群内的资源浪费。 0103 为了更好地实施以上方法， 本申请实施例还提供一种游戏集群管理装置， 该游戏 集群管理装置具体可以集成在电子设备中， 比如， 该电子设备可以为由多台服务器构成的 服务器集群。 0104 比如， 在本实施例中， 将以游戏集群管理装置具体集成在服务器集群为例， 对本申 请实施例的方法进行详细说明。 0105 例如， 如图3所示， 该游戏集群管理装置可以包括确定单元301和创建单元302和发 送单元303， 如下： 0106 确定单元301， 用于在通过战斗节点运行指定游戏逻辑的过程中， 确定当前所述游 戏集群中

45、各观战转发节点关联的观战客户端数量， 其中， 所述观战转发节点被配置为用于 处理来源于战斗节点的战斗数据， 所述战斗数据基于所述战斗节点运行所述指定游戏逻辑 得到； 0107 创建单元302， 用于当检测到新增的目标客户端发送的观战请求时， 若所有观战转 发节点关联的观战客户端数量均达到上限值， 则在所述游戏集群中创建目标观战转发节 点， 并建立所述目标观战转发节点与所述目标客户端之间的关联； 0108 移除单元303， 用于当检测到关联的观战客户端数量少于预设值的空闲观战转发 节点时， 移除所述空闲观战转发节点。 0109 在一些实施例中， 所述创建单元302用于： 0110 确定当前所述游

46、戏集群中正在运行的游戏进程， 得到进程集合； 说明书 8/12 页 11 CN 112148495 A 11 0111 获取所述进程集合中每一游戏进程对应的负载； 0112 根据所述负载的大小从所述进程集合中确定目标游戏进程； 0113 通过所述目标游戏进程创建目标观战转发节点。 0114 在一些实施例中， 所述创建单元302进一步用于： 0115 确定所述进程集合中各游戏进程创建的观战转发节点的数量； 0116 根据观战转发节点的数量确定各游戏进程对应的负载。 0117 在一些实施例中， 所述装置还可以包括： 0118 更新单元， 用于在建立所述目标观战转发节点与所述目标客户端之间的关联之

47、后， 将所述目标客户端作为观战客户端， 并更新所述目标观战转发节点关联的观战客户端 数量。 0119 在一些实施例中， 所述装置还可以包括： 0120 处理单元， 用于当接收到目标观战客户端发送的结束观战请求时， 解除所述目标 观战客户端与对应观战转发节点之间的关联， 并更新所述对应观战转发客户端关联的观战 客户端数量。 0121 在一些实施例中， 所述装置还可以包括： 0122 第一转发单元， 用于当检测到各观战节点和/或所述目标观战转发节点上存储有 来源于战斗节点的战斗数据时， 通过观战节点和/或所述目标观战转发节点向对应关联的 观战客户端发送战斗数据。 0123 在一些实施例中， 所述游

48、戏集群还包括： 一个或多个观战转发中心节点， 所述观战 转发中心节点被配置为用于处理战斗节点转发的战斗数据， 每一观战转发节点关联至少一 个战斗节点、 及至少一个观战转发节点； 所述装置还包括： 0124 发送单元， 用于在通过所述观战节点和/或所述目标观战转发节点向对应关联的 观战客户端发送战斗数据之前， 通过战斗节点将战斗数据发送至关联的观战转发中心节 点； 0125 第二转发单元， 用于通过观战转发中心节点将接收到的战斗数据转发至关联的观 战转发节点， 其中， 所述游戏集群中观战转发中心节点的数量少于观战转发节点的数量。 0126 在一些实施例中， 所述战斗数据包括： 包含指定视频帧数的

49、合包数据； 所述发送单 元具体可以用于： 0127 每间隔预设时长通过战斗节点向关联的观战转发中心节点发送所述合包数据。 0128 由上可知， 本实施例的游戏集群管理装置， 当接收到目标客户端发送的观战请求 时， 通过确定单元301在通过战斗节点运行指定游戏逻辑的过程中， 确定当前游戏集群中各 观战转发节点关联的观战客户端数量； 当检测到目标客户端发送的观战请求时， 若所有观 战转发节点关联的观战客户端数量均达到上限值， 则通过创建单元302在游戏集群中创建 目标观战转发节点， 并建立目标观战转发节点与目标客户端之间的关联； 当检测到关联的 观战客户端数量少于预设值的空闲观战转发节点时， 通过

50、移除单元303移除空闲观战转发 节点。 该游戏集群管理装置可以对账户中虚拟资源量不足的用户提示其提前补充虚拟资 源， 以使在执行虚拟资源转移操作时保证账户中虚拟资源充足， 提升了游戏集群管理的智 能性和准确性， 避免了因虚拟资源不足对网络直播、 网络游戏中的情景玩法的结果造成不 良影响。 说明书 9/12 页 12 CN 112148495 A 12 0129 相应的， 本申请实施例还提供一种电子设备， 该电子设备可以为服务器或服务器 集群。 如图4所示， 图4为本申请实施例提供的电子设备的结构示意图。 该电子设备400包括 有一个或者一个以上处理核心的处理器401、 有一个或一个以上计算机可