CN112181431A - 一种分布式数据打包方法及系统、存储介质、计算设备 - Google Patents
一种分布式数据打包方法及系统、存储介质、计算设备 Download PDFInfo
- Publication number
- CN112181431A CN112181431A CN202011060896.4A CN202011060896A CN112181431A CN 112181431 A CN112181431 A CN 112181431A CN 202011060896 A CN202011060896 A CN 202011060896A CN 112181431 A CN112181431 A CN 112181431A
- Authority
- CN
- China
- Prior art keywords
- task
- task execution
- data packaging
- server
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
- G06F8/456—Parallelism detection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
- G06F8/453—Data distribution
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明提供了一种分布式数据打包方法及系统、存储介质、计算设备,该方法包括:基于预设的主控服务器生成包括多个数据打包任务的任务分配清单文件;将所述任务分配清单文件中的多个数据打包任务划分为多个任务组;将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务。基于本发明提供的方法将原有的打包工作拆分成可分配的工作,每个任务执行服务器均可以独立地、互不影响地完成部分压缩包的打包工作,从而有效提升数据打包的效率。
Description
技术领域
本发明涉及数据处理技术领域,特别是一种分布式数据打包方法及系统、存储介质、计算设备。
背景技术
在Unity引擎中,Asset Bundle(以下简称AB)压缩包提供了一种压缩的数据格式,可以索引和序列化多个文件,因为其流式加载、增量更新等特性,可广泛应用于游戏制作及游戏安装包的生成。
在Unity引擎传统的打包方式中,是以单线程的方式基于压缩包所需的信息逐个调用指定函数编译压缩包,且只有在特定情况下才会开启并行线程执行打包任务。但是,对于一些比较大项目,如果继续以单线程的方式打包数据包则需要等待较长时间,从而降低打包流程效率。如果采用并行线程,打包过程中的文件,使用完全相同的名字,则很容易造成任务冲突,不仅影响打包效率,而且还无法有效完成打包任务。
发明内容
鉴于上述问题,提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的分布式数据打包方法及系统、存储介质、计算设备。
根据本发明的一个方面,提供了一种分布式数据打包方法,包括:
基于预设的主控服务器生成包括多个数据打包任务的任务分配清单文件;
将所述任务分配清单文件中的多个数据打包任务划分为多个任务组;
将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务。
可选地,所述基于预设的主控服务器生成包括多个数据打包任务的任务分配清单文件,包括:
启动预设的主控服务器的主Unity引擎,并通过所述主Unity引擎监听数据打包请求;
当所述主Unity引擎监听到任一数据打包请求时,获取各所述数据打包请求对应的压缩包的配置信息和资源信息;其中,所述配置信息包括压缩包生成路径、压缩包数量、编译选项、压缩包的资源信息和各压缩包之间的依赖关系中至少之一;
基于各所述压缩包的配置信息和资源信息生成任务分配清单文件。
可选地,所述将所述任务分配清单文件中的多个数据打包任务划分为多个任务组,包括:
读取所述任务分配清单文件中的任务数量,并计算每次进行任务分配时的分配任务数量;
依据所述分配任务数量将所述任务分配清单文件中的多个数据打包任务划分为多组任务组。
可选地,所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务,包括:
分别向各所述任务执行服务器分配任务组,并将各所述任务执行服务器的工作状态设定为锁定状态,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务;其中,每次向各所述任务执行服务器分配一组任务组;
接收任一所述任务执行服务器返回的任务完成消息,并将所述任务执行服务器的工作状态设定为未锁定状态。
可选地,所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务,还包括:
在各所任务执行服务器执行数据打包任务期间,间隔预设时间查询各所述任务执行服务器的工作状态;
若查询到任一所述任务执行服务器的工作状态为未锁定状态,则继续向该任务执行服务器分配新的任务组,由该任务执行服务器执行所接收到的新的任务组中的数据打包任务。
可选地,所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务,包括:
将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器启动Unity引擎,基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
可选地,所述将各所述任务组分配至预设的多个任务执行服务器之前,还包括:
向各所述任务执行服务器发送启动Unity引擎的第一通知消息;
所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务,包括:
将各所述任务组分配至预设的多个任务执行服务器,由所述任务执行服务器基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
可选地,所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务之后,还包括:
判断所述任务分配清单文件中的数据打包任务是否分配完成;
若是,则向各所述任务执行服务器发送关闭Unity引擎的第二通知消息。
根据本发明的另一个方面,提供了一种分布式数据打包系统,包括:
分配清单生成模块,适于基于预设的主控服务器生成包括多个数据打包任务的任务分配清单文件;
任务划分模块,适于将所述任务分配清单文件中的多个数据打包任务划分为多个任务组;
任务分配模块,适于将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务。
可选地,所述分配清单生成模块还适于:
启动预设的主控服务器的主Unity引擎,并通过所述主Unity引擎监听数据打包请求;
当所述主Unity引擎监听到任一数据打包请求时,获取各所述数据打包请求对应的压缩包的配置信息和资源信息;其中,所述配置信息包括压缩包生成路径、压缩包数量、编译选项、压缩包的资源信息和各压缩包之间的依赖关系中至少之一;
基于各所述压缩包的配置信息和资源信息生成任务分配清单文件。
可选地,所述任务划分模块还适于:
读取所述任务分配清单文件中的任务数量,并计算每次进行任务分配时的分配任务数量;
依据所述分配任务数量将所述任务分配清单文件中的多个数据打包任务划分为多组任务组。
可选地,所述任务分配模块还适于:
分别向各所述任务执行服务器分配任务组,并将各所述任务执行服务器的工作状态设定为锁定状态,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务;其中,每次向各所述任务执行服务器分配一组任务组;
接收任一所述任务执行服务器返回的任务完成消息,并将所述任务执行服务器的工作状态设定为未锁定状态。
可选地,所述任务分配模块还适于:
在各所任务执行服务器执行数据打包任务期间,间隔预设时间查询各所述任务执行服务器的工作状态;
若查询到任一所述任务执行服务器的工作状态为未锁定状态,则继续向该任务执行服务器分配新的任务组,由该任务执行服务器执行所接收到的新的任务组中的数据打包任务。
可选地,所述任务分配模块还适于:
将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器启动Unity引擎,基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
可选地,所述系统还包括:
第一通知模块,适于向各所述任务执行服务器发送启动Unity引擎的第一通知消息;
所述任务分配模块,还适于将各所述任务组分配至预设的多个任务执行服务器,由所述任务执行服务器基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
可选地,所述系统还包括:
第二通知模块,适于判断所述任务分配清单文件中的数据打包任务是否分配完成;
当所述任务分配清单文件中的数据打包任务分配完成时,向各所述任务执行服务器发送关闭Unity引擎的第二通知消息。
根据本发明的又一个方面,还提供了一种计算机可读存储介质,所述计算机可读存储介质用于存储程序代码,所述程序代码用于执行上述任一项所述的分布式数据打包方法。
根据本发明的又一个方面,还提供了一种计算设备,所述计算设备包括处理器以及存储器:
所述存储器用于存储程序代码,并将所述程序代码传输给所述处理器;
所述处理器用于根据所述程序代码中的指令执行上述任一项所述的分布式数据打包方法。
本发明提供了一种分布式数据打包方法及系统、存储介质、计算设备,在本发明提供的方法中,通过预设的主控服务器的主Unity引擎生成任务分配清单文件,并将任务分配清单文件中的多个数据打包划分为多组任务组后,分配至各预设的任务执行服务器并各自执行接收到的任务组中的数据打包任务。基于本发明提供的方法没有将Unity引擎的原始打包过程修改为多线程执行,而是分配到多个进程并行完成打包过程,即,将原有的打包工作拆分成可分配的工作,每个任务执行服务器均可以独立地、互不影响地完成部分压缩包的打包工作,从而有效提升数据打包的效率。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
根据下文结合附图对本发明具体实施例的详细描述,本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1示出了根据本发明一实施例的分布式数据打包方法流程示意图;
图2示出了根据本发明另一实施例的分布式数据打包方法流程示意图;
图3示出了根据本发明另一实施例的分布式数据打包操作界面示意图;
图4示出了根据本发明一实施例的分布式数据打包系统结构示意图;
图5示出了根据本发明另一实施例的分布式数据打包系统结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
本发明实施例提供了一种分布式数据打包方法,参见图1可知,本发明实施例提供的分布式数据打包方法可以包括:
步骤S102,基于预设的主控服务器生成包括多个数据打包任务的任务分配清单文件。
在本发明实施例中,主控服务器作为Master进程,其可以设置有主Unity引擎,在进行数据打包时,可以通过主控服务器中的主Unity引擎生成包括多个数据打包任务的任务分配清单文件。实际应用中,可以根据不同的需求设置一个或多个主控服务器,各主控服务器中均可设置有主Unity引擎。
在本发明一可选实施例中,主控服务器可以对应于设置有Unity引擎的计算机设备,主控服务器对应Unity引擎作为主Unity引擎,基于主控服务器生成任务分配清单文件时,可先启动预设的主控服务器的主Unity引擎,并通过主Unity引擎监听数据打包请求;当主Unity引擎监听到任一数据打包请求时,获取各数据打包请求对应的压缩包的配置信息和资源信息,进而基于各压缩包的配置信息和资源信息生成任务分配清单文件。主Unity引擎可以实时监听数据打包请求或是间隔一定时间监听数据打包请求,每次监听到的数据打包请求之后,即可获取对应的压缩包的相关信息,以生成任务分配清单文件。其中,任务分配清单文件中包括的打包任务的数量不限,具体可以所监听到的数据打包请求进行变化,本发明对此不做限定。
可选地,配置信息包括压缩包生成路径、压缩包数量、编译选项、压缩包的资源信息和各压缩包之间的依赖关系中至少之一。压缩包的资源可包括图片、文字、声效和音乐等等;当然,除上述介绍的之外,压缩包的配置信息和资源信息还可以包括与压缩包相关的其他信息,如压缩包名称、图标名和图标等等,本发明对此不做限定。
步骤S104,将任务分配清单文件中的多个数据打包任务划分为多个任务组。
在本发明实施例中任务分配清单文件中可能具有多个数据打包任务,此时,需要先读取任务分配清单文件中的任务数量,并计算每次进行任务分配时的分配任务数量;进而依据分配任务数量将任务分配清单文件中的多个数据打包任务划分为多组任务组。
举例来讲,假设任务分配清单文件中具有600个压缩包的数据打包任务,可以计算每次进行任务分配时的分配任务数量为100,则一共可划分为6个任务组。实际应用中,对于每次进行任务分配时的分配任务数量可以根据每个任务执行服务器的处理能力或是数据任务的数量进行计算,本发明对此不做限定。
步骤S106,将各任务组分配至预设的多个任务执行服务器,由各任务执行服务器执行各自接收到的任务组中的数据打包任务。
在本发明实施例中,任务执行服务器作为Worker进程,各任务执行服务器同样可以对应多台计算设备,用于执行主控服务器Master进程分配的任务。其中,任务执行服务器可以包括多个,具体数量可以根据不同的需要进行设置。
在本发明一可选实施例中,可先分别向各任务执行服务器分配任务组,并将各任务执行服务器的工作状态设定为锁定状态,由各任务执行服务器执行各自接收到的任务组中的数据打包任务。并且,还可以接收任一任务执行服务器返回的任务完成消息,并将任务执行服务器的工作状态设定为未锁定状态。
一般情况下,对于每个任务执行服务器来讲,其可能具有两种工作状态,一种为状锁定态,另一种为未锁定状态,锁定状态,表示该任务执行服务器正在执行主控服务器分配的数据打包任务;未锁定状态表示该任务执行服务器未进行数据打包任务。基于本发明实施例提供的方法,通过将已分配任务组的任务执行服务器进行工作状态的设置,可以有效监控各进程进行工作状态的任务执行状态。
本发明实施例中,每次向各任务执行服务器分配一组任务组。举例来讲,假设有三个任务执行服务器,则每次向各任务执行服务器分一组任务组,避免由于打包任务太多而造成任务执行服务器的负荷太重。但是,在实际应用中,任务组的数量可能与任务执行服务器的数量不匹配。各任务执行服务器接收到主控服务器分配的任务组之后,即可各自独立地、互不影响地完成部分压缩包的打包工作,从而有效提升压缩包的数据打包的效率。
可选地,当任务组的数量小于或等于任务执行服务器的数量时,可以在多个任务执行服务器随机选择与任务组的数量匹配的任务执行服务器以进行任务组的分配。
当任务组的数量大于任务执行服务器的数量时,则可能需要向各任务执行服务器多次分配任务组,向任一任务执行服务器再次分配任务组时,需要对该任务执行服务器的任务执行状态进行检测。
在本发明可选实施例中,还可以在各所任务执行服务器执行数据打包任务期间,间隔预设时间查询各任务执行服务器的工作状态;若查询到任一任务执行服务器的工作状态为未锁定状态,则继续向该任务执行服务器分配新的任务组,由该任务执行服务器执行所接收到的新的任务组中的数据打包任务。其中,预设时间可根据不同的需求进行设置,如0.1秒或是其他时间,本发明对此不做限定。
向该任务执行服务器分配新的任务组之后,同样需要将其工作状态设定为锁定状态,并且在接收到其返回的任务执行完成的消息时,再次将其工作状态设定为未锁定状态,以便后续再次分配任务组。
基于本发明实施例提供的方法,通过选取处于未锁定状态的任务执行服务器再次分配任务组,可以有效减少在任务执行服务器执行打包任务时的等待时间,从而提升任务分配效率及任务执行效率。
在本发明实施例中,各任务执行服务器中同样具有Unity引擎,因此,任务进程执行数据打包任务时,可以基于各自的Unity引擎进行。
实际应用中,任务进程执行数据打包任务之前,需要先启动自的Unity引擎,本发明可选实施例提供了两种Unity引擎启动方式。
一、任务进程接收到的数据打包任务时启动Unity引擎
也就是说,上述步骤S106可进一步包括将各任务组分配至预设的多个任务执行服务器,由任务执行服务器启动Unity引擎,基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
在本发明实施例中,任务执行服务器在接收到主控服务器分配的任务组之后启动Unity引擎,以执行该任务组中的数据打包任务。本实施例中,任务执行服务器只有在接收到数据打包任务时才会启动Unity引擎,从而减少因过早启动Unity引擎的资源占用。
二、接收到的数据打包任务之前启动Unity引擎
在本发明实施例中,在上述步骤S106将各任务组分配至预设的多个任务执行服务器之前,可以向各任务执行服务器发送启动Unity引擎的第一通知消息,当各任务执行服务器接收到该第一通知消息之后,即可启动各自的Unity引擎。可选地,该第一通知消息可以是与上述步骤S102生成任务分配清单文件之前进行执行,也可以在其之后或他同步进行,本发明对此不做限定。
进一步地,上述步骤S106就可以包括将各任务组分配至预设的多个任务执行服务器,由任务执行服务器基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
本发明实施例提供的方法,通过预先发送第一通知消息通知任务执行服务器发送启动Unity引擎,可以节省每次启动Unity引擎的时间,并且,当任务执行服务器接收到数据打包任务之后,可立即执行数据打包任务,而无需等待Unity引擎启动,从而有效降低数据打包任务的执行时间,提升数据打包效率。
在本发明另一可选实施例中,还可以判断任务分配清单文件中的数据打包任务是否分配完成;若是,则向各任务执行服务器发送关闭Unity引擎的第二通知消息。若否,则继续进行任务分配。基于本发明实施例提供的方法可以在任务分配清单文件的打包任务分配完成后,及时通知任务执行服务器发送关闭Unity引擎,从而可以有效降低资源占用,节省能耗。
图2是根据本发明另一实施例的分布式数据打包方法流程示意图,如图2所示,本发明实施例提供的方法中,主控服务器作为Master服务器,任务执行服务器作为Worker服务器,采用分布式打包的方式实现在数据打包。图2仅示意性示出了任务执行服务器1和任务执行服务器2,实际应用中,任务执行服务器的数量可以根据不同的需求设置多个(两个或两个以上)。参见图2,本发明实施例提供的方法可以包括:
S1,主控服务器向所有任务执行服务器发送启动Unity引擎的第一通知消息。各任务执行服务器接收到第一通知消息后,启动各自的Unity引擎,并开始监听数据打包任务。本实施例在向各任务执行服务器分配数据打包任务之前通知各任务执行服务器启动Unity引擎,可以减少每次执行数据打包任务时启动Unity引擎的时间。
实际应用中,Master可以调用build job触发worker启动Unity引擎的操作,而Worker在打开相应的场景后,会调用Unlock,开始监听打包任务。也就是说,Worker完成Unity引擎启动后,可以调用UnLock,表示自身的工作状态状态为未锁定状态,即,Master可以向该Worker分配数据打包任务。
S2,启动主控服务器的主Unity引擎。一般情况下,主控服务器可以是指定计算设备,当通知任务执行服务器启动Unity引擎之后,或是同步更新主控服务器的工程,并启动主控服务器的Unity引擎,监听数据打包请求。
S3,生成任务分配清单文件。
本发明实施例提供的分布式数据打包方式中,将原本Unity生成Asset Bundle(以下简称AB)包的流程,替换成生成分配清单文件distribute.manifest的流程。这部分修改,是在BuildAssetBundlesInternal中完成,distribute.manifest记录了CalculateAssetBundlesToBeBuilt计算的编译AB包需要的所有信息,而不再做生成AB包的流程。此部分实现代码可以如下:
在本发明实施例中,任务分配清单文件用yaml格式编写,其中记录了AB包资源信息和配置信息,以下示意性提供了任务分配清单文件的内容:
outputPath(AB包的生成路径):
S4,判断任务分配清单文件中是否有数据打包任务;若是,则执行步骤S5;若否,则执行步骤S6。
S5,向任务执行服务器分配数据打包任务;
Master分配数据打包任务时,会依次执行如下流程:
S5-1,读取任务分配清单文件中的任务数量workCount(每个任务对应一个AB包的数据打包任务),计算出每次要分配的任务数量worksPerNode;
S5-2,每0.1秒通过isLocked查询各Worker是否在执行数据打包任务;
S5-3,如果任一Worker正在执行数据打包任务,继续等待,否则分配数据打包任务给该Worker。
S6,向所有任务执行服务器发出退出Unity引擎的第二通知消息。各任务执行服务器接收到第一通知消息后,退出各自的Unity引擎,并结束监听数据打包任务。
Master在分配完所有任务后,会等待所有Worker完成打包任务,等待完成后,会发送-1-1通知所有的Worker结束监听状态,并退出Unity引擎。
在本发明实施例中,任一Worker监听数据打包任务时,会依次执行如下流程:
1.是否分配了任务给这个Worker,由Worker是否锁定(Lock)来确定,当Worker为锁定(Lock)状态,即表示Master给Worker分配了任务。Worker在没有分配任务时(处于Unlock状态)就继续等待;
2.Worker接收到数据打包任务后,Worker会读取其中的AB包编译范围信息,以及分配清单路径,以及分配清单中的信息;
3.Worker编译startWorkIndex到endWorkIndex之间的AB包。
可选地,Worker监听数据打包任务的实现代码可以如下:
本发明实施例提供的数据打包方法,没有将Unity引擎的原始打包过程修改为多线程执行,而是分配到多个进程并行完成打包过程,即,将原有的打包工作拆分成可分配的工作,每个任务执行服务器均可以独立地、互不影响地完成部分压缩包的打包工作,从而有效提升数据打包的效率。
本发明实施例还提供了采用本发明实施例所提供的分布式数据打包方法和传统的数据打包方法对比示例。当主控服务器启动Unity引擎之后,可以通过distribute-android-assetbundle-master开启打包任务,此时可以展示图3所示界面,用户可以设置每次分配的AB包数量(MAX_WORKES_PER_NODE),是否强制编译库文件(FORCE_REBUILD_LIBRARY),是否完全重新生成AB包(FORCE_REBUILD_ASSETBUNDLES),是否分配(ENABLE_DISTRIBUTE),若不选择分配会退化到Unity引擎原始打包流程,以及可以跳过各个阶段的参数。
启动之后,会依次执行准备阶段、创建清单阶段、分配任务阶段以及创建游戏阶段。
准备阶段,Master更新工程,并通知worker更新工程,启动Unity引擎,并调用命令开始监听任务;
创建清单阶段,master调用命令行启动master生成分配清单
分配任务阶段,以每次分配100个AB包为例,本发明实施例的worker可以部署3台机器。
创建游戏阶段,生成最后的游戏包,该游戏包可被用户下载安装。
如上所述,用户可以关闭ENABLE_DISTRIBUTE来退化到原始的打包流程,我们可以用它来比较原生打包流程和分布式打包流程的效率。表1和表2分别是采用原始数据打包流程和分布式数据打包流程的打包时间,其中,表2所示分布式数据打包流程使用了3个worker。
表1
准备阶段 | 创建清单阶段 | 分配任务阶段 | 创建游戏阶段 |
1分9秒 | 1小时12分 | 553毫秒 | 26分45秒 |
1分0秒 | 1小时13分 | 512毫秒 | 25分1秒 |
表2
通过分析表1、表2可知,原生流程的打包平均时间是72分钟(即只计算创建清单阶段对应的时间),分布式数据打包流程的打包时间需要创建清单阶段和分配任务阶段的时间之和,其平均时间是44分钟,速度相较于原生的打包流程优化了40%。实际应用中,分布式数据打包流程中的Worker部署越多,分配任务阶段所花的时间就会越少,本文的示例只部署了3个Worker,实际应用中可根据不同的打包需求进行设置,本发明对此不做限定。
基于同一发明构思,本发明实施例还提供了一种分布式数据打包系统,如图4所示,该系统可以包括:
分配清单生成模块410,适于基于预设的主控服务器生成包括多个数据打包任务的任务分配清单文件;
任务划分模块420,适于将任务分配清单文件中的多个数据打包任务划分为多个任务组;
任务分配模块430,适于将各任务组分配至预设的多个任务执行服务器,由各任务执行服务器执行各自接收到的任务组中的数据打包任务。
在本发明一可选实施例中,分配清单生成模块410还适于:
启动预设的主控服务器的主Unity引擎,并通过主Unity引擎监听数据打包请求;
当主Unity引擎监听到任一数据打包请求时,获取各数据打包请求对应的压缩包的配置信息和资源信息;其中,配置信息包括压缩包生成路径、压缩包数量、编译选项、压缩包的资源信息和各压缩包之间的依赖关系中至少之一;
基于各压缩包的配置信息和资源信息生成任务分配清单文件。
在本发明一可选实施例中,任务划分模块420还适于:
读取任务分配清单文件中的任务数量,并计算每次进行任务分配时的分配任务数量;
依据分配任务数量将任务分配清单文件中的多个数据打包任务划分为多组任务组。
在本发明一可选实施例中,任务分配模块430还适于:
分别向各任务执行服务器分配任务组,并将各任务执行服务器的工作状态设定为锁定状态,由各任务执行服务器执行各自接收到的任务组中的数据打包任务;其中,每次向各任务执行服务器分配一组任务组;
接收任一任务执行服务器返回的任务完成消息,并将任务执行服务器的工作状态设定为未锁定状态。
在本发明一可选实施例中,任务分配模块430还适于:
在各所任务执行服务器执行数据打包任务期间,间隔预设时间查询各任务执行服务器的工作状态;
若查询到任一任务执行服务器的工作状态为未锁定状态,则继续向该任务执行服务器分配新的任务组,由该任务执行服务器执行所接收到的新的任务组中的数据打包任务。
在本发明一可选实施例中,任务分配模块430还适于:
将各任务组分配至预设的多个任务执行服务器,由各任务执行服务器启动Unity引擎,基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
在本发明一可选实施例中,如图5所示,该系统还可以包括:
第一通知模块440,适于向各任务执行服务器发送启动Unity引擎的第一通知消息;
任务分配模块430,还适于将各任务组分配至预设的多个任务执行服务器,由任务执行服务器基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
在本发明一可选实施例中,该系统还可以包括:
第二通知模块450,适于判断任务分配清单文件中的数据打包任务是否分配完成;
当任务分配清单文件中的数据打包任务分配完成时,向各任务执行服务器发送关闭Unity引擎的第二通知消息。
在本发明一可选实施例中,还提供了一种计算机可读存储介质,计算机可读存储介质用于存储程序代码,程序代码用于执行上述一实施例的分布式数据打包方法。
在本发明一可选实施例中,还提供了一种计算设备,计算设备包括处理器以及存储器:
存储器用于存储程序代码,并将程序代码传输给处理器;
处理器用于根据程序代码中的指令执行权上述一实施例的分布式数据打包方法。
所属领域的技术人员可以清楚地了解到,上述描述的系统、装置、模块和单元的具体工作过程,可以参考前述方法实施例中的对应过程,为简洁起见,在此不另赘述。
另外,在本发明各个实施例中的各功能单元可以物理上相互独立,也可以两个或两个以上功能单元集成在一起,还可以全部功能单元都集成在一个处理单元中。上述集成的功能单元既可以采用硬件的形式实现,也可以采用软件或者固件的形式实现。
本领域普通技术人员可以理解:所述集成的功能单元如果以软件的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,其包括若干指令,用以使得一台计算设备(例如个人计算机,服务器,或者网络设备等)在运行所述指令时执行本发明各实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM)、随机存取存储器(RAM),磁碟或者光盘等各种可以存储程序代码的介质。
或者,实现前述方法实施例的全部或部分步骤可以通过程序指令相关的硬件(诸如个人计算机,服务器,或者网络设备等的计算设备)来完成,所述程序指令可以存储于一计算机可读取存储介质中,当所述程序指令被计算设备的处理器执行时,所述计算设备执行本发明各实施例所述方法的全部或部分步骤。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:在本发明的精神和原则之内,其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案脱离本发明的保护范围。
Claims (11)
1.一种分布式数据打包方法,其特征在于,包括:
基于预设的主控服务器生成包括多个数据打包任务的任务分配清单文件;
将所述任务分配清单文件中的多个数据打包任务划分为多个任务组;
将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务。
2.根据权利要求1所述的方法,其特征在于,所述基于预设的主控服务器生成包括多个数据打包任务的任务分配清单文件,包括:
启动预设的主控服务器的主Unity引擎,并通过所述主Unity引擎监听数据打包请求;
当所述主Unity引擎监听到任一数据打包请求时,获取各所述数据打包请求对应的压缩包的配置信息和资源信息;其中,所述配置信息包括压缩包生成路径、压缩包数量、编译选项、压缩包的资源信息和各压缩包之间的依赖关系中至少之一;
基于各所述压缩包的配置信息和资源信息生成任务分配清单文件。
3.根据权利要求1所述的方法,其特征在于,所述将所述任务分配清单文件中的多个数据打包任务划分为多个任务组,包括:
读取所述任务分配清单文件中的任务数量,并计算每次进行任务分配时的分配任务数量;
依据所述分配任务数量将所述任务分配清单文件中的多个数据打包任务划分为多组任务组。
4.根据权利要求1所述的方法,其特征在于,所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务,包括:
分别向各所述任务执行服务器分配任务组,并将各所述任务执行服务器的工作状态设定为锁定状态,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务;其中,每次向各所述任务执行服务器分配一组任务组;
接收任一所述任务执行服务器返回的任务完成消息,并将所述任务执行服务器的工作状态设定为未锁定状态。
5.根据权利要求4所述的方法,其特征在于,所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务,还包括:
在各所任务执行服务器执行数据打包任务期间,间隔预设时间查询各所述任务执行服务器的工作状态;
若查询到任一所述任务执行服务器的工作状态为未锁定状态,则继续向该任务执行服务器分配新的任务组,由该任务执行服务器执行所接收到的新的任务组中的数据打包任务。
6.根据权利要求1所述的方法,其特征在于,所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务,包括:
将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器启动Unity引擎,基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
7.根据权利要求1所述的方法,其特征在于,所述将各所述任务组分配至预设的多个任务执行服务器之前,还包括:
向各所述任务执行服务器发送启动Unity引擎的第一通知消息;
所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务,包括:
将各所述任务组分配至预设的多个任务执行服务器,由所述任务执行服务器基于各自的Unity引擎执行接收到的任务组中的数据打包任务。
8.根据权利要求6或7所述的方法,其特征在于,所述将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务之后,还包括:
判断所述任务分配清单文件中的数据打包任务是否分配完成;
若是,则向各所述任务执行服务器发送关闭Unity引擎的第二通知消息。
9.一种分布式数据打包系统,其特征在于,包括:
分配清单生成模块,适于基于预设的主控服务器生成包括多个数据打包任务的任务分配清单文件;
任务划分模块,适于将所述任务分配清单文件中的多个数据打包任务划分为多个任务组;
任务分配模块,适于将各所述任务组分配至预设的多个任务执行服务器,由各所述任务执行服务器执行各自接收到的任务组中的数据打包任务。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质用于存储程序代码,所述程序代码用于执行权利要求1-8中任一项所述的分布式数据打包方法。
11.一种计算设备,其特征在于,所述计算设备包括处理器以及存储器:
所述存储器用于存储程序代码,并将所述程序代码传输给所述处理器;
所述处理器用于根据所述程序代码中的指令执行权利要求1-8中任一项所述的分布式数据打包方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011060896.4A CN112181431A (zh) | 2020-09-30 | 2020-09-30 | 一种分布式数据打包方法及系统、存储介质、计算设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011060896.4A CN112181431A (zh) | 2020-09-30 | 2020-09-30 | 一种分布式数据打包方法及系统、存储介质、计算设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN112181431A true CN112181431A (zh) | 2021-01-05 |
Family
ID=73947360
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011060896.4A Pending CN112181431A (zh) | 2020-09-30 | 2020-09-30 | 一种分布式数据打包方法及系统、存储介质、计算设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112181431A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112732317A (zh) * | 2021-01-11 | 2021-04-30 | 珠海金山网络游戏科技有限公司 | 加快基于Unity 3D项目出包速度的方法、装置及介质 |
CN113922953A (zh) * | 2021-09-30 | 2022-01-11 | 联想(北京)有限公司 | 一种数据处理方法及装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130263142A1 (en) * | 2012-03-27 | 2013-10-03 | Fujitsu Limited | Control device, control method, computer readable recording medium in which program is recorded, and distributed processing system |
CN109614232A (zh) * | 2018-12-07 | 2019-04-12 | 网易(杭州)网络有限公司 | 任务处理方法、装置、存储介质和电子装置 |
CN109865292A (zh) * | 2019-01-10 | 2019-06-11 | 珠海金山网络游戏科技有限公司 | 一种基于游戏引擎的游戏资源构建方法和装置 |
CN110069278A (zh) * | 2019-03-25 | 2019-07-30 | 福州智永信息科技有限公司 | 一种自动化分布式多任务打包方法及系统 |
CN110134430A (zh) * | 2019-04-12 | 2019-08-16 | 中国平安财产保险股份有限公司 | 一种数据打包方法、装置、存储介质和服务器 |
-
2020
- 2020-09-30 CN CN202011060896.4A patent/CN112181431A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130263142A1 (en) * | 2012-03-27 | 2013-10-03 | Fujitsu Limited | Control device, control method, computer readable recording medium in which program is recorded, and distributed processing system |
CN109614232A (zh) * | 2018-12-07 | 2019-04-12 | 网易(杭州)网络有限公司 | 任务处理方法、装置、存储介质和电子装置 |
CN109865292A (zh) * | 2019-01-10 | 2019-06-11 | 珠海金山网络游戏科技有限公司 | 一种基于游戏引擎的游戏资源构建方法和装置 |
CN110069278A (zh) * | 2019-03-25 | 2019-07-30 | 福州智永信息科技有限公司 | 一种自动化分布式多任务打包方法及系统 |
CN110134430A (zh) * | 2019-04-12 | 2019-08-16 | 中国平安财产保险股份有限公司 | 一种数据打包方法、装置、存储介质和服务器 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112732317A (zh) * | 2021-01-11 | 2021-04-30 | 珠海金山网络游戏科技有限公司 | 加快基于Unity 3D项目出包速度的方法、装置及介质 |
CN112732317B (zh) * | 2021-01-11 | 2024-05-17 | 珠海金山数字网络科技有限公司 | 加快基于Unity 3D项目出包速度的方法、装置及介质 |
CN113922953A (zh) * | 2021-09-30 | 2022-01-11 | 联想(北京)有限公司 | 一种数据处理方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108845884B (zh) | 物理资源分配方法、装置、计算机设备和存储介质 | |
US9319281B2 (en) | Resource management method, resource management device, and program product | |
CN113918270A (zh) | 基于Kubernetes的云资源调度方法及系统 | |
CN108845954B (zh) | 压力测试方法、系统及存储介质 | |
CN112181431A (zh) | 一种分布式数据打包方法及系统、存储介质、计算设备 | |
CN106325966B (zh) | 软件编译方法及装置 | |
CN101131652A (zh) | 多核多中央处理器的执行线程分配方法 | |
JP2019533256A (ja) | アプリケーションリンク拡張方法、装置、及びシステム | |
CN113918281A (zh) | 一种提升容器云资源扩展效率的方法 | |
CN111352726B (zh) | 一种基于容器化微服务的流数据处理方法及装置 | |
CN111163140A (zh) | 资源获取和分配的方法、装置和计算机可读存储介质 | |
CN110737670A (zh) | 一种集群数据一致性的保障方法、装置及系统 | |
CN114389955A (zh) | 嵌入式平台异构资源池化管理方法 | |
CN111158956A (zh) | 一种集群系统的数据备份方法及相关装置 | |
CN116048618A (zh) | 探针处理方法、系统、电子设备和可读存储介质 | |
CN112579145A (zh) | 应用部署方法及装置 | |
CN113590281A (zh) | 基于动态集中式调度的分布式并行模糊测试方法及系统 | |
CN112486502A (zh) | 分布式任务的部署方法、装置、计算机设备和存储介质 | |
CN112463312A (zh) | 一种定时任务的动态维护系统和方法、介质、计算设备 | |
CN112783892A (zh) | 一种通过事件驱动模型实现的链式任务执行引擎 | |
CN113886349A (zh) | 计费系统参数装载共享方法、装置及计算设备 | |
CN114157569A (zh) | 集群系统及其构建方法和构建装置 | |
CA2341331A1 (en) | Computational data processing system and computational process implemented by means of such a system | |
JPH1069402A (ja) | ソフトウェアの自動試験制御方法 | |
CN112328331B (zh) | 一种分区更换应用的方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |