Cloud-computing-based game channel package parallel packaging and task scheduling method and system

Abstract

This invention provides a method and system for parallel packaging and task scheduling of game channel packages based on cloud computing, relating to the field of cloud computing technology. The method includes: acquiring the original game resource package and packaging configuration information for multiple channels; generating packaging tasks for each channel based on the content differences between the two, and aggregating them into a global task queue; splitting each packaging task in the global task queue into multiple sub-tasks according to the resource dependency type of the processing stage; obtaining the resource consumption correlation of the sub-tasks by labeling them; and generating a global task directed acyclic graph by executing each sub-task. This invention improves resource utilization and enhances system scheduling robustness by splitting the game channel package into sub-tasks according to the resource type of the processing stage and combining a dual dynamic rescheduling mechanism of resource backlog migration and task stagnation reset.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a method and system for parallel packaging and task scheduling of game channel packages based on cloud computing. Background Technology

[0002] With the rapid development of the gaming industry, game distribution channels have become increasingly diversified, including official app stores, third-party game platforms, mobile phone manufacturer channels, and advertising channels. To adapt to the access requirements of different channels, game developers need to generate a large number of channel packages with different channel identifiers, SDK configurations, and resource package contents for the same game. In the traditional model, the generation of game channel packages usually adopts a serial packaging method, performing code compilation, resource processing, signing, and other processes for each channel in turn. This serial processing method has obvious efficiency bottlenecks when faced with a surge in the number of channels and frequent version iterations. For a version release of a large mobile game, channel packages covering 200 channels need to be generated. In a traditional single-machine build environment, the complete packaging process of each channel package takes an average of about 30 minutes. Executing 200 channel packages serially would take about 100 hours, far exceeding the version release window. To shorten the packaging cycle, development teams often simply increase the number of build servers and manually allocate different channel packages to different servers for parallel packaging. However, this... The static allocation method has the following technical drawbacks: Due to differences in resource modules contained in each channel package, the consumption of computing, memory, and I / O resources during the packaging process is uneven. The static allocation method cannot dynamically adjust resource allocation based on the actual resource consumption of each packaging task, easily leading to resource imbalance where some build nodes exhaust resources, causing slow task execution, while other nodes remain idle. The overall packaging throughput is limited by the node with the lowest resource utilization. Furthermore, the lack of a unified distributed scheduling mechanism makes it impossible to perform global task splitting and scheduling for a large number of packaging tasks. When a build node fails or a task execution anomaly occurs, the system lacks automatic retry and task migration capabilities, causing packaging tasks on that node to be blocked for extended periods, affecting the overall packaging progress and requiring manual intervention, increasing operational complexity. During the batch generation of channel packages, the packaging task load dynamically changes with the number of channels and version complexity. The existing solution cannot automatically scale the number of build nodes based on real-time load conditions, resulting in insufficient resources during peak periods and wasted resources during off-peak periods. Summary of the Invention

[0003] This invention provides a cloud computing-based method and system for parallel packaging and task scheduling of game channel packages. It involves splitting game channel packages into sub-tasks according to resource types in the processing stage, employing constraint propagation and arc consistency checks for deterministic scheduling, and combining resource backlog migration and task stagnation reset with dual dynamic mechanisms.

[0004] The rescheduling mechanism improves resource utilization for parallel packaging.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] Firstly, a cloud-based method for parallel packaging and task scheduling of game channel packages, the method comprising:

[0007] Step 1: Obtain the original game resource package and packaging configuration information for multiple channels, generate packaging tasks for each channel based on the content differences between the two, and aggregate them into a global task queue.

[0008] Step 2: Based on each packaged task in the global task queue, split it into multiple sub-tasks according to the resource dependency type of the processing stage;

[0009] Step 3: By labeling the subtasks, obtain the resource consumption relationships of the subtasks; by executing each subtask, generate a global directed acyclic graph of tasks.

[0010] Step 4: By constraining and verifying the resource consumption correlation of subtasks and the directed acyclic graph, execution nodes are matched for each subtask to generate a global scheduling table.

[0011] Step 5: Each execution node executes subtasks in parallel through the global scheduling table and the directed acyclic graph, obtains the resource usage changes of each node, and stores them in the cache to generate an execution status table.

[0012] Step 6: Based on the execution status table, identify nodes that are resource-saturated and have a backlog of tasks, remove the unstarted subtasks of the node from the current scheduling table, return to step 4 for reallocation, and update the global scheduling table.

[0013] Step 7: Based on the updated global scheduling table and execution status table, identify nodes that have made no progress in multiple consecutive scheduling cycles, reset the unfinished subtasks of the node to the pending scheduling state, and return to step 4 for reallocation; after all subtasks are completed, extract the results from the cache to generate packages for each channel, and complete parallel packaging and task scheduling.

[0014] Furthermore, the system obtains the original game resource package and packaging configuration information from multiple channels, generates packaging tasks for each channel based on the content differences between the two, and aggregates them into a global task queue, including:

[0015] Step 11: Obtain the original game resource package and the packaging configuration information of each channel. Extract the channel identifier, SDK configuration parameters and signature certificate from the packaging configuration information of each channel, and compare them with the default configuration in the original game resource package to obtain the differentiated configuration information of each channel.

[0016] Step 12: Based on the differentiated configuration information of each channel, merge the differentiated configuration information with the original game resource package to generate a corresponding packaging task for each channel, and obtain a set of packaging tasks for each channel.

[0017] Step 13: Store the packaging tasks in the packaging task sets of each channel into the task queue in order according to the channel identifier, and generate a global task queue.

[0018] Furthermore, each packaged task in the global task queue is split into multiple sub-tasks based on the resource dependency type of the processing stage, including:

[0019] Step 21: Obtain the packaging tasks sequentially from the global task queue to get a set of packaging tasks to be processed;

[0020] Step 22: parse each packaging task in the set of packaging tasks to be processed, and split each packaging task into multiple sub-tasks according to the differences in resource types that each processing stage, such as code compilation, resource processing, and signing packaging, depends on.

[0021] Furthermore, by labeling subtasks, the resource consumption relationships of subtasks are obtained; by executing each subtask, a global directed acyclic graph of tasks is generated, including:

[0022] Step 31: Based on the multiple subtasks that have been split, record the execution order and dependencies of each subtask in the packaging process to obtain a set of subtasks and a subtask dependency table.

[0023] Step 32: Based on the processing stage corresponding to each subtask in the subtask set, obtain the consumption relationship between the stage and CPU, memory and storage resources as the resource consumption feature of the subtask, and add the resource consumption feature to the subtask dependency table to obtain the subtask dependency table with resource consumption feature.

[0024] Step 33: Convert the subtask dependency table with resource consumption characteristics into a graph structure, using subtasks as nodes, execution order dependencies as directed edges, and resource consumption characteristics as node attributes to generate a global task directed acyclic graph.

[0025] Furthermore, by constraining and verifying the resource consumption correlation of subtasks and the directed acyclic graph, execution nodes are matched for each subtask to generate a global scheduling table, including:

[0026] Step 41: Extract the resource consumption characteristics of each subtask from the global task directed acyclic graph, and obtain the current available resource status from each execution node to obtain the subtask resource requirement table and the node available resource table.

[0027] Step 42: Using the subtask resource requirement table and the node available resource table as input, establish resource allocation constraints for each subtask, and gradually narrow down the range of nodes that can be allocated to each subtask through constraint propagation to obtain the candidate node set for each subtask.

[0028] Step 43: Based on the candidate node set of each subtask, perform resource persistence verification, subsequent dependency resource reservation verification and allocation conflict verification in sequence, eliminate node allocation schemes that do not meet any of the verifications, until each subtask retains at least one feasible allocation node, and obtain the feasible allocation scheme of subtask and execution node.

[0029] Step 44: Convert the feasible allocation scheme into a mapping relationship between subtasks and execution nodes, and generate a global scheduling table.

[0030] Furthermore, each execution node executes subtasks in parallel using a global scheduling table and a directed acyclic graph, records changes in its own resource usage, and stores these changes in a cache to generate an execution status table, including:

[0031] Step 51: Obtain the list of subtasks assigned to each execution node from the global scheduling table, and obtain the dependency relationships between subtasks from the global task directed acyclic graph to obtain the set of subtasks to be executed and the dependency constraint table for each node.

[0032] Step 52: Each execution node selects subtasks that meet the dependency conditions from the set of subtasks to be executed according to the dependency constraint table and executes them in parallel. During the execution process, the changes in CPU, memory and storage resources occupied by each node due to the execution of subtasks are recorded in real time to obtain the node resource usage record table.

[0033] Step 53: After each execution node completes its execution, it stores the execution result of the subtask in the result cache area and updates the resource usage status of the corresponding subtask in the node resource usage record table to "completed", thus obtaining the updated node resource usage record table.

[0034] Step 54: Extract the execution status of each subtask and the resource usage status of each node from the updated node resource usage record table to generate an execution status table.

[0035] Furthermore, based on the execution status table, nodes with resource saturation and task backlog are identified. Unstarted subtasks of these nodes are removed from the current scheduling table, and the process returns to step 4 for reallocation to update the global scheduling table, including:

[0036] Step 61: Extract the resource occupancy status and number of unfinished tasks of each node from the execution status table to obtain the load status table of each node.

[0037] Step 62: Based on the load status table of each node, identify the nodes whose resource usage has reached the node capacity limit and whose number of unfinished tasks continues to accumulate, as high-load nodes, and obtain the sub-tasks that have not yet started on the high-load nodes to obtain a list of sub-tasks to be reallocated.

[0038] Step 63: Remove the subtasks in the list of subtasks to be reassigned from the scheduling plan of the high-load node, and return to step 4 to reallocate execution nodes for these subtasks according to the current available resource status of each node, and obtain the reassignment result.

[0039] Step 64: Update the reallocation results to the global scheduling table to obtain the updated global scheduling table.

[0040] Furthermore, based on the updated global scheduling table and execution status table, nodes that have made no progress within multiple consecutive scheduling cycles are identified. The unfinished subtasks of these nodes are reset to a pending scheduling state, and the process returns to step 4 for reallocation. After all subtasks are completed, results are extracted from the cache to generate packages for each channel, completing parallel packaging and task scheduling, including:

[0041] Step 71: Based on the updated global scheduling table and execution status table, extract the execution progress information of the subtasks assigned on each node to obtain the subtask execution progress table for each node.

[0042] Step 72: Based on the subtask execution progress table of each node, identify the node where the subtask has not progressed in multiple consecutive scheduling cycles, and designate it as the fault node. Then, obtain all the subtasks in the incomplete state on the fault node to obtain the list of subtasks to be reset.

[0043] Step 73: Reset the status of each subtask in the list of subtasks to be reset to pending scheduling, and return the reset list of subtasks to Step 4 to reallocate execution nodes, thus obtaining the reallocated global scheduling table.

[0044] Step 74: Iterate through steps 61 to 63 until all subtasks are in the completed state. Extract the execution results of each subtask from the result cache and merge them by channel to generate complete channel packages for each channel, so as to realize parallel packaging and task scheduling of game channel packages.

[0045] Secondly, a cloud-based parallel packaging and task scheduling system for game channel packages includes:

[0046] The acquisition module is used to acquire the original game resource package and the packaging configuration information of multiple channels, generate packaging tasks for each channel based on the content differences between the two, and aggregate them into a global task queue.

