A distributed task centralized scheduling management method and system

Abstract

The application relates to a distributed task centralized scheduling management method, which comprises the following steps: in response to a task triggering instruction, task configuration information of a to-be-executed task is acquired, and pre-position detection of a running state of the to-be-executed task is carried out based on the task configuration information to determine whether a task starting condition is met; in the case that the task starting condition is met, a target protocol type is determined according to the task configuration information, and if the target protocol type is a remote procedure call protocol, a task execution request is concurrently issued to a plurality of execution nodes associated with the to-be-executed task; task execution results returned by the plurality of execution nodes are asynchronously collected, the task execution results of the plurality of execution nodes are aggregated by constructing a result execution matrix, and an overall execution state of the to-be-executed task is generated. Unified scheduling decisions can be made, a result execution matrix and an overall execution conclusion can be automatically formed, a judgment benchmark can be provided for task triggering and abnormality processing, and the limitation of single-machine execution is broken through.

Description

Technical Field

[0001] This application relates to the field of game operation and maintenance management, and in particular to a distributed task centralized scheduling and management method, system, computer device and computer-readable storage medium. Background Technology

[0002] With the rapid development of the gaming industry, the server-side architecture of modern online games has become increasingly complex, typically employing a distributed microservice architecture deployed across dozens or even hundreds of servers. Game operation involves numerous automated tasks that need to be executed on a scheduled, batch, and cross-server basis, such as scheduled game data backup, cross-server event scheduling, hot updates and version releases, player behavior data analysis, server health checks, game economy system regulation, and security anti-cheat scanning.

[0003] Currently, the most common scheduled task management solutions in the gaming industry rely primarily on built-in scheduled task scheduling tools in operating systems such as Linux Crontab. However, existing technologies have several shortcomings: First, the management methods are outdated and lack a visual interface, leading to conflicts in multi-user collaboration and an inability to meet the large-scale needs of game operations and maintenance. Second, they are limited by single-machine execution, unable to achieve distributed scheduling, and cannot meet the strong demands of cross-server game operations. Third, they lack execution logs and auditing capabilities, resulting in no operational audit chain and making game fault diagnosis difficult. Furthermore, they lack exception handling mechanisms, intelligent retry mechanisms, and support for task dependency orchestration, leaving game service stability unreliable. Finally, insufficient security and permission control expose game data to risks, and limited cross-platform support makes operation and maintenance in mixed environments difficult.

[0004] Therefore, there is an urgent need for a distributed task centralized scheduling and management method and system that can realize unified scheduling and centralized management of tasks in a multi-node environment, enable collaborative execution of tasks across multiple nodes, and ensure controllable execution process. Summary of the Invention

[0005] This application provides a distributed task centralized scheduling and management method, system, computer device, and computer-readable storage medium to at least solve the problem in related technologies that it is impossible to achieve unified scheduling and centralized management of tasks in a multi-node environment.

[0006] In a first aspect, embodiments of this application provide a distributed task centralized scheduling and management method, the method comprising: In response to a task trigger command, the task configuration information of the task to be executed is obtained, and the running status of the task to be executed is pre-detected based on the task configuration information to determine whether the task start conditions are met. If the task start conditions are met, the target protocol type is determined according to the task configuration information. If the target protocol type is a remote procedure call protocol, a task execution request is concurrently sent to multiple execution nodes associated with the task to be executed, so that the multiple execution nodes can collaboratively execute the task to be executed. Asynchronously collect the task execution results returned by multiple execution nodes, and aggregate the task execution results of multiple execution nodes by constructing a result execution matrix to generate the overall execution status of the task to be executed; Post-processing is performed based on the overall execution status, and corresponding subsequent dependent tasks are triggered based on preset task dependencies.

[0007] In some embodiments, the step of performing a pre-running status check on the task to be executed based on the task configuration information to determine whether the task start conditions are met includes: Read the current running status set of the task to be executed, and check whether there are any unfinished running instances of the task to be executed; If an unfinished running instance of the same task is found, the execution will be canceled, queued, or a new execution instance will be generated according to the preset task concurrency strategy. After determining that a new execution instance will be generated, a signal is sent to the buffered concurrency control queue to occupy a global concurrency slot, and after the global concurrency slot is successfully occupied, the running instance of the task to be executed is marked.