[0047] The processing module is used to split each packaged task in the global task queue into multiple subtasks according to the resource dependency type of the processing stage; to obtain the resource consumption association of the subtasks by labeling them; and to generate a global task directed acyclic graph by executing each subtask.

[0048] The verification module is used to constrain and verify the resource consumption correlation of subtasks and the directed acyclic graph, match execution nodes for each subtask, and generate a global scheduling table. Each execution node executes subtasks in parallel through the global scheduling table and the directed acyclic graph, obtains the resource usage changes of each node, and stores them in the cache to generate an execution status table.

[0049] The update module is used to identify nodes with saturated resources and backlogged tasks based on the execution status table, remove the unstarted subtasks of the node from the current scheduling table, and return to step 4 for reallocation to update the global scheduling table.

[0050] The control module is used to identify nodes that have made no progress in multiple consecutive scheduling cycles based on the updated global scheduling table and execution status table, reset the unfinished subtasks of the node to the pending scheduling state and return to step 4 for reallocation; after all subtasks are completed, the results are extracted from the result cache to generate packages for each channel, and parallel packaging and task scheduling are completed.

[0051] The above-described solution of the present invention has at least the following beneficial effects:

[0052] This invention solves the problems of mixed multi-channel configurations and manual errors by accurately merging and generating channel packaging tasks through differentiated configuration and aggregating them into a global queue, achieving precise matching and orderly control of task configurations. It breaks down packaging tasks into sub-tasks based on resource dependencies such as code compilation, resource processing, and signature packaging, and constructs a directed acyclic graph, solving the problems of high process coupling and unclear dependencies, achieving clear responsibilities and traceable dependencies. It uses constraint propagation and arc consistency checks to allocate execution nodes to sub-tasks and generate a global scheduling table, solving the problems of blind resource allocation and unfounded node selection, achieving precise allocation and globally feasible scheduling. Each node executes sub-tasks in parallel according to dependencies and records changes in resource usage in real time to generate an execution status table, solving the problems of execution black boxes and unknown resource usage, achieving process transparency and monitorable status. It identifies high-load nodes, removes unstarted sub-tasks, and reassigns them, solving the problem of difficult load imbalance adjustment, achieving dynamic balancing and resource optimization. It identifies sub-tasks that have stalled for multiple consecutive cycles, resets them, backtracks, reassigns them, and iterates until completion, solving the problems of long-term task suspension and lack of system self-healing after node failure, achieving fault isolation, closed-loop self-healing, and stable and reliable automated large-scale parallel packaging. Attached Figure Description

[0053] Figure 1 This is a flowchart illustrating a cloud-based parallel packaging and task scheduling method for game channel packages provided by an embodiment of the present invention.

[0054] Figure 2 This is a schematic diagram of a cloud computing-based game channel package parallel packaging and task scheduling system provided by an embodiment of the present invention. Detailed Implementation

[0055] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0056] like Figure 1 As shown, an embodiment of the present invention proposes a method for parallel packaging and task scheduling of game channel packages based on cloud computing, the method comprising the following steps:

[0057] Step 1: Obtain the original game resource package and packaging configuration information for multiple channels, generate packaging tasks for each channel based on the content differences between the two, and aggregate them into a global task queue.

[0058] Step 2: Based on each packaged task in the global task queue, split it into multiple sub-tasks according to the resource dependency type of the processing stage;

[0059] Step 3: By labeling the subtasks, obtain the resource consumption relationships of the subtasks; by executing each subtask, generate a global directed acyclic graph of tasks.

[0060] Step 4: By constraining and verifying the resource consumption correlation of subtasks and the directed acyclic graph, execution nodes are matched for each subtask to generate a global scheduling table.

[0061] Step 5: Each execution node executes subtasks in parallel through the global scheduling table and the directed acyclic graph, obtains the resource usage changes of each node, and stores them in the cache to generate an execution status table.

[0062] Step 6: Based on the execution status table, identify nodes that are resource-saturated and have a backlog of tasks, remove the unstarted subtasks of the node from the current scheduling table, return to step 4 for reallocation, and update the global scheduling table.

[0063] Step 7: Based on the updated global scheduling table and execution status table, identify nodes that have made no progress in multiple consecutive scheduling cycles, reset the unfinished subtasks of the node to the pending scheduling state, and return to step 4 for reallocation; after all subtasks are completed, extract the results from the cache to generate packages for each channel, and complete parallel packaging and task scheduling.

[0064] In this embodiment of the invention, differentiated configuration generates channel packaging tasks and aggregates them into a global queue, solving the problems of mixed multi-channel configurations and manual errors, and achieving accurate task matching and orderly controllability; resource dependencies are split into sub-tasks and a directed acyclic graph is constructed to solve the problems of high process coupling and unclear dependencies, and achieve clear responsibilities and traceable dependencies; constraint propagation and arc consistency checks are used to allocate execution nodes and generate a global scheduling table to solve the problems of blind resource allocation and unfounded node selection, and achieve accurate allocation and globally feasible scheduling; each node executes sub-tasks in parallel and records resource usage in real time to generate an execution status table, solving the problems of execution black box and unknown resource usage, and achieving process transparency and status monitoring; high-load nodes are identified and unstarted sub-tasks are removed and reassigned to solve the problem of difficult load imbalance adjustment, and achieve dynamic balancing and resource optimization; sub-tasks that have been stalled for multiple consecutive cycles are identified and reset and backtracked for reassignment until completion, solving the problems of long-term task suspension and lack of system self-healing after node failure, and achieving fault isolation, closed-loop self-healing and stable and reliable automated large-scale parallel packaging.

[0065] In a preferred embodiment of the present invention, step 1 above includes:

[0066] Step 11: Obtain the original game resource package and packaging configuration information for each channel. Extract the channel identifier, SDK configuration parameters, and signing certificate from the packaging configuration information of each channel, and compare them with the default configuration in the original game resource package to obtain the differentiated configuration information for each channel. Specifically, this includes: obtaining the original game resource package from the resource management module of the game development terminal through a preset interface. This original resource package contains all the basic resources required for game operation, including but not limited to game code, core materials, default configuration files, and basic runtime libraries. At the same time, obtaining the packaging configuration information of all channels to be packaged from the channel management module. Each channel corresponds to an independent set of packaging configuration information, and each set of configuration information completely includes the three core contents of channel identifier, SDK configuration parameters, and signing certificate. After obtaining the above two types of basic data, the system starts the configuration comparison process, comparing the packaging configuration information of each channel with the default configuration in the original game resource package item by item, focusing on comparing three core dimensions: first, the channel identifier, to confirm the channel. The system performs several checks: First, it compares the unique identifier with the default identifier in the original resource package. If they don't match, they are marked as different information. Second, it compares the SDK configuration parameters, including the SDK's access path, function switches, and interface parameters. Each parameter is compared with the default SDK configuration in the original resource package. For example, if the default SDK interface timeout in the original resource package is 30 seconds, but a certain channel requires a timeout of 60 seconds, this parameter difference must be accurately extracted. Third, it compares the signature certificate with the encryption algorithm, validity period, and signature key information of the signature certificate provided by the channel, comparing them with the default signature certificate in the original resource package. After the comparison, the system summarizes and organizes the difference information for each channel to form independent different configuration information for each channel. This different configuration information only includes content that is inconsistent with the default configuration of the original resource package and does not include duplicate default configurations. For example, if a channel only has two differences, namely SDK interface parameters and signature certificate, then the different configuration information for that channel only records these two differences, ensuring the accuracy and conciseness of the different information.

[0067] Step 12: Based on the differentiated configuration information of each channel, merge the differentiated configuration information with the original game resource package to generate a corresponding packaging task for each channel, resulting in a set of packaging tasks for each channel. Specifically, this includes: based on obtaining the differentiated configuration information of each channel, accurately merging the differentiated configuration information of each channel with the original game resource package. The merging process follows the principle of differentiated configuration overriding default configuration and default configuration retaining the undifferentiated parts. That is, for content existing in the differentiated configuration, the corresponding default content in the original resource package is replaced with the differentiated configuration; for content not covered in the differentiated configuration, the default content in the original resource package is directly retained, ensuring that the merged resource package meets the access requirements of the channel while retaining the core functions of the game. After the basic resources and content are merged, the system generates a corresponding packaging task for each channel. Each packaging task contains all the instructions and resource association information required to complete the packaging of that channel's package. Specifically, this includes the path of the merged resource package, the channel's differentiated configuration details, the tool path required for packaging, and the step parameters of the packaging process. At the same time, a temporary task identifier is assigned to each packaging task. For all channels to be packaged, the above merging and task generation operations are repeated, ultimately forming a set of packaging tasks for each channel. This task set contains independent packaging tasks for all channels to be packaged, and each task corresponds one-to-one with a corresponding channel. For example, if there are 200 channels to be packaged, then the task set contains 200 independent packaging tasks, each task corresponding to one channel.

[0068] Step 13: Store the packaging tasks from each channel's packaging task set into the task queue sequentially according to their channel identifiers, generating a global task queue. Specifically, this includes: reading the channel identifiers from each channel's packaging tasks; sorting all packaging tasks according to the lexicographical order of the channel identifiers; ensuring that packaging tasks for each channel are not duplicated or omitted during the sorting process; for example, if channel identifiers are arranged in the order of 1, 2, 3...200, then the corresponding packaging tasks are also arranged in that order. After sorting, the system sequentially stores the sorted packaging tasks into the preset task queue, following a first-in, first-out (FIFO) principle, meaning that the first sorted channel's packaging tasks are processed first. Tasks are first stored in the queue, and then sorted tasks follow in sequence to ensure that the order of tasks in the queue is consistent with the order of channels after sorting. When all packaging tasks for all channels are stored in the task queue, the system performs an integrity check on the queue. The check includes whether the number of tasks matches the number of channels to be packaged, whether the identifier of each task is unique, and whether the resource association information of each task is complete. If the check passes, the task queue is the global task queue; if the check fails, the system will return an error message, locate the missing or incorrect tasks, and re-execute steps 12 and 13 until a complete and accurate global task queue is generated.

[0069] In this embodiment of the invention, by employing a differentiated configuration precise extraction and merging mechanism, the technical problems of configuration overlay errors, redundancy, and easy omissions and mismatches in manual configuration during multi-channel packaging are overcome. This achieves the technical effects of precise matching of packaging configurations, a simple and efficient merging process, zero redundancy of differentiated information, and no interference between configurations of different channels. Furthermore, by constructing a standard task scheduling system based on sorting and first-in-first-out queues, the technical problems of disordered packaging task order, incomplete task association information, and difficulty in tracing scheduling failures are overcome. This achieves the technical effects of orderly and reliable task scheduling, automatic verification of queue integrity, full tracking of scheduling status, and precise anomaly location down to the individual task level. Finally, by integrating the above mechanisms into an automated closed-loop process from configuration acquisition to queue generation, the technical problems of multi-channel packaging relying on manual intervention, low batch processing efficiency, and difficulty in scaling up are overcome. This achieves the technical effects of full-process automation, support for large-scale concurrent packaging across channels, and a dual improvement in packaging efficiency and delivery quality.

[0070] In a preferred embodiment of the present invention, step 2 above includes:

[0071] Step 21: Obtain the packaging tasks sequentially from the global task queue to form a set of packaging tasks to be processed. Specifically, this includes: starting the task reading module, temporarily caching each read packaging task according to the first-in-first-out storage principle of the global task queue, and recording the number of tasks read to ensure that the reading process is not duplicated or omitted. For example, if the global task queue contains packaging tasks for 200 channels, stored in order from channel identifier 1 to 200, the system will start from the packaging task with identifier 1 and read the packaging task with identifier 200 sequentially. Each time a task is read, it is stored in the temporary task cache area until all packaging tasks have been read. After all packaging tasks have been read, the system will summarize the tasks in the temporary task cache area to form a set of packaging tasks to be processed.

[0072] Step 22: Analyze each packaging task in the set of packaging tasks to be processed. Based on the differences in resource types required by each processing stage (code compilation, resource processing, and signing / packaging), break down each packaging task into multiple sub-tasks. Specifically, this includes: first, performing a comprehensive and detailed analysis of each individual packaging task, including the version parameters of the packaging tool, compilation environment configuration, resource processing standards, signing rules, etc., to clarify the complete processing stages that the packaging task needs to perform. After analysis, it is confirmed that all channel package packaging processes include three core and indispensable stages: code compilation, resource processing, and signing / packaging. These three stages constitute the complete chain of channel package packaging, and the types of hardware resources required by each stage are significantly different: the core of the code compilation stage is to compile and link the game code to generate an executable. The code compilation stage relies heavily on CPU resources for high-intensity computation, with the number of CPU cores and processing speed directly determining compilation efficiency. The resource processing stage mainly involves compressing, converting, and encrypting game assets, requiring significant memory resources for temporary storage of assets under processing, as well as storage resources for saving processed asset files. The signing and packaging stage integrates and signs the compiled code files and processed resource files to generate the final channel package that meets channel requirements. Based on the resource dependencies of these three core stages, the system adopts a stage-based decomposition approach, precisely dividing each packaging task into three independent subtasks: code compilation subtask, resource processing subtask, and signing and packaging subtask. Each subtask corresponds one-to-one with a core processing stage, ensuring clear responsibilities and well-defined boundaries for each subtask.

[0073] In this embodiment of the invention, by reading and recording the number of packaging tasks sequentially according to the first-in-first-out principle, the problem of incomplete or duplicate task reading is solved, ensuring accurate and orderly transmission of the global task queue. By splitting each packaging task into three independent subtasks based on the resource dependency differences of code compilation, resource processing, and signature packaging, the problems of resource mismatch and low utilization are overcome, and precise matching between subtasks and nodes is achieved. After splitting, the boundaries of subtasks are clear and the dependencies are simplified into a fixed pipeline structure, solving the problems of complex task dependency graphs and difficult state tracking, reducing the complexity of scheduling and management, and facilitating accurate status monitoring and rapid anomaly location. By decoupling the same packaging task into multiple independent subtasks according to the steps, the bottlenecks of insufficient parallelism between different channels and serial blocking within the same channel are eliminated, achieving dual parallelism in both horizontal and vertical directions, and shortening the overall packaging cycle of large-scale channel packages.

[0074] In a preferred embodiment of the present invention, step 3 above includes:

[0075] Step 31: Based on the multiple subtasks, record the execution order dependencies of each subtask in the packaging process to obtain a set of subtasks and a subtask dependency table. Specifically, each subtask has independent execution instructions, independent resource requirements, and an independent execution result feedback mechanism. After being assigned to the corresponding execution node, it can be executed independently, only needing to follow the preset order dependencies, without relying on the execution process of other subtasks. The code compilation subtask is responsible for reading the game code file merged by the channel, and according to the compilation rules specified in the packaging process parameters of the channel, completing code syntax checking, compilation calculation, linking processing, and finally generating an executable intermediate code. The code compilation subtask reads the game asset files merged by the channel and compresses, converts, and encrypts them according to the channel's configuration requirements to ensure they meet the channel's access standards. After processing, it generates standardized resource files and caches them. The signature and packaging subtask reads the intermediate code files generated by the code compilation subtask and the standardized resource files generated by the resource processing subtask. It performs signature calculations according to the channel's signature certificate and signing rules, integrates the two types of files to generate a complete channel package, generates channel package verification information, and finally stores the channel package and verification information in a temporary storage area, providing feedback on the execution status. (Single packaging task) After the breakdown, the system immediately records the execution order dependencies of each subtask. Combined with the inherent logic of the packaging process, it clarifies that the execution order of the three subtasks cannot be reversed, forming a fixed linear dependency: the code compilation subtask, as a fundamental prerequisite for the packaging process, must be executed first, and the corresponding resource processing subtask can only be started after the code compilation subtask has completed and reported success; the corresponding signing and packaging subtask can only be started after the resource processing subtask has completed and reported success, ensuring that the signing and packaging uses correctly processed resource files. The three subtasks form a linear dependency relationship of code compilation, resource processing, and signing and packaging, without any circular dependencies. This is in accordance with the above single... The system follows a process of task parsing, process breakdown, subtask generation, and dependency recording. It performs a breakdown operation on each packaging task in the packaged task set one by one, ensuring that all packaging tasks are accurately broken down. After all packaging tasks are broken down, the system aggregates all generated subtasks to form a subtask set containing all subtasks. Each subtask is assigned a unique subtask identifier and associated with its corresponding packaging task identifier. The system generates a subtask dependency table, using structured storage to record detailed core information for each subtask, including subtask identifier, associated packaging task identifier, corresponding packaging processing stage, subtask identifiers it depends on for execution order, and subtask execution priority.

[0076] Step 32: Based on the processing stage corresponding to each subtask in the subtask set, obtain the consumption relationship between that stage and CPU, memory, and storage resources as the resource consumption feature of the subtask, and add the resource consumption feature to the subtask dependency table to obtain a subtask dependency table with resource consumption features. Specifically, based on the completed subtask set and the subtask dependency table, clarify the packaging task to which each subtask belongs, the corresponding processing stage, and the execution order dependency relationship, and establish a database relating the packaging stage and resource consumption. This database specifically stores the resource consumption standards of the three core stages of code compilation, resource processing, and signing packaging under different scenarios. The CPU consumption of the code compilation stage is positively correlated with the amount of game code, with an average consumption of 0.5 CPU cores / minute for every 1000 lines of code compiled, and an average memory consumption of 512MB / minute. The average memory consumption is 100MB / minute. Memory consumption in the resource processing stage is positively correlated with the resource file size, averaging 1GB of memory / minute for every 1GB of resource file processed. CPU consumption averages 0.3 CPU cores / minute, and storage consumption averages 200MB / minute. CPU consumption in the signing and packaging stage is positively correlated with the package size, averaging 0.2 CPU cores / minute for every 100MB package signed and packaged. Memory consumption averages 256MB / minute, and storage consumption averages 150MB / minute. After the database is established, for each subtask in the subtask set, its corresponding packaging processing stage is first determined. Then, based on this stage, the corresponding resource consumption standard is extracted from the associated database. Combined with the specific task information of the subtask, the specific resource consumption relationship of the subtask is calculated using the corresponding formula. Resource consumption value = (Specific task quantity of subtask ÷ corresponding baseline quantity of consumption standard) × resource unit consumption value of the corresponding stage. The calculation result is the resource consumption characteristic of the subtask. For example, the game code quantity corresponding to a code compilation subtask is 20,000 lines. According to the consumption standard of the code compilation stage in the database, its CPU consumption is (20,000 ÷ 1,000) × 0.5 = 10 CPU cores / minute, memory consumption is (20,000 ÷ 1,000) × 512MB = 10,240MB / minute, and storage consumption is (20,000 ÷ 1,000) × 100MB = 2,000MB / minute. This calculation result accurately reflects the resource consumption of the subtask. After the resource consumption characteristics of all subtasks are calculated, the system adds the resource consumption characteristics of each subtask to the subtask dependency table one by one, supplements and improves the table body content, and finally forms a subtask dependency table with resource consumption characteristics.

[0077] Step 33: Convert the subtask dependency table with resource consumption characteristics into a graph structure. Using subtasks as nodes, execution order dependencies as directed edges, and resource consumption characteristics as node attributes, generate a global directed acyclic graph (DAG). Specifically, this includes: The system starts the graph structure conversion module, using the generated subtask dependency table as the data source, and following preset graph structure mapping rules. During the conversion process, the system first completes the mapping of subtasks to graph nodes, dependencies to directed edges, and resource consumption characteristics to node attributes. Each subtask is mapped to an independent node in the graph structure, with the subtask identifier serving as the unique node identifier, subtask dependencies mapped as directed edges, and resource consumption characteristics stored as node attributes. After mapping, a planar sweep algorithm is used, treating subtask nodes as discrete points on the plane and subtask dependencies as line segments. The sweep operation is performed according to the preset order of subtask execution priority. Before sweeping, the sweep step size is calculated using the following formula: ;in, The planar sweep step size, This represents the total number of subtasks. For dependency coefficients, To set a preset time threshold for sweeping, The average processing time for a single node and its corresponding dependencies is given. Following this sweep step size, each node and its corresponding dependencies are identified one by one, and directed edges are accurately constructed. While constructing directed edges, the system simultaneously performs loop detection based on the detection capabilities of the planar sweep algorithm, as shown in the following formula: Where C is the circular dependency determination value, Let be the directed edge identifier. If there exists a directed edge from subtask i to subtask j, then... =1, if it does not exist. =0; This is the identifier for the reverse directed edge. If there exists a directed edge from subtask j to subtask i, then... =1, if it does not exist. =0, during the sweeping process, when the system identifies a directed edge, it immediately calculates the C value using this formula. If the sweeping finds a directed edge from subtask A to subtask B, then... =1, and there exists a directed edge from subtask B to subtask A. =1, then C=1×1=1≥1, indicating a circular dependency exists; if only a directed edge exists from subtask A to subtask B, then... =1, no reverse edge is If C=0, then C=1×0=0, indicating no circular dependency. If a circular dependency is detected, the system will return an error message, locate the corresponding subtask, re-check the subtask dependency table and correct it. After correction, the sweep, build and check operations are performed again until all subtask nodes are mapped, the directed edges are accurately constructed, and the cycle detection shows C=0, indicating no circular dependency. Then the global task directed acyclic graph is officially generated.

[0078] In this embodiment of the invention, by establishing a database linking the packaging process with resource consumption and calculating the resource consumption characteristics of subtasks based on task volume, the technical problems of vague resource demand estimation, blind resource allocation, and easy resource contention or idleness of nodes in packaging tasks are overcome. This achieves the technical effects of accurate quantification of resource consumption, reliable resource allocation, and improved hardware utilization. The planar sweep algorithm is used to convert the dependency table into a directed acyclic graph structure and a cycle detection formula is introduced to verify circular dependencies in real time. This overcomes the technical problems of difficult manual verification when the dependency relationship is complex, difficulty in automatically identifying circular dependencies, and high risk of scheduling deadlock. This achieves the technical effects of visualized and traceable task dependency relationships, automatic detection and location of circular dependencies, and no risk of deadlock in the scheduling process.

[0079] In a preferred embodiment of the present invention, step 4 above includes:

[0080] Step 41: Extract the resource consumption characteristics of each subtask from the global task directed acyclic graph (DAG), and obtain the current available resource status from each execution node to obtain the subtask resource requirement table and the node available resource table. Specifically, this includes: starting the node traversal module, traversing all subtask nodes in the global task DAG one by one according to the node arrangement order, ensuring that each subtask node is covered without omission. During the traversal, the system reads the resource consumption characteristic attribute inherent to each node. This attribute is the resource consumption data specific to the subtask mentioned in the previous steps. The system sequentially extracts the specific required values ​​of CPU resources, memory resources, and storage resources for each subtask. CPU resources are measured in cores per minute, memory resources in MB per minute, and storage resources in MB per minute, ensuring that all resource values ​​are in the same unit. For example, if the resource consumption characteristics of a code compilation subtask are 10 CPU cores per minute, 10240 MB per minute, and 2000 MB per minute, the system accurately extracts these three specific values, associates them with the unique identifier of the subtask, and then retrieves the subtask from the node using the subtask identifier. In ascending order, the system inputs the identifiers, CPU requirements, memory requirements, and storage requirements of all subtasks into a pre-defined data table, organizes and stores them in the system's temporary database to form a complete subtask resource requirement table. After the subtask resource requirement table is generated, the system sends a resource status collection instruction to all online execution nodes. This instruction includes requirements such as collection time, collection items, and data return format. Upon receiving the instruction, each execution node immediately starts the resource collection module to collect its current available CPU core count, available memory capacity, and available storage capacity in real time. The number of CPU cores is rounded to an integer, and memory and storage capacities are in MB. After collection, each execution node returns the collected available resource data to the system in real time according to the format required by the instruction. After receiving the available resource data returned by all execution nodes, the system deduplicates and verifies the data, removes abnormal data, and organizes and inputs the identifier, available CPU core count, available memory capacity, and available storage capacity of each execution node into a data table in ascending order, generating a node available resource table.

[0081] Step 42: Using the subtask resource requirement table and the node available resource table as input, resource allocation constraints are established for each subtask. Constraint propagation gradually narrows down the range of nodes that can be allocated to each subtask, resulting in a candidate node set for each subtask. Specifically, the subtask resource requirement table and the node available resource table are simultaneously used as input data and loaded into the resource constraint matching module via a data interface. After loading, the module automatically associates the data in the two tables, establishing a temporary correspondence between subtask identifiers and node identifiers. For each subtask, the system, relying on the resource constraint matching module, establishes three strict resource allocation constraints. All three constraints are indispensable: the CPU resources required by the subtask are less than or equal to the number of available CPU cores on the execution node; the memory resources required by the subtask are less than or equal to the available memory capacity on the execution node; and the storage resources required by the subtask are less than or equal to the available storage capacity on the execution node. After the constraints are established, the system uses these three constraints as a basis to initiate the constraint propagation process. Constraint propagation is executed in the order of subtask-by-subtask, node-by-node, and resource-by-resource, i.e., first selecting a subtask... The system extracts the three resource requirements of each subtask and compares them one by one with the available resource values ​​of all execution nodes. If the available resource value of an execution node does not meet any of the constraints, the execution node is directly removed from the range of allocable nodes for that subtask. For example, if a subtask requires 8 CPU cores / minute, 8192MB / minute memory, and 1500MB / minute storage, and an execution node has 6 available CPU cores, 10240MB available memory, and 2000MB available storage, the comparison shows that the node's 6 available CPU cores are less than the subtask's CPU requirement of 8 cores / minute, thus failing to meet the first constraint. Therefore, the node is removed from the allocable range of that subtask. After all subtasks have been compared with all execution nodes, the set of remaining allocable execution nodes for each subtask is the candidate node set for that subtask. The execution nodes in each candidate node set can satisfy the three resource allocation constraints of the subtask. The system stores the candidate node sets of all subtasks in a temporary database according to the order of the subtask identifiers.

[0082] Step 43: Based on the candidate node set of each subtask, perform resource persistence verification, subsequent dependency resource reservation verification, and allocation conflict verification in sequence. Eliminate node allocation schemes that do not meet any of the verifications until each subtask retains at least one feasible allocation node, thus obtaining a feasible allocation scheme between subtasks and execution nodes. Specifically, the system loads the candidate node set of all subtasks from the temporary database, and simultaneously calls the subtask execution sequence dependency relationship stored in the global task directed acyclic graph to associate and bind the candidate node set with the dependency relationship. Then, the arc consistency verification process is started. The arc consistency verification adopts an iterative verification method. The iteration process controls the verification rhythm and termination condition through a core formula, as follows: Iteration termination judgment formula: ;in, This represents the change in the test value during the nth iteration. Let be the number of candidate nodes for the i-th subtask after the n-th iteration; Let Q0 be the number of candidate nodes for the i-th subtask after the (n-1)-th iteration. The specific execution process of the iterative verification is as follows: In the initial round n=1, the system counts the initial number of candidate nodes for all subtasks before the iterative verification, denoted as Q0. The first round of iterative verification is started. According to the execution order of subtasks determined in the directed acyclic graph of the global task, starting from the subtask with the highest priority and no pre-dependencies, the feasibility of allocation is verified for each execution node in the candidate node set of each subtask. The verification content covers three core dimensions, as follows: Resource continuity verification verifies whether the currently available resources of the execution node continue to meet the three resource allocation constraints of the subtask. Because other temporary tasks may occupy node resources during system operation, it is necessary to check the current available resources of the node in real time, rather than relying solely on the resource snapshot obtained in the above steps. If the remaining resources of the node after allocation cannot meet the requirements of the subtask, the node is determined to be infeasible. The subsequent dependency resource verification checks whether the remaining available resources of the execution node after allocating the subtask can meet the resource requirements of the subsequent dependent subtasks. If there are subsequent dependent subtasks, the corresponding resources must be reserved in advance. If the reserved resources cannot meet the minimum resource requirements of the subsequent dependent subtasks, the node allocation scheme is invalid. The allocation conflict verification checks whether the execution node has already been allocated... The system allocates nodes to other subtasks that execute concurrently with the current subtask. Specifically, it checks if there are multiple unrelated subtasks that conflict within the same execution node's time period. If a conflict exists, the node cannot be allocated to the current subtask. For node allocation schemes that do not meet any of the above checks, the system directly removes them from the candidate node set of that subtask and records the reasons for removal in the associated dataset, including insufficient resource continuity, insufficient reservation of subsequent dependent resources, and allocation conflicts. After the first round of iteration checks, the system counts the number of candidate nodes Q1 for all subtasks and substitutes Q1 and the initial number of candidate nodes Q0 into the iteration termination determination formula to calculate... If I≠0, it means that an invalid allocation scheme has been eliminated in this iteration, and the candidate node set is still in a dynamic state. Start the second iteration, repeat the above verification process, count Q2 and calculate I. If I=0, it means that no invalid allocation scheme has been eliminated in this iteration, the number of candidate nodes in all subtasks is the same as in the previous round, the candidate node set has stabilized, and the candidate node set of each subtask is not empty. The iteration terminates, and the system continues to perform iterative verification until at least one normally allocable execution node is retained in the candidate node set of each subtask. At this time, the allocation combination of all retained subtasks and execution nodes together constitutes the feasible allocation scheme of subtasks and execution nodes.

[0083] Step 44: Convert feasible allocation schemes into mapping relationships between subtasks and execution nodes, and generate a global scheduling table. Specifically, this includes: loading the scheme verification report based on the feasible allocation schemes of subtasks and execution nodes, and performing a feasibility check again. The check includes verifying whether the candidate node set for each subtask is not empty to ensure at least one feasible allocation node, and whether all allocation schemes satisfy resource constraints and execution dependencies without omissions or errors. After the check passes, the system enters the mapping relationship establishment stage. This stage adopts an optimal node priority selection strategy. The specific execution process is as follows: the system sequentially selects each subtask according to its subtask identifier in ascending order. The system selects the optimal execution node from its candidate node set, following the principles of prioritizing remaining resources, concurrent load, and node performance. Prioritizing remaining resources means selecting the execution node with the most remaining resources after allocation; prioritizing concurrent load means selecting the execution node with the lowest load and no other concurrently allocated tasks to reduce resource contention; and prioritizing node performance means that if remaining resources and load are comparable, the execution node with better CPU computing performance and memory read / write performance is selected to improve subtask execution efficiency. After selection, the system establishes a one-to-one mapping between subtask identifiers and selected execution node identifiers, and stores this mapping relationship. The mapping data is stored in a mapping table to ensure that each subtask corresponds to only one execution node, and one execution node can correspond to multiple subtasks without execution conflicts. The system also records the timestamp of the mapping relationship establishment. After the mapping relationship is established, the system sorts all mapping relationships according to the subtask execution order determined in the global directed acyclic graph. The sorting principle is as follows: subtasks without prerequisite dependencies are prioritized and placed at the beginning of the sequence; subtasks with prerequisite dependencies follow their predecessors to ensure that the dependency relationship is not broken; and subtasks at the same level are sorted according to their subtask identifiers to ensure the uniqueness and stability of the sorting. After sorting, the system provides detailed information for each mapping relationship. The supplementary core information includes eight items: a unique subtask identifier, a channel packaging task identifier associated with the original channel packaging task to which the subtask belongs, an allocation execution node identifier, the CPU resource requirement of the subtask, the memory resource requirement of the subtask, the storage resource requirement of the subtask, the subtask's pre-dependency identifiers (recorded as none if there are no pre-dependencies), and the estimated execution time of the subtask calculated using a standardized formula. ,in, Indicates the estimated execution time of the subtask. Indicates the CPU requirements of the subtask. This indicates the number of available CPU cores on the execution node. Let's assume a subtask has a CPU requirement... The number of available CPU cores allocated to a node is 10 cores / minute. If the core count is 5, then the estimated execution time of this subtask is... =10÷5=2 minutes. The system will synchronously enter the calculation result into the mapping relationship. After all information is supplemented, the system will encapsulate all sorted mapping relationships in a structured way and organize them into a global scheduling table using a combination of two-dimensional tables and index trees. Each row of the two-dimensional table corresponds to a mapping record of a subtask, and each column corresponds to the eight supplemented core information items. The index tree is constructed with subtask identifiers and execution node identifiers as core search keywords to build a tree-shaped index structure. The global scheduling table is equipped with a dual control mechanism: first, permission control, which restricts each execution node to only reading the subtask information assigned to it; second, a real-time update mechanism, which automatically updates the corresponding data, including available node resources, subtask execution progress, and estimated execution time, when the subtask execution status and node resource status change, and generates the global scheduling table.

[0084] In this embodiment of the invention, by unifying resource measurement and real-time collection, the problem of inconsistent resource descriptions is overcome, achieving the effect of accurate matching of resource data; by using hard constraints and step-by-step screening, the problems of blind resource allocation and excessively large candidate range are overcome, achieving the effect of accurate convergence of candidate node sets; by using multi-dimensional verification and iterative convergence, the problems of lack of foresight in allocation schemes and difficulty in identifying node conflicts are overcome, achieving the effect of globally feasible schemes and evidence-based convergence; by using multi-dimensional priority selection and dynamic management, the problems of node selection relying on experience and lack of dynamic feedback in the scheduling table are overcome, achieving the effect of scientific and reasonable node allocation and real-time management of the scheduling table.

[0085] In a preferred embodiment of the present invention, step 5 above includes:

[0086] Step 51: Obtain the list of subtasks assigned to each execution node from the global scheduling table, and extract the dependencies between subtasks from the global task directed acyclic graph to obtain the set of subtasks to be executed and the dependency constraint table for each node. Specifically, this includes: grouping and traversing all mapping data in the global scheduling table, extracting all associated information corresponding to each execution node identifier during the traversal, including subtask identifier, subtask type, subtask CPU requirement, subtask memory requirement, subtask storage requirement, and estimated execution time of the subtask. After extraction, organize and enter all subtask information corresponding to each execution node into a temporary data table in ascending order of execution node identifiers to form a list of subtasks assigned to each execution node. Each row in this list corresponds to a subtask, and each column corresponds to a subtask association information item. At the same time, add an execution node identifier index to the list. The system starts the graph data reading module, reads all directed edge data from the global task directed acyclic graph, parses the subtask association relationship corresponding to each directed edge, and extracts each group with sequential execution relationship. The system identifies the subtasks and their corresponding information, clearly defining all the pre-dependent subtask identifiers and post-execution subtask identifiers for each subtask. For subtasks without pre-dependents, the pre-dependents are marked as empty; for subtasks without post-execution, the post-execution is marked as empty. All subtask dependencies are organized and entered into a two-dimensional table in ascending order of subtask identifiers, generating a dependency constraint table. This table contains three core fields: subtask identifier, a list of pre-dependent subtask identifiers, and a list of post-execution subtask identifiers. The system matches the subtask list assigned to each execution node with the dependency constraint table item by item. During the matching process, the execution status of each subtask's pre-dependent subtasks is checked one by one. Subtasks that have been completed or whose pre-dependent subtasks are incomplete or do not yet meet the execution conditions are removed. Only subtasks whose pre-dependents are met and can enter the execution preparation state at the current stage are retained. These subtasks are then categorized and organized according to the execution node dimension to form a set of subtasks to be executed for each execution node. The set of subtasks to be executed and the dependency constraint table are simultaneously pushed to the local cache unit of the corresponding execution node.

[0087] Step 52: Each execution node selects subtasks that meet the dependency conditions from the set of subtasks to be executed based on the dependency constraint table and executes them in parallel. During execution, the node records the changes in CPU, memory, and storage resource usage caused by the execution of subtasks in real time, resulting in a node resource usage record table. Specifically, after the set of subtasks to be executed and the dependency constraint table are synchronously pushed to the local cache unit of each execution node, each execution node starts the local cache reading module to read its corresponding set of subtasks to be executed and dependency constraint table from the local cache unit. After reading, the data integrity is checked. After confirming that there is no missing data or field errors, the pre-processing is started. The component verification module checks the prerequisite conditions of each subtask in the set of subtasks to be executed, according to the prerequisite execution relationships recorded in the dependency constraint table. During the verification process, it checks the execution status records of the subtasks stored in the system to confirm whether all the prerequisite dependent subtasks of the subtask have been completed. If all the prerequisite dependent subtasks have been completed, the subtask is determined to meet the execution conditions and is added to the local parallel execution queue. If any prerequisite dependent subtask has not been completed, the subtask is determined to not meet the execution conditions, is not added to the execution queue, and remains in the set of subtasks to be executed. Each execution node then executes the subtasks in local parallel order. The queue is arranged in order to initiate a multi-threaded execution mechanism, simultaneously launching multiple subtasks that meet the execution conditions. During subtask startup, according to the CPU, memory, and storage requirements recorded in the global scheduling table, a corresponding amount of computing resources is allocated from its available resources. The allocation process ensures that the allocated resources do not exceed the subtask's requirement limit and do not affect the normal execution of other subtasks. During subtask execution, each execution node activates a resource usage collection module to collect resource usage data at fixed time intervals (set to 1 second). The collected data includes real-time CPU usage and real-time memory usage. After data collection, the system records the usage capacity and storage capacity in real time. Once the data collection is complete, the collection time, subtask identifier, CPU usage value, memory usage value, and storage usage value are written to the local data area in chronological order to form a node resource usage record table. The node resource usage record table is written in a time-order appending manner, that is, a record is appended to the end of the record table every time data is collected. Multiple resource usage records for the same subtask are strictly arranged in chronological order of collection time. Each record contains six core fields: collection timestamp, subtask identifier, CPU usage, memory usage, storage usage, and resource usage status. The resource usage status is initially marked as "in execution".

[0088] Step 53: After each execution node completes its execution, it stores the execution result of the subtask in the result cache and updates the resource usage status of the corresponding subtask in the node resource usage record table to "completed," resulting in an updated node resource usage record table. This includes a node resource usage record table update module. This module first reads the node resource usage record table stored in the local data area, establishes a temporary traversal pointer, and traverses all time-series records in the record table one by one according to the ascending order of the subtask identifiers. It precisely matches the subtask identifier with the identifier of the currently completed subtask to locate all time-series resource usage records corresponding to that subtask. An exact matching mode is used during the matching process. After location, the update module updates the resource usage status field in these records from "execution" to "completed." During the update process, it strictly retains all CPU usage values, memory usage capacity, storage usage capacity, and corresponding collection timestamps from all time-series data collections, without deleting any historical collection information. This ensures that the complete resource usage data of the subtask from start to finish is traceable and guarantees the integrity of the resource usage data. For completeness, after the update, an updated node resource usage record table is generated. This record table retains the original data structure and includes six core fields: subtask identifier, acquisition time, CPU usage, memory usage, storage usage, and resource usage status. No fields are missing. The executing node starts the data verification module to perform a comprehensive verification of the updated node resource usage record table. The verification includes: field completeness verification, confirming that the six core fields are complete and free of null values; data accuracy verification, confirming that the resource usage values ​​are valid positive numbers and the timestamp order is correct; and status consistency verification, confirming that the resource usage status of all time-series records for the same subtask has been updated to "completed," with no partial or missed updates. If an anomaly is found during verification, the system immediately locates the anomaly, records the error log, and triggers a re-update and verification process. If the verification passes, the updated node resource usage record table is confirmed to be accurate and complete. The record table is then stored in the local data area, and a data synchronization mechanism is initiated to back up the updated record table to the system's temporary database to prevent local data loss.

[0089] Step 54: Extract the execution status of each subtask and the resource usage status of each node from the updated node resource usage record table to generate an execution status table. Specifically, this includes: after each execution node generates the updated node resource usage record table and completes data verification, the system starts the data aggregation module and sends a data read command to all execution nodes. The command explicitly requires each execution node to upload the updated node resource usage record table. Upon receiving the command, each execution node uploads its locally updated node resource usage record table to the system in real time via the data upload interface. After receiving the record tables uploaded by all execution nodes, the system starts the data merging and deduplication module to... All record tables are merged according to the combination of subtask identifier and execution node identifier. During the merging process, duplicate data records are removed; that is, only one duplicate record corresponding to the same subtask, the same collection time, and the same execution node is retained to ensure that the merged data is free of redundancy. After merging, the system starts the data extraction module to extract the core field data corresponding to each record from the merged record table one by one. Specifically, this includes subtask identifier, execution node identifier, execution start time, execution end time, CPU usage, memory usage, storage usage, and execution status. The execution start time is the collection time of the first resource usage record for that subtask, and the execution end time is the collection time of the first resource usage record for that subtask. The time interval is the time of collection of the last resource usage record for this subtask. The system starts the data statistics and calculation module to perform statistical calculations on multiple time-series resource usage records of the same subtask. The peak CPU usage is the maximum value of CPU usage among all time-series records of this subtask, the peak memory usage is the maximum value of memory usage among all time-series records of this subtask, and the peak storage usage is the maximum value of storage usage among all time-series records of this subtask. The execution duration is calculated by subtracting the execution start time from the execution end time. The calculation process is: execution duration equals execution end time minus execution start time, in seconds. For example, for a certain subtask... If the task starts at 10:00:00 and ends at 10:00:05, the execution duration is 5 seconds. After all data extraction and calculation are completed, the system organizes all data in ascending order of subtask identifiers, encapsulates it using a two-dimensional table structure, and generates an execution status table. The execution status table contains nine core fields: subtask identifier, execution node identifier, execution start time, execution end time, execution duration, peak CPU usage, peak memory usage, peak storage usage, and execution status. After generation, the execution status table is stored in the system's core database using encrypted storage to ensure data security.

[0090] In this embodiment of the invention, by adopting a unified resource measurement and constraint propagation mechanism, the technical problems of inconsistent resource descriptions and error-prone manual matching are overcome, achieving the technical effects of accurate candidate node screening and automated allocation. By using arc consistency test and iteration termination judgment formula for three-dimensional iterative verification, the technical problems of lack of foresight in allocation scheme, insufficient reservation of post-dependencies, and difficulty in identifying concurrent conflicts are overcome, achieving the technical effects of globally feasible allocation scheme and evidence-based iterative convergence. By adopting a multi-dimensional priority optimal node selection strategy and precise quantification of execution time, and generating a scheduling table with permission control and real-time update mechanism, the technical problems of allocation relying on experience and lack of dynamic feedback in the scheduling table are overcome, achieving the technical effects of scientific and reasonable node allocation and controllable and real-time updated scheduling table.

[0091] In a preferred embodiment of the present invention, step 6 above includes:

[0092] Step 61: Extract the resource usage status and number of unfinished tasks for each node from the execution status table to obtain the load status table for each node. Specifically, this includes: the system reads the generated execution status table from the core database, groups the data in the table according to the execution node identifier, and aggregates all subtask records corresponding to the same execution node into the same data group. The system traverses the data group corresponding to each execution node, extracts the execution status of all subtasks under that node, counts the number of subtasks in the "not started" and "in execution" states, and records this number as the number of unfinished tasks for the current node. The system also extracts the peak CPU usage corresponding to all subtasks under that node. The system calculates the peak CPU usage, peak memory usage, and peak storage usage of each execution node by summing the peak CPU usage values ​​of all nodes under the same node. The system then organizes the node identifier, total CPU usage, total memory usage, total storage usage, and number of unfinished tasks for each execution node in ascending order by execution node identifier to generate a load status table, which is stored in the system's temporary database.