[0008] In some embodiments, the step of concurrently issuing task execution requests to multiple execution nodes associated with the task to be executed, so that the multiple execution nodes collaboratively execute the task to be executed, includes: Traverse the list of execution nodes associated with the task to be executed, determine the execution node, and obtain the communication connection corresponding to the multiple execution nodes from the connection resource manager; Create a context control object with a timeout for each execution node, wherein the timeout is determined based on the timeout field in the task configuration information; Through the communication connection, an independent coroutine is asynchronously started for each execution node, and through each independent coroutine, a task execution request containing a task command and the timeout period is concurrently sent to the execution node, so that the execution node concurrently executes the task command within the timeout period.

[0009] The step of aggregating the task execution results of multiple execution nodes by constructing a result execution matrix to generate the overall execution status of the task to be executed includes: Receive the node execution status, output results, execution time, and exception information returned by all the execution nodes; The execution status, output results, and execution time of the nodes are used to construct the result execution matrix; The number of successful nodes, the number of failed nodes, and the number of timeout nodes in the execution matrix are counted, and the success rate of each execution node is generated. Based on the success rate, the number of failed nodes, and a preset node weighting mechanism, the result execution matrix is ​​determined to generate the overall execution status of the task to be executed, which is either successful, partially successful, failed, or timed out.

[0010] In some embodiments, triggering the corresponding subsequent dependent tasks based on preset task dependencies includes: Obtain the list of subtasks and their dependency status attributes configured for the task to be executed; If the dependency status attribute is a strong dependency, all subtasks in the subtask list will be triggered concurrently when the overall execution status of the task to be executed is successful. If the dependency status attribute is a weak dependency, all subtasks in the subtask list will be triggered concurrently, regardless of whether the overall execution status is successful.

[0011] In some embodiments, the method further includes: When the overall execution status of the task to be executed is failed, and the number of retries is configured in the task configuration information, the failure retry logic is entered. In the failure retry logic, if no retry interval is configured, an exponentially increasing strategy is used to determine the retry waiting time, and the task to be executed is re-initiated after waiting for the retry waiting time. If a retry in the retry loop succeeds, the loop is exited and retries are stopped. If the number of iterations of the retry loop exceeds the preset number and the overall execution status is still a failure, the failure retry logic is stopped and exited to prevent infinite retries from wasting resources, and the result of each retry is recorded in the task log.

[0012] In some embodiments, the method further includes a graceful system exit process based on signal capture, the graceful system exit process comprising: When the task to be executed is triggered, increment the global running task counter. Upon receiving a system termination signal, the task scheduler is stopped to reject new timed task triggers and is blocked waiting for the global running task counter to return to zero. Only after the count value reaches zero does the node connection manager begin to be destroyed, all network connections to the execution node be released, the database connection pool be closed, and finally the system process be exited.

[0013] In some embodiments, after determining the target protocol type based on the task configuration information, the method further includes: If the target protocol type is Hypertext Transfer Protocol mode, then the client initiates a request to the target Uniform Resource Locator and determines the task execution result based on the returned response status code.

[0014] Secondly, embodiments of this application provide a distributed task centralized scheduling and management system, the system comprising: a management terminal, a scheduling server, and a game server, wherein... The scheduling server is configured to execute a distributed task centralized scheduling and management method as described in the first aspect; The management terminal is used to: display existing task configuration information through a graphical interface and receive user operation instructions to generate the task configuration information; The game server is used to: run node service software as an execution node, and receive task execution requests issued by the scheduling server through the scheduling receiver in the node service software, and return the execution results.

[0015] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0016] Compared with related technologies, the distributed task centralized scheduling and management method, system, computer equipment, and readable storage medium provided in this application have the following advantages: This application constructs a unified task scheduling and control mechanism that supports visual management, enables one-stop definition and parallel execution across multiple machines, and provides complete execution logs and operation audit links, thereby improving the efficiency of centralized management in large-scale node environments.

[0017] This application establishes a multi-node task collaborative execution and result aggregation mechanism, which can unify scheduling decisions, automatically form a result execution matrix and overall execution conclusion, provide a judgment benchmark for dependent task triggering and exception handling, and break through the limitations of single-machine execution.

[0018] This application establishes a task execution guarantee mechanism, which limits global resource consumption through concurrency control, prevents duplicate execution through single instance control, and combines timeout termination and abnormal retry mechanisms to significantly reduce the risk of task loss of control and abnormal interruption, thereby improving the reliability of distributed scheduling.

[0019] This application features observability and cross-platform unified support capabilities, supports multi-dimensional asynchronous notifications and API integration, and is compatible with mainstream operating systems. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a distributed task centralized scheduling and management method according to an embodiment of this application; Figure 2 This is a structural block diagram of a distributed task centralized scheduling and management system according to an embodiment of this application; Figure 3 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0022] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0023] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0024] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0025] Based on the above system architecture, this embodiment also provides a distributed task centralized scheduling and management method. Figure 1 This is a flowchart of a distributed task centralized scheduling and management method according to an embodiment of this application, such as... Figure 1 As shown, the method flow includes the following steps: S101, in response to the task triggering command, obtains the task configuration information of the task to be executed, and performs a pre-running status check on the task to be executed based on the task configuration information to determine whether the task start conditions are met. In practice, before responding to task trigger commands, the software needs to perform an initialization process. First, it parses command-line parameters to obtain the bound host address, port, and runtime environment configuration. Then, it performs application environment initialization, checks the installation status, reads the version number file, and creates the necessary directory structure.

[0026] Furthermore, the system reads the configuration file and loads parameters such as database connection information, security configuration, and global concurrent queue capacity. It establishes a Transmission Control Protocol (TCP) connection pool with the database using an Object-Relational Mapping framework, configures the maximum number of idle connections (default 5), the maximum number of open connections (default 100), and the maximum connection lifespan (2 hours), and performs database connectivity tests and data table structure comparisons and upgrades.

[0027] In addition, the task scheduling engine is initialized. To ensure the smooth operation of the scheduling server, all active parent tasks are loaded through database pagination (1000 records per page). The time expressions are registered with the scheduler, and a concurrent control queue with a buffered channel (default capacity 500) and a task counter for tracking the number of globally running tasks are initialized. Finally, the web service is started, registering a Hypertext Transfer Protocol (HTTP) middleware processing chain that includes Internet Protocol (IP) whitelist verification, JSON Web Token authentication, interface permission verification, and request signature verification (verifying MD5 (apiKey + timestamp + path + apiSecret) and a 30-minute timestamp validity period), and listening on the request port. In this embodiment, the sources of task triggering instructions include operation instructions that access the user interface through a browser (the front-end page adopts a single-page application (SPA) architecture such as Vue.js; optionally, a Go template engine such as html / template can be used for server-side rendering, and the page can be dynamically generated by the server), application programming interface (API) instructions that are called by third parties through signature verification requests, and automatic triggering instructions initiated by the task scheduling engine using Crontab time expressions.

[0028] For the task scheduling engine's memory-based automatic triggering method, alternatively, a standard library timer (such as time.Ticker) can be used to poll the database to determine whether a task has expired, or an external message queue (such as Redis / RabbitMQ / Kafka) can be introduced to deliver delayed tasks. Furthermore, when a task is triggered, the global running task counter is first incremented to support the system's exit mechanism. Then, the current running status set of tasks to be executed is read to check if any unfinished running instances exist. If an unfinished running instance of the same task is found, the system decides to cancel execution, queue it, or create a new execution instance based on a preset task concurrency strategy, and generates corresponding log records to prevent the same task from being repeatedly triggered before completion, thus avoiding dirty data writes.

[0029] After determining to generate a new execution instance, a signal is sent to the buffered concurrency control queue to reserve a global concurrency slot. If the number of currently running tasks reaches the configured limit (default 500), this reservation operation enters a blocking waiting state until another task completes and releases the slot, thereby preventing too many concurrent tasks from exhausting resources during peak task periods.

[0030] Additionally, in scenarios requiring the deployment of multiple scheduler instances for high availability, the local concurrency control queue can optionally be replaced with a Redis distributed lock or a database row lock to achieve global concurrency control across instances. After successfully securing a global concurrency slot, the running instance of the task to be executed is marked in the set of running instances, and task-level mutual exclusion control is achieved in conjunction with the preceding single-instance detection mechanism. Step S101 uses a buffered concurrency control queue and a single-instance pre-detection mechanism to limit global concurrency and intercept duplicate triggers. This effectively prevents task surges from exhausting system resources and ensures the safety and stability of task triggering.