[0093] Step 62: Based on the load status table of each node, identify nodes whose resource usage has reached the node capacity limit and whose number of unfinished tasks continues to accumulate. These nodes are designated as high-load nodes. Obtain the unstarted subtasks on these high-load nodes to obtain a list of subtasks to be reallocated. This specifically includes: reading the generated load status table from the temporary database, performing integrity checks on the data in the table during the reading process, confirming that the total CPU usage, total memory usage, total storage usage, and number of unfinished tasks for each execution node have no null values ​​or abnormal values. After successful verification, load the load status table into system memory. The system then uses the node resource configuration library... A dedicated read interface reads the rated resource capacity data of each execution node, including the rated number of CPU cores, rated total memory capacity, and rated total storage capacity. These rated resource capacity data are fixed values ​​preset during the factory configuration of the execution node or system initialization. After reading, they are bound to the execution node identifier and stored in a temporary data buffer. The system starts the load calculation module to calculate the CPU utilization, memory utilization, and storage utilization of each execution node. All three utilization rates use the same calculation logic. The specific calculation process is as follows: The CPU utilization rate is calculated by dividing the total CPU utilization of the execution node by... The CPU utilization rate is calculated by dividing the total CPU core count of the execution node by its rated total memory capacity, multiplying the quotient by 100%, and rounding the result to two decimal places. For example, if an execution node has a total CPU core utilization of 8 cores and a rated CPU core count of 10, its CPU utilization rate is (8 ÷ 10) × 100% = 80.00%. The memory utilization rate is calculated by dividing the total memory utilization of the execution node by its rated total memory capacity, multiplying the quotient by 100%, and rounding the result to two decimal places. For example, if an execution node has a total memory utilization of 8192MB and a rated total memory capacity of 16384MB, its memory utilization rate is (8192 ÷ 16384) × 100% = 80.00%. (20480 ÷ 40960) × 100% = 50.00%; The storage utilization rate is calculated by dividing the total storage utilization of the execution node by its rated total storage capacity, and then multiplying the quotient by 100%. The result is rounded to two decimal places. For example, if the total storage utilization of an execution node is 20480 MB and the rated total storage capacity is 40960 MB, its storage utilization rate is (20480 ÷ 40960) × 100% = 50.00%. The system presets a unified capacity upper limit threshold, which is a fixed value preset during system initialization and is used to determine whether the node has reached a high load state. In this embodiment, the capacity upper limit threshold is set to 85%.The system calculates the three utilization rates for each execution node and compares them one by one with the preset capacity limit threshold. Simultaneously, it retrieves the number of incomplete tasks recorded in the previous load monitoring cycle for that node and compares the changing trend of the current number of incomplete tasks with the previous cycle. When any one of the node's CPU utilization, memory utilization, or storage utilization reaches or exceeds 85%, and the current number of incomplete tasks shows a continuously increasing trend compared to the previous monitoring result (i.e., the current number of incomplete tasks is greater than the previous cycle), the system marks that execution node as a high-load node. During the marking process, a high-load tag is added after the node identifier, and the marking time, the resource utilization items that triggered the high load, and the number of incomplete tasks are recorded. Regarding changes in the number of tasks, after marking all execution nodes as high-load, the system initiates a subtask filtering module. This module reads the global scheduling table in the core scheduling database and iterates through each mapping record in the table. The filtering criteria are that the execution node identifier belongs to a marked high-load node, and the subtask execution status is "not started." An exact match mode is used during the filtering process. After filtering, the system extracts all relevant information for these eligible subtasks, including subtask identifier, CPU requirements, memory requirements, storage requirements, and resource requirements and dependencies such as pre-dependent identifiers. This information is then arranged in ascending order by subtask identifier to form a list of subtasks to be reassigned. This list uses a two-dimensional table structure, with each row corresponding to a subtask to be reassigned and each column corresponding to a piece of subtask-related information. Once generated, the list is synchronously stored in the system scheduling cache, and a cache monitoring mechanism is activated to ensure the list data is not tampered with, awaiting the next removal and reassignment operations.

[0094] Step 63: Remove the subtasks from the list of subtasks to be reassigned from the scheduling plan of the high-load node, and return to Step 4 to reallocate execution nodes for these subtasks based on the current available resource status of each node, obtaining the reassignment result. Specifically, this includes: reading the list of subtasks to be reassigned; verifying the list data after reading to confirm that the subtask identifiers in the list are not duplicated or missing, and that the resource requirement information is complete and valid; after verification, loading the list into the system scheduling module; traversing the global scheduling table in the core scheduling database one by one according to each subtask identifier in the list; and accurately locating the specific scheduling record corresponding to these subtasks in the high-load node through the combination of subtask identifier and execution node identifier. During the location process, a system is established... A temporary traversal pointer is used to compare the subtask identifiers in the global scheduling table line by line, ensuring that the scheduling record corresponding to each subtask to be reassigned can be accurately found without omissions or mismatches. After location, the system starts the scheduling record removal module to completely remove these located scheduling records from the original scheduling plans of high-load nodes. At the same time, all mapping relationships between these subtasks and their corresponding high-load nodes are cleared, and the status of these subtasks is marked as pending reassignment in the global scheduling table. The removal time, the corresponding high-load node identifier, and the subtask identifier are recorded to form a removal operation log. After the removal operation of all subtasks to be reassigned is completed, the real-time resource monitoring module is started to monitor the real-time available resource status of all execution nodes. A comprehensive data collection process is performed, and the available resource status is derived using standardized calculation formulas. The specific calculation process is as follows: Available CPU resources equal the rated number of CPU cores of the execution node minus the current total CPU utilization. For example, if an execution node has a rated number of 10 CPU cores and the current total CPU utilization is 8 cores, its available CPU resources are 10 - 8 = 2 cores; Available memory resources equal the rated total memory capacity of the execution node minus the current total memory utilization. For example, if an execution node has a rated total memory capacity of 16384MB and the current total memory utilization is 8192MB, its available memory resources are 16384 - 8192 = 8192MB; Available storage resources equal the rated total storage capacity of the execution node minus... The current total storage usage is as follows: For example, if the rated total storage capacity of an execution node is 40960MB and the current total storage usage is 20480MB, then its available storage resources are 40960-20480=20480MB. The system organizes the real-time available resource data of each execution node into a snapshot of available resources and stores it in the temporary data area to ensure the real-time performance and accuracy of the data. The system treats all subtasks in the list of subtasks to be reassigned as new independent scheduling objects, starts the process backtracking mechanism, and returns to the complete process of resource constraint matching and arc consistency verification in step 4. The system rereads the subtask execution order dependency relationship stored in the global task directed acyclic graph and associates and binds the subtasks to be reassigned with the dependency relationship.Based on real-time snapshots of available resources at each execution node, the system re-establishes three resource allocation constraints for each subtask to be reallocated. It compares the available resources of each execution node with the resource requirements of the subtask, filtering out a set of candidate nodes that meet all constraints. An iterative process of arc consistency verification is initiated, performing multiple rounds of checks on the candidate node set to eliminate nodes with resource conflicts or insufficient downstream dependent resources, ensuring that each node in the candidate node set can be properly allocated and execute the subtask. For each subtask to be reallocated, the optimal execution node is selected from its candidate node set, completing a new round of node allocation and candidate node filtering. This ultimately forms a one-to-one correspondence between each subtask to be reallocated and the new execution node, yielding a complete reallocation result. The reallocation result includes complete information such as the subtask identifier, the new execution node identifier, the available resources of the new node, and the resource requirements of the subtask.

[0095] Step 64: Update the reassignment results to the global scheduling table to obtain the updated global scheduling table. This includes: reading the generated reassignment results; verifying the completeness and accuracy of the result data during the reading process; confirming that each subtask to be reassigned corresponds to a unique new execution node identifier, with no duplicate or missing assignments; and that the subtask resource requirements, prerequisite dependencies, and other information are complete and correct. After successful verification, the reassignment results are loaded into the global scheduling table update module. The system extracts the core information of each subtask from the reassignment results, including the subtask identifier, the corresponding new execution node identifier after reassignment, the subtask CPU requirements, the subtask memory requirements, the subtask storage requirements, the estimated execution time of the subtask, and the subtask prerequisite dependencies. After extraction, the subtasks are sorted in ascending order by their identifiers and stored in a temporary update buffer. The system then starts the global scheduling table update module and reads the data stored in the core scheduling database through the core scheduling database's read / write interface. To avoid data loss or anomalies caused by directly modifying the original global scheduling table, the system first copies the original global scheduling table to generate a temporary operation copy. All update operations are performed in the temporary operation copy. The system traverses each subtask mapping record in the temporary update buffer, extracts the subtask identifier and the corresponding new execution node identifier, and searches for the original mapping record corresponding to the subtask identifier in the temporary operation copy line by line. After finding the corresponding record, the old execution node identifier in the record is replaced with the reassigned new execution node identifier. At the same time, the estimated execution time of the subtask is recalculated based on the real-time available resource status of the new execution node. The calculation process is that the estimated execution time of the subtask is equal to the subtask's CPU requirement divided by the available CPU resources of the new execution node. The calculation result is rounded to two decimal places. For example, if a subtask's CPU requirement is 10 cores / minute and the available CPU resources of the new execution node are 5 cores, its estimated execution time is 10 ÷ 5 = 2.At 00 minutes, the system updates the scheduling sequence number and execution time of the subtask in the global scheduling table based on the dependencies in the global task directed acyclic graph, ensuring that the execution order of the subtask is consistent with its pre-dependencies. After all the mapping records of the subtasks to be reassigned are updated, the system starts the data integrity verification module to perform a comprehensive verification of the updated scheduling records in the temporary operation copy. The verification includes: first, verifying the one-to-one correspondence between subtask identifiers and node identifiers, ensuring that one subtask corresponds to only one execution node, and one execution node can correspond to multiple non-conflicting subtasks, with no abnormal one-to-many or many-to-one mappings; second, verifying the integrity of resource requirement information, confirming the CPU requirements, memory requirements, storage requirements, etc. of all subtasks. The system performs several checks: 1) Fields are complete, with no null values ​​or abnormal values; 2) Dependency consistency verification confirms that the pre-dependency identifiers of subtasks have not changed and are consistent with the dependencies in the global task's directed acyclic graph, with no disordered dependencies; 3) Scheduling sequence rationality verification confirms that the updated scheduling sequence number and execution sequence conform to the subtask's dependencies, with no timing conflicts. If an anomaly is found during verification, the system immediately locates the location and cause of the anomaly record, records a detailed error log, and triggers a re-update and verification process. If the verification passes, the system confirms that the scheduling records in the temporary operation copy are accurate, complete, and without anomalies. The system then repackages all updated records in the temporary operation copy into a standard two-dimensional table structure, generating the updated global scheduling table. The updated global scheduling table retains the original data structure, including all core fields such as subtask identifier, execution node identifier, resource requirements, estimated execution time, prerequisite dependency identifier, and scheduling sequence number. After generation, the system uses the overwrite interface of the core scheduling database to overwrite the original global scheduling table in the core scheduling database with the updated global scheduling table, completing the data replacement operation. After the replacement is complete, the system initiates a scheduling table activation command, notifying all execution nodes to pull the latest global scheduling table through a dedicated interface. Upon receiving the command, each execution node reads the updated global scheduling table and updates its locally cached scheduling plan.

[0096] In this embodiment of the invention, a high-load identification mechanism combining multi-dimensional resource occupancy rate and task backlog trend is adopted to overcome the technical problem of misjudging high load by a single indicator, achieving the technical effect of accurate identification and low misjudgment rate. After removing the sub-tasks to be reallocated, the complete resource constraint and arc consistency verification process is backtracked for reallocation, overcoming the technical problem of task migration relying on manual intervention and easily causing secondary conflicts, achieving the technical effect of automated reallocation and globally feasible results. After completing the integrity verification by using a temporary operation copy mechanism, the original table is overwritten and each node is synchronized, overcoming the technical problem of data loss and node plan asynchrony during scheduling table updates, achieving the technical effect of safe and reliable update process and strong data consistency. The closed-loop optimization process from load monitoring to scheduling table update overcomes the technical problem of difficulty in timely adjustment of load imbalance and uneven resource utilization, achieving the technical effect of real-time load perception, dynamic task migration, and balanced system resource utilization.

[0097] In a preferred embodiment of the present invention, step 7 above includes:

[0098] Step 71: Based on the updated global scheduling table and execution status table, extract the execution progress information of the assigned subtasks on each node to obtain the subtask execution progress table for each node. Specifically, the system reads the updated global scheduling table from the core scheduling database and simultaneously reads the execution status table. It verifies each item in both tables—execution node identifier, subtask identifier, execution status, execution start time, estimated execution duration, and resource usage—to ensure all data is complete, valid, without missing data, and without anomalies. After verification, the system uses the execution node identifier as the grouping basis to collect and organize all subtask data corresponding to the same execution node. It then extracts all information for each assigned subtask on each node, including subtask identifier, execution node identifier, execution start time, current execution status, estimated execution duration, and already executed duration. The system uses the moment the subtask enters the execution state as the reference time for progress calculation, extracting the current system time, subtask execution start time, and subtask estimated execution duration to calculate the current execution progress of the subtask. The execution progress calculation formula is: ,in, Indicates the current execution progress of the subtask. Indicates the current system time. Indicates the start time of subtask execution. This represents the estimated execution time of the subtask. The calculation result is rounded to two decimal places. The particle swarm optimization algorithm is used to smooth and calibrate the calculated execution progress. Through iterative updates of particle position and velocity, deviations in the progress calculation are corrected. The velocity update formula is as follows:

[0099] ;

[0100] in, This indicates the update speed of the particle in this iteration, used to represent the magnitude and direction of the particle's position adjustment in this iteration; Indicates inertia weight; This indicates the velocity of the particle in the previous iteration; This represents the individual learning factor, with a fixed value of 1.5. Represents a random number between 0 and 1; This represents the particle's own historical optimal position, corresponding to the optimal progress calibration parameter found during the particle's iteration process; This indicates the particle's current position and corresponds to the current subtask progress calibration parameters. This represents the group learning factor, with a fixed value of 1.7. Represents a random number between 0 and 1; This represents the global optimal position of the entire particle swarm, corresponding to the optimal progress calibration parameter found during all particle iterations. The position update formula is: new = + ;in, new This indicates the updated position of the particles, i.e., the corrected subtask progress calibration parameters; This indicates the position of the particle before the update, i.e., the current uncalibrated subtask progress parameter; This represents the update rate of the particle in this iteration, and is related to the rate update formula. The meanings are completely consistent. The system uses the iterative calculations of the aforementioned particle swarm optimization algorithm to smoothly calibrate the execution progress of each subtask, correcting deviations in the initial calculations. After calibration, the system statistically analyzes the execution progress, execution status, executed time, and remaining execution time of all subtasks under the same execution node. Simultaneously, it counts the number of completed subtasks, the number of subtasks in execution, and the number of subtasks not yet started within the node, and calculates the overall task completion rate of the node. The formula for calculating the overall task completion rate of the node is: R = × 100%, where R represents the overall task completion rate of the node. This indicates the number of subtasks that have been completed within the node. This indicates the total number of subtasks assigned to a node. The system organizes the statistical data of all execution nodes into a standard two-dimensional table structure according to the ascending order of the execution node identifiers, and generates a subtask execution progress table for each node. The subtask execution progress table includes all fields such as execution node identifier, subtask identifier, execution start time, execution duration, estimated execution duration, current execution progress, execution status, and continuous pause period.

[0101] Step 72: Based on the subtask execution progress table of each node, identify the node containing the subtask that has not progressed in multiple consecutive scheduling cycles as the fault node, and obtain all the subtasks in the incomplete state on the fault node to obtain the list of subtasks to be reset. Specifically, this includes: reading the subtask execution progress table stored in the temporary database, starting the fault node identification process, and setting a first baseline and a second baseline for each subtask. The first baseline is the timestamp of the most recent effective progress of the subtask execution. The second benchmark is the start timestamp of the current monitoring period. The time crossover value is calculated based on two reference points. The formula for calculating the time crossover value is as follows: ,in, Indicates the time crossover value between two reference points; Indicates the first reference point timestamp; This represents the second baseline timestamp. Simulated annealing is used to improve the accuracy of fault node identification, combined with time crossover values. Based on fluctuations in execution progress, the stalled subtasks are accurately identified using the following formula: Temperature Update Formula: = x ;in, This represents the temperature value after this iteration. This represents the temperature value before the current iteration. This represents the cooling coefficient, fixed at 0.95. The acceptance probability formula is: ;in, This represents the acceptable probability of fluctuations in the progress of a subtask. This represents the difference in subtask progress, calculated as the absolute value of the difference between the current cycle progress and the previous cycle progress. ,in, This represents the execution progress of the subtask in the current cycle. This refers to the execution progress of subtasks in the previous cycle; This represents the temperature value during the current iteration. The specific process is as follows: Initialize the temperature. Set the number of iterations, and in each iteration, calculate the progress fluctuation difference for each subtask. With the probability of acceptance ;like If the probability threshold is less than 0.1 (preset by the system), the lack of progress in the subtask is determined to be a genuine stagnation, not an accidental fluctuation. If the progress value is greater than or equal to the probability threshold, it is judged as an occasional fluctuation and not as a standstill. The system uses multiple consecutive scheduling cycles as the judgment window, collecting and recording the execution progress value of each subtask cycle by cycle. The progress values ​​of the same subtask in different cycles are compared one by one. Combined with the judgment results of the simulated annealing algorithm, if the execution progress value of a subtask does not increase in multiple consecutive scheduling cycles and remains unchanged, and the time crossover value is greater than the system's preset standstill threshold and acceptance probability, then the system will consider it as a standstill. When the probability threshold is less than 1, the system classifies the subtask as a stalled subtask. The system iterates through all execution nodes, marking those with stalled subtasks as fault nodes, and records the fault node identifier, fault trigger time, number of stalled subtasks, and stall duration. After marking fault nodes, the system reads the global scheduling table and execution status table, filtering out all incomplete subtasks assigned to fault nodes that are in execution status (not started or in progress). The system extracts complete information such as subtask identifier, CPU requirements, memory requirements, storage requirements, prerequisite dependency identifiers, and channel identifiers of these subtasks, and arranges them in ascending order of subtask identifiers to form a list of subtasks to be reset. After the list of subtasks to be reset is generated, it is synchronously stored in the system scheduling cache. At the same time, the integrity of the list data is checked to ensure that the subtask identifiers are not duplicated or missing, and that the information is complete and valid.

[0102] Step 73: Reset the status of each subtask in the list of subtasks to be reset to "pending scheduling," and return the reset subtask list to Step 4 to reallocate execution nodes, obtaining the reallocated global scheduling table. Specifically, this includes: reading the list of subtasks to be reset from the scheduling cache; initiating the task status reset and execution node reallocation process; the system traverses the global scheduling table in the core scheduling database; accurately locating the scheduling mapping record corresponding to each subtask to be reset based on the subtask identifier in the list; uniformly resetting the execution status of these subtasks to "pending scheduling"; clearing the original execution start time, execution progress, baseline time, and resource usage time sequence data; removing all association mappings between subtasks and faulty nodes; and marking these subtasks as "pending reallocation" in the global scheduling table. After the status reset is complete, the system returns all subtasks to be reset to Step 4, re-executing the resource constraint matching, candidate node screening, and optimal execution node allocation process; collecting the real-time available resource status of all normally operating execution nodes; and determining that the available CPU resources of an execution node are equal to the node's rated CPU capacity minus the node's current CPU capacity. The total PU usage is calculated as follows: the available memory resources of the execution node equal the node's rated memory capacity minus the node's current total memory usage; the available storage resources of the execution node equal the node's rated storage capacity minus the node's current total storage usage. Based on the core condition that the node's available resources can fully meet the resource requirements of the subtasks, and combined with the principle of global load balancing, the optimal execution node is re-matched for each subtask to be reset, resulting in a complete redistribution result. After reading the redistribution result and completing data verification, the system writes the new subtask-to-execution node mapping relationship, execution sequence, and estimated execution duration into the global scheduling table, replacing the old data. Based on the real-time available resource status of the newly allocated execution node, the estimated execution duration of the subtask is recalculated. The estimated execution duration equals the subtask's CPU requirement divided by the CPU available resources of the newly allocated node, with the result rounded to two decimal places. After all data updates are complete, the system performs an integrity check on the global scheduling table. After confirming no duplicate allocations, no dependency conflicts, and no data errors, a redistributed global scheduling table is generated, overwriting the original global scheduling table and taking effect immediately. Each execution node is then notified to load the latest scheduling plan.

[0103] Step 74: Iterate through steps 61 to 63 until all subtasks are marked as completed. Extract the execution results of each subtask from the result cache and merge them into complete channel packages for each channel to achieve parallel packaging and task scheduling of game channel packages. Specifically, this includes: reading the latest global scheduling table and execution status table, synchronizing and verifying the data in the two tables, then iterating through the execution status of all subtasks in the system, counting the number of completed subtasks and the total number of all subtasks, and judging against the preset iteration termination condition. The iteration termination condition is as follows: the execution status of all subtasks is marked as completed, and there are no unstarted or unexecuted subtasks in the system. Subtasks in the in-process, pending scheduling, or pending reset states are all executed when all execution nodes are idle and have no resource consumption. During the iteration process, the system collects key data for each iteration in real time, including the number of iterations, the number of faulty nodes, the number of task resets, the number of successful reassignments, the time consumed in each iteration, and the peak resource consumption of each execution node. This data is then organized into standardized iteration logs according to a preset log format specification. The logs clearly record the collection timestamp, specific data value, and exception description for each data item. After generation, the logs are synchronously stored in the system's runtime log library and archived according to iteration date. When the system detects that the iteration termination conditions are fully met, it immediately triggers... The iteration terminates upon receiving the instruction, exiting the loop execution process and initiating the result extraction and channel package generation process. The system extracts the execution result data of all subtasks from the result cache in ascending order of their subtask identifiers. During extraction, the integrity of the data transmission is verified in real time. After extraction, the system initiates a three-layer verification mechanism to comprehensively verify the extracted execution result data: integrity verification, checking whether the execution result data of each subtask is complete and whether there are any issues such as missing fields or null values; format verification, confirming that the format of the execution result data conforms to the preset standard and is consistent with the format requirements for channel package generation; and consistency verification, comparing the subtask execution results with the preset... The system ensures consistency between execution standards and the results of pre-dependent tasks, confirming the absence of data errors, contradictory results, or other anomalies. After successful verification, the system categorizes and groups the execution results of all subtasks according to the channel identifier. The execution results of subtasks from the same channel are then combined, integrated, logically validated, and format-encapsulated according to a preset packaging order. During the encapsulation process, the system strictly adheres to the exclusive format requirements of each game channel. Upon completion of the generation of each channel package, the system immediately performs integrity and availability checks. After confirming the absence of encapsulation errors and data corruption, the package is stored in the system's persistent storage area, completing data archiving and updating the archive logs to achieve parallel packaging and task scheduling of game channel packages.

[0104] In this embodiment of the invention, the particle swarm optimization algorithm is used to smooth and calibrate the execution progress, overcoming the technical problems of numerous spikes in progress data and inaccurate prediction, achieving smooth and stable progress and accurate prediction of remaining time. The use of dual benchmark time cross-values ​​combined with simulated annealing algorithm accurately distinguishes between real stagnation and accidental fluctuations, overcoming the technical problem of high misjudgment rate in traditional threshold judgment, achieving accurate stagnation identification and reliable fault node location. After resetting the status of unfinished subtasks on faulty nodes, the complete allocation process is backtracked for reallocation and iterative execution, overcoming the technical problems of long-term task suspension and low efficiency of manual intervention after node failure, achieving automatic fault isolation, fully automatic task reallocation, and system self-healing capabilities. After iteration termination, the system is categorized and packaged by channel and three-layer verification is performed, overcoming the technical problems of scattered parallel packaging results and lack of verification mechanisms, achieving automated result extraction, accurate and reliable channel package generation, and traceable scheduling loop.