[0031] S102, if the task start conditions are met, determine the target protocol type according to the task configuration information. If the target protocol type is a remote procedure call protocol, send task execution requests concurrently to multiple execution nodes associated with the task to be executed, so that multiple execution nodes can work together to execute the task to be executed. In this embodiment, execution is performed according to the protocol field of the task configuration information. Specifically, if the target protocol type is Hypertext Transfer Protocol (HTTP), the scheduling server, as a client, initiates a request to the target Uniform Resource Locator (URL), supports custom request methods and headers, and the timeout limit is 300 seconds by default. The task execution result is determined based on the returned response status code. If the status code is not 200, it is considered a failure, and the returned response body content is taken as the execution result. If the target protocol type is Remote Procedure Call (RPC), then the multi-node parallel execution process begins. The list of execution nodes associated with the task to be executed (taskModel.Hosts) is traversed to determine the execution nodes. Furthermore, communication connections corresponding to multiple execution nodes are obtained from the connection resource manager. This connection reuse mechanism avoids the overhead of frequently establishing TCP connections, reducing communication latency. A context control object (context.WithTimeout) with a timeout is created for each execution node, where the timeout is determined based on the timeout field in the task configuration information.

[0032] Furthermore, through communication connections, independent coroutines are asynchronously started for each execution node, and through each independent coroutine, task execution requests containing task commands and timeouts are concurrently sent to the execution node, so that the execution node executes the task commands within the timeout period.

[0033] The scheduling server and execution nodes communicate via the gRPC protocol and perform certificate authentication. Data serialization uses Protocol Buffers binary format to ensure efficient transmission. Optionally, at the communication layer, the underlying gRPC communication can be replaced with HTTP REST interface calls (deploying an HTTP Agent on the node to receive commands). However, it should be noted that the HTTP method lacks native streaming bidirectional communication and binary serialization capabilities, resulting in higher transmission overhead.

[0034] After receiving the request, each execution node executes the command using a cross-platform command execution engine. On the Windows platform, cmd.exe is called (using cmd / C to execute the command and automatically completing the GBK to UTF-8 encoding conversion), while on the Linux or macOS platform, / bin / sh is called (using / bin / sh -c to execute the command). Standard output is captured, and if the timeout period is reached, the node actively terminates the target process and its child processes and returns the timeout status. Step S102, based on connection multiplexing and asynchronous coroutine technology, combined with a cross-platform command engine and timeout context, concurrently sends requests to multiple nodes. This shields the differences in underlying systems, significantly reduces communication latency in high-frequency scheduling, and achieves efficient and controllable parallel execution.

[0035] S103 asynchronously collects the task execution results returned by multiple execution nodes, and aggregates the task execution results of multiple execution nodes by constructing a result execution matrix to generate the overall execution status of the task to be executed. A buffered execution result collection queue is used to asynchronously receive the node execution status, output results, execution time, and exception information returned by all execution nodes. The node execution status, output results, and execution time are used to construct a result execution matrix, which is initially set to a timeout state and is gradually updated as node return data is written. After all nodes return or reach the timeout condition, the number of successful nodes, failed nodes, and timeout nodes in the execution matrix are counted, the average execution time is calculated, and the success rate of each execution node is determined. Based on the success rate, the number of failed nodes, and the preset node weight mechanism, the execution matrix is ​​comprehensively judged to generate the overall execution status of the task to be executed as successful, partially successful, failed, or timed out.

[0036] It is understandable that this result aggregation and status determination mechanism enables the transformation of multi-node tasks from decentralized execution to unified scheduling decisions. Additionally, if the overall execution status of the task to be executed is failed, and the task configuration information specifies a number of retries (configured range 0 to 10), the failure retry logic is initiated. Within this logic, the retry loop executes at most one plus the number of retries. If no retry interval is configured (configured range 0 to 3600 seconds), an exponentially increasing strategy is used to determine the retry waiting time (e.g., 1 minute for the first retry, 2 minutes for the second, 4 minutes for the third, etc.), and the task to be executed is re-initiated after the retry waiting time. This exponentially increasing strategy prevents dense retries from exacerbating failures in scenarios with network jitter or node overload. If a retry in the retry loop succeeds, the loop is exited and retries stop, and the result of each retry is recorded in the task log. Step S103 utilizes an asynchronous queue to collect the specific output and execution time of each server, summarizing and generating a result matrix containing success rate and failure count. Based on this, the success or failure of the overall task and the execution result of each node are directly determined, eliminating the tedious manual troubleshooting of each server. At the same time, the failure retry strategy adopts a strategy of doubling the waiting time, realizing automatic decision-making on the execution results of massive nodes, and avoiding server blocking due to frequent requests when the network is abnormal.

[0037] S104, perform post-processing based on the overall execution status, and trigger corresponding subsequent dependent tasks based on preset task dependencies. After task execution, the update log status is changed to "completed" or "failed," and the execution result output, total time, and end time of each node are persistently written. The system determines whether to send an alarm notification based on the task's configured notification policy. Notification policies include four categories: no notification, notification only on failure, notification after each execution, and keyword matching notification (triggered when the execution result contains a keyword specified in the key field). Notification channels include email (SMTP), Slack (Webhook), and custom Webhook, and custom message templates are supported. Notification sending uses an asynchronous buffer queue design (capacity of 100) and has a failure retry mechanism (automatically retrying 3 times with a 2-second interval after a failed send), without blocking the main process. Retrieve the list of subtasks and their dependency status attributes configured for the task to be executed, and perform automated pipeline orchestration. If the dependency status attribute is a strong dependency, all subtasks in the subtask list will be triggered concurrently when the overall execution status of the task to be executed is successful (e.g., after a successful database backup, the backup data verification will be triggered first, followed by the upload to remote storage). If the dependency status attribute is a weak dependency, all subtasks in the subtask list will be triggered concurrently regardless of the parent task's status (e.g., the result notification task will be triggered regardless of whether the backup was successful). The triggered subtasks are executed concurrently through independent coroutines, and each subtask independently follows the aforementioned complete lifecycle process. Finally, after post-processing is complete, the concurrent slots are released through the defer mechanism, the single-instance running flag is cleared, and the task counter is decremented to allow waiting tasks to begin execution. Step S104 concurrently triggers subtasks based on strong and weak dependencies, combined with asynchronous multi-channel alarms and a resource release mechanism based on delayed calls. This achieves fully automated orchestration of complex business pipelines, eliminates manual intervention, and ensures long-term stable system operation.

[0038] This embodiment also includes a signal-capture-based exit process to ensure state consistency during service upgrades or maintenance. When a task to be executed is triggered, the global running task counter is incremented. Upon receiving a termination signal (such as SIGINT or SIGTERM), the task scheduler stops to reject new scheduled task triggers and blocks until the global running task counter reaches zero. After the counter reaches zero, the node connection manager is destroyed, all network connections to the execution node are released, the database connection pool is closed, and finally, the process exits safely to prevent data anomalies caused by forced interruption of execution. It is important to emphasize that not actively accepting new task instances and completing the execution of old, remaining task instances is the first step of the exit process. Exiting the system process, as the final step in the graceful exit process, controls the timing of resource release through a blocking and waiting mechanism. That is, the remaining old task instances must be completed first, and only after the resource cleanup actions such as destroying the node connection manager, releasing network connections, and closing the database connection pool are fully completed will the system process exit operation be finally executed. This timing control ensures that all running tasks complete the post-processing steps, avoiding the risk of data anomalies caused by forced interruption. In an exemplary embodiment, taking an automated pipeline scenario of cross-server battlefield activities in an online game as an example, the scheduling server periodically triggers a parent task, concurrently sending synchronous activity configuration requests to 20 game server nodes in RPC mode. After all nodes return success, a subtask to verify configuration loading is concurrently triggered based on strong dependencies. After verification, strongly dependent subtasks to start the matching service (HTTP mode) and check the database connection pool status (RPC mode) are concurrently triggered. Simultaneously, based on weak dependencies, an activity status notification is sent to the operations Slack group, and a subtask to back up the configuration snapshot is executed. The entire process is automated and requires no manual intervention.