[0105] like Figure 2 As shown, embodiments of the present invention also provide a cloud computing-based parallel packaging and task scheduling system for game channel packages, comprising:

[0106] The acquisition module is used to acquire the original game resource package and the packaging configuration information of multiple channels, generate packaging tasks for each channel based on the content differences between the two, and aggregate them into a global task queue.

[0107] The processing module is used to split each packaged task in the global task queue into multiple subtasks according to the resource dependency type of the processing stage; to obtain the resource consumption association of the subtasks by labeling them; and to generate a global task directed acyclic graph by executing each subtask.

[0108] The verification module is used to constrain and verify the resource consumption correlation of subtasks and the directed acyclic graph, match execution nodes for each subtask, and generate a global scheduling table. Each execution node executes subtasks in parallel through the global scheduling table and the directed acyclic graph, obtains the resource usage changes of each node, and stores them in the cache to generate an execution status table.

[0109] The update module is used to identify nodes with saturated resources and backlogged tasks based on the execution status table, remove the unstarted subtasks of the node from the current scheduling table, and return to step 4 for reallocation to update the global scheduling table.

[0110] The control module is used to identify nodes that have made no progress in multiple consecutive scheduling cycles based on the updated global scheduling table and execution status table, reset the unfinished subtasks of the node to the pending scheduling state and return to step 4 for reallocation; after all subtasks are completed, the results are extracted from the result cache to generate packages for each channel, and parallel packaging and task scheduling are completed.

[0111] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0112] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0113] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0114] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A cloud-based method for parallel packaging and task scheduling of game channel packages, characterized in that, The method includes: Step 1: Obtain the original game resource package and packaging configuration information for multiple channels, generate packaging tasks for each channel based on the content differences between the two, and aggregate them into a global task queue. Step 2: Based on each packaged task in the global task queue, split it into multiple sub-tasks according to the resource dependency type of the processing stage; Step 3: By labeling the subtasks, obtain the resource consumption relationships of the subtasks; by executing each subtask, generate a global directed acyclic graph of tasks. Step 4: By constraining and verifying the resource consumption correlation of subtasks and the directed acyclic graph, execution nodes are matched for each subtask to generate a global scheduling table. Step 5: Each execution node executes subtasks in parallel through the global scheduling table and the directed acyclic graph, obtains the resource usage changes of each node, and stores them in the cache to generate an execution status table. Step 6: Based on the execution status table, identify nodes that are resource-saturated and have a backlog of tasks, remove the unstarted subtasks of the node from the current scheduling table, return to step 4 for reallocation, and update the global scheduling table. Step 7: Based on the updated global scheduling table and execution status table, identify nodes that have made no progress in multiple consecutive scheduling cycles, reset the unfinished subtasks of these nodes to a pending scheduling state, and return to Step 4 for reallocation; after all subtasks are completed, extract the results from the cache to generate packages for each channel, completing parallel packaging and task scheduling, including: Step 71: Based on the updated global scheduling table and execution status table, extract the execution progress information of the assigned subtasks on each node, use the particle swarm optimization algorithm to smooth and calibrate the execution progress of the subtasks, and correct the deviation in the progress calculation through iterative updates of particle position and velocity. After calibration, perform item-by-item statistics on the execution progress, execution status, execution duration, and remaining execution duration of all subtasks under the same execution node to generate the subtask execution progress table for each node. Step 72: Based on the subtask execution progress table of each node, identify the nodes where subtasks that have not progressed in multiple consecutive scheduling cycles are located as fault nodes. This includes setting a first reference point and a second reference point for each subtask, calculating the time cross value based on the two reference points, using the simulated annealing algorithm to improve the accuracy of fault node identification, and combining the time cross value with the execution progress fluctuation to accurately determine the stalled subtasks. The execution nodes with stalled subtasks are marked as fault nodes. Step 73: Reset the status of each subtask in the list of subtasks to be reset to pending scheduling, and return the reset list of subtasks to Step 4 to reallocate execution nodes, thus obtaining the reallocated global scheduling table. Step 74: Iterate through Step 6 until all subtasks are in the completed state. Extract the execution results of each subtask from the result cache and merge them by channel to generate complete channel packages for each channel, so as to achieve parallel packaging and task scheduling of game channel packages.

2. The method for parallel packaging and task scheduling of game channel packages based on cloud computing according to claim 1, characterized in that, Obtain the original game resource package and packaging configuration information from multiple channels, generate packaging tasks for each channel based on the content differences between the two, and aggregate them into a global task queue, including: Step 11: Obtain the original game resource package and the packaging configuration information of each channel. Extract the channel identifier, SDK configuration parameters and signature certificate from the packaging configuration information of each channel, and compare them with the default configuration in the original game resource package to obtain the differentiated configuration information of each channel. Step 12: Based on the differentiated configuration information of each channel, merge the differentiated configuration information with the original game resource package to generate a corresponding packaging task for each channel, and obtain a set of packaging tasks for each channel. Step 13: Store the packaging tasks in the packaging task sets of each channel into the task queue in order according to the channel identifier, and generate a global task queue.

3. The method for parallel packaging and task scheduling of game channel packages based on cloud computing according to claim 1, characterized in that, Each packaged task in the global task queue is split into multiple sub-tasks based on the resource dependency type of the processing stage, including: Step 21: Obtain the packaging tasks sequentially from the global task queue to get a set of packaging tasks to be processed; Step 22: parse each packaging task in the set of packaging tasks to be processed, and split each packaging task into multiple sub-tasks according to the differences in resource types that each processing stage, such as code compilation, resource processing, and signing packaging, depends on.

4. The method for parallel packaging and task scheduling of game channel packages based on cloud computing according to claim 1, characterized in that, By labeling subtasks, the resource consumption relationships between them are obtained; by executing each subtask, a global directed acyclic graph of tasks is generated, including: Step 31: Based on the multiple subtasks that have been split, record the execution order and dependencies of each subtask in the packaging process to obtain a set of subtasks and a subtask dependency table. Step 32: Based on the processing stage corresponding to each subtask in the subtask set, obtain the consumption relationship between the stage and CPU, memory and storage resources as the resource consumption feature of the subtask, and add the resource consumption feature to the subtask dependency table to obtain the subtask dependency table with resource consumption feature. Step 33: Convert the subtask dependency table with resource consumption characteristics into a graph structure, using subtasks as nodes, execution order dependencies as directed edges, and resource consumption characteristics as node attributes to generate a global task directed acyclic graph.

5. The method for parallel packaging and task scheduling of game channel packages based on cloud computing according to claim 1, characterized in that, By constraining and verifying the resource consumption correlation of subtasks and the directed acyclic graph, execution nodes are matched for each subtask to generate a global scheduling table, including: Step 41: Extract the resource consumption characteristics of each subtask from the global task directed acyclic graph, and obtain the current available resource status from each execution node to obtain the subtask resource requirement table and the node available resource table. Step 42: Using the subtask resource requirement table and the node available resource table as input, establish resource allocation constraints for each subtask, and gradually narrow down the range of nodes that can be allocated to each subtask through constraint propagation to obtain the candidate node set for each subtask. Step 43: Based on the candidate node set of each subtask, perform resource persistence verification, subsequent dependency resource reservation verification and allocation conflict verification in sequence, eliminate node allocation schemes that do not meet any of the verifications, until each subtask retains at least one feasible allocation node, and obtain the feasible allocation scheme of subtask and execution node. Step 44: Convert the feasible allocation scheme into a mapping relationship between subtasks and execution nodes, and generate a global scheduling table.

6. The method for parallel packaging and task scheduling of game channel packages based on cloud computing according to claim 1, characterized in that, Each execution node executes subtasks in parallel using a global scheduling table and a directed acyclic graph. It records changes in its own resource usage and stores these changes in a cache to generate an execution status table, including: Step 51: Obtain the list of subtasks assigned to each execution node from the global scheduling table, and obtain the dependency relationships between subtasks from the global task directed acyclic graph to obtain the set of subtasks to be executed and the dependency constraint table for each node. Step 52: Each execution node selects subtasks that meet the dependency conditions from the set of subtasks to be executed according to the dependency constraint table and executes them in parallel. During the execution process, the changes in CPU, memory and storage resources occupied by each node due to the execution of subtasks are recorded in real time to obtain the node resource usage record table. Step 53: After each execution node completes its execution, it stores the execution result of the subtask in the result cache area and updates the resource usage status of the corresponding subtask in the node resource usage record table to "completed", thus obtaining the updated node resource usage record table. Step 54: Extract the execution status of each subtask and the resource usage status of each node from the updated node resource usage record table to generate an execution status table.

7. The method for parallel packaging and task scheduling of game channel packages based on cloud computing according to claim 1, characterized in that, Based on the execution status table, identify nodes that are resource-saturated and have a backlog of tasks. Remove any unstarted subtasks from the current scheduling table for these nodes and return to step 4 for reallocation. This will update the global scheduling table, including: Step 61: Extract the resource occupancy status and number of unfinished tasks of each node from the execution status table to obtain the load status table of each node. Step 62: Based on the load status table of each node, identify the nodes whose resource usage has reached the node capacity limit and whose number of unfinished tasks continues to accumulate, as high-load nodes, and obtain the sub-tasks that have not yet started on the high-load nodes to obtain a list of sub-tasks to be reallocated. Step 63: Remove the subtasks in the list of subtasks to be reassigned from the scheduling plan of the high-load node, and return to step 4 to reallocate execution nodes for these subtasks according to the current available resource status of each node, and obtain the reassignment result. Step 64: Update the reallocation results to the global scheduling table to obtain the updated global scheduling table.

8. A cloud-based parallel packaging and task scheduling system for game channel packages, wherein the system implements the method as described in any one of claims 1 to 7, characterized in that, include: The acquisition module is used to acquire the original game resource package and the packaging configuration information of multiple channels, generate packaging tasks for each channel based on the content differences between the two, and aggregate them into a global task queue. The processing module is used to split each packaged task in the global task queue into multiple subtasks according to the resource dependency type of the processing stage; to obtain the resource consumption association of the subtasks by labeling them; and to generate a global task directed acyclic graph by executing each subtask. The verification module is used to constrain and verify the resource consumption correlation of subtasks and the directed acyclic graph, and to match execution nodes for each subtask in order to generate a global scheduling table. Each execution node executes subtasks in parallel through a global scheduling table and a directed acyclic graph, obtains the resource usage changes of each node, and stores them in a cache to generate an execution status table. The update module is used to identify nodes with saturated resources and backlogged tasks based on the execution status table, remove the unstarted subtasks of the node from the current scheduling table, and return to step 4 for reallocation to update the global scheduling table. The control module is used to identify nodes that have made no progress in multiple consecutive scheduling cycles based on the updated global scheduling table and execution status table, reset the unfinished subtasks of the node to the pending scheduling state, and return to step 4 for reallocation. After all subtasks are completed, the results are extracted from the result cache to generate packages for each channel, thus completing parallel packaging and task scheduling.

Images