[0039] Through steps S101 to S104 above, relying on a distributed architecture and memory-level scheduling, multi-node parallel distribution is achieved through connection reuse and a cross-platform engine. This breaks through the limitations of traditional Crontab single-machine execution and lack of auditing, constructing a closed-loop system for automated operations and maintenance that is defined once and runs in parallel across multiple machines. It improves the execution efficiency and reliability of complex task chains, prevents resource loss and data corruption, and provides technical support for large-scale distributed operations and maintenance.

[0040] This embodiment provides a distributed task centralized scheduling and management system, which is deployed within a multi-node interconnected network architecture. Figure 2 This is a structural block diagram of a distributed task centralized scheduling and management system according to an embodiment of this application, such as... Figure 2 As shown, the system includes a management terminal, a scheduling server, a database server, and at least one game server execution node. The management terminal is a PC or mobile device, accessing the system's web management interface via a browser using the HTTP / HTTPS protocol; the scheduling server (usually equipped with 2 cores and more than 4GB of memory) runs task scheduling service software, including web services, a task scheduling engine, and task management and business processing modules; the game server execution nodes (including login server, game server, chat server, etc.) deploy node service software (approximately 10MB binary file) containing a scheduling receiver, command execution engine, and system resource access layer; and the database server (running MySQL or PostgreSQL) is responsible for the persistent storage of task metadata and execution logs.

[0041] Furthermore, the management terminal displays task configuration information and system operating status through a visual graphical interface. Compared to traditional command-line-based management methods, this visual graphical interface intuitively presents the distribution and execution history of multi-node tasks, eliminating the shortcomings of traditional solutions such as lack of a visual interface and scattered logs. By transforming the complex underlying distributed scheduling logic into an intuitive graphical display, it significantly reduces the learning cost and operational threshold for operators, providing an easy-to-understand and efficient human-computer interaction experience.

[0042] Furthermore, both the task scheduling service software and the node service software in this embodiment are developed based on the Go language. Their single code is compiled into a static binary file by the Go language, and can run on operating systems such as Windows, Linux, and macOS without the need to install additional runtime dependencies.

[0043] As a preferred embodiment, the node service software can be compiled into a static binary file of approximately 10MB in size, requiring no additional runtime dependencies. This lightweight design ensures that the node service software consumes very few system resources such as CPU and memory when asynchronously receiving scheduling instructions and executing tasks in the background. This avoids resource contention with the main game process, thereby ensuring the high concurrency and stable operation of the game server while performing automated maintenance tasks.

[0044] It should be noted that the above system can also adopt a centralized monolithic architecture, in which a single process undertakes both scheduling decision-making and local command execution responsibilities, cancels the automatic generation mechanism of multi-node execution plans, and all tasks are executed locally on the same server. This can also meet the needs of distributed batch scheduling, that is, the scheduling server is on the same machine as a certain node and other multiple nodes run together.

[0045] In one embodiment, Figure 3 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application, such as... Figure 3 As shown, an electronic device is provided, which can be a server, and its internal structure diagram can be as follows. Figure 3 As shown, the electronic device includes a processor, a network interface, internal memory, and non-volatile memory connected via an internal bus. The non-volatile memory stores the operating system, computer programs, and a database. The processor provides computing and control capabilities, the network interface communicates with external terminals via a network, the internal memory provides an environment for the operation of the operating system and computer programs, the computer programs are executed by the processor to implement a distributed task centralized scheduling and management method, and the database stores data.

[0046] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0047] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for centralized scheduling and management of distributed tasks, characterized in that, The method includes: In response to a task trigger command, the task configuration information of the task to be executed is obtained, and the running status of the task to be executed is pre-detected based on the task configuration information to determine whether the task start conditions are met. If the task start conditions are met, the target protocol type is determined according to the task configuration information. If the target protocol type is a remote procedure call protocol, task execution requests are concurrently sent to multiple execution nodes associated with the task to be executed, so that the multiple execution nodes can collaboratively execute the task to be executed. Asynchronously collect the task execution results returned by multiple execution nodes, and aggregate the task execution results of multiple execution nodes by constructing a result execution matrix to generate the overall execution status of the task to be executed; Post-processing is performed based on the overall execution status, and corresponding subsequent dependent tasks are triggered based on preset task dependencies.

2. The method according to claim 1, characterized in that, The step of performing a pre-running status check on the task to be executed based on the task configuration information to determine whether the task start conditions are met includes: Read the current running status set of the task to be executed, and check whether there are any unfinished running instances of the task to be executed; If an unfinished running instance of the same task is found, the execution will be canceled, queued, or a new execution instance will be generated according to the preset task concurrency strategy. After determining that a new execution instance will be generated, a signal is sent to the buffered concurrency control queue to occupy a global concurrency slot, and after the global concurrency slot is successfully occupied, the running instance of the task to be executed is marked.

3. The method according to claim 1, characterized in that, The step of concurrently issuing task execution requests to multiple execution nodes associated with the task to be executed, so that the multiple execution nodes can collaboratively execute the task to be executed, includes: Traverse the list of execution nodes associated with the task to be executed, determine the execution node, and obtain the communication connection corresponding to the multiple execution nodes from the connection resource manager; Create a context control object with a timeout for each execution node, wherein the timeout is determined based on the timeout field in the task configuration information; Through the communication connection, an independent coroutine is asynchronously started for each execution node, and through each independent coroutine, a task execution request containing a task command and the timeout period is concurrently sent to the execution node, so that the execution node executes the task command within the timeout period.

4. The method according to claim 1, characterized in that, The step of aggregating the task execution results of multiple execution nodes by constructing a result execution matrix to generate the overall execution status of the task to be executed includes: Receive the node execution status, output results, execution time, and exception information returned by all the execution nodes; The execution status, output results, and execution time of the nodes are used to construct the result execution matrix; The number of successful nodes, the number of failed nodes, and the number of timeout nodes in the execution matrix are counted, and the success rate of each execution node is generated. Based on the success rate, the number of failed nodes, and a preset node weighting mechanism, the result execution matrix is ​​determined to generate the overall execution status of the task to be executed, which is either successful, partially successful, failed, or timed out.

5. The method according to claim 4, characterized in that, The triggering of corresponding subsequent dependent tasks based on preset task dependency relationships includes: Obtain the list of subtasks and their dependency status attributes configured for the task to be executed; If the dependency status attribute is a strong dependency, all subtasks in the subtask list will be triggered concurrently when the overall execution status of the task to be executed is successful. If the dependency status attribute is a weak dependency, all subtasks in the subtask list will be triggered concurrently, regardless of whether the overall execution status is successful.

6. The method according to claim 1, characterized in that, The method further includes: When the overall execution status of the task to be executed is failed, and the number of retries is configured in the task configuration information, the failure retry logic is entered. In the failure retry logic, if no retry interval is configured, an exponentially increasing strategy is used to determine the retry waiting time, and the task to be executed is re-initiated after waiting for the retry waiting time. If a retry in the retry loop succeeds, the loop is exited and retries are stopped. If the number of iterations of the retry loop is greater than the preset number, and the overall execution status is still a failure, the failure retry logic is stopped and exited.

7. The method according to claim 1, characterized in that, The method also includes a graceful system exit process based on signal acquisition, the graceful system exit process comprising: When the task to be executed is triggered, increment the global running task counter. Upon receiving a system termination signal, the task scheduler is stopped to reject new timed task triggers and is blocked waiting for the global running task counter to return to zero. After the count value reaches zero, the node connection manager is destroyed and all network connections to the execution node are released, the database connection pool is closed, and finally the system process exits.

8. The method according to claim 1, characterized in that, After determining the target protocol type based on the task configuration information, the method further includes: If the target protocol type is Hypertext Transfer Protocol mode, then the client initiates a request to the target Uniform Resource Locator and determines the task execution result based on the returned response status code.

9. A distributed task centralized scheduling and management system, characterized in that, The system includes: a management terminal, a scheduling server, and a game server, wherein, The scheduling server is configured to execute a distributed task centralized scheduling and management method as described in any one of claims 1-8; The management terminal is used to: display existing task configuration information through a graphical interface and receive user operation instructions to generate the task configuration information; The game server is used to: run node service software as an execution node, and receive task execution requests issued by the scheduling server through the scheduling receiver in the node service software, and return the execution results.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 8.

Images