A remote task distribution and management method and system

Abstract

This application provides a remote task delivery management method and system, relating to the technical field of task delivery management. The method includes: firstly, acquiring the tasks to be delivered, the task cycle, and the task delivery objects, and counting the number of task delivery objects; calculating the initial delivery frequency and formulating an initial delivery strategy based on this; constructing a fuzzy control model and setting membership functions and rule bases; deploying the initial strategy to the server, acquiring real-time resource and bandwidth utilization, setting concurrency coefficients through the fuzzy control model, and adjusting the initial delivery frequency in real time to obtain the target delivery strategy; and the server sending tasks according to this strategy. This application can dynamically adjust the task delivery frequency and concurrency coefficients based on the server's real-time resource utilization and network bandwidth utilization, thereby reducing the risk of server overload or network congestion and enabling tasks to be executed efficiently according to the predetermined plan.

Description

Technical Field

[0001] This application relates to the technical field of task assignment management, and in particular to a remote task assignment management method and system. Background Technology

[0002] In today's digital and information-driven era, various business systems and applications are widely distributed across different geographical locations and device terminals. Many enterprises and organizations need unified task management and scheduling for these dispersed systems and devices to achieve efficient business operations. Remote task dispatch management has emerged to address this need. It allows managers to send task instructions from a central location to multiple remote task dispatch objects (such as distributed servers, mobile terminal devices, etc.), enabling each task to be executed according to predetermined plans and requirements.

[0003] Currently, existing remote task delivery management technologies primarily employ a fixed-frequency delivery strategy. Specifically, after determining the tasks to be delivered, their duration, and the recipients, the system assigns a fixed delivery frequency to each task based on preset rules. However, under conditions of limited server resources or network bandwidth, this fixed-frequency delivery can lead to excessive server load, potentially causing system crashes. It can also result in network congestion, impacting the normal operation of other services. Summary of the Invention

[0004] In order to dynamically adjust the frequency of task distribution to reduce the risk of server overload or network congestion and to ensure that tasks are executed efficiently according to the predetermined plan, this application provides a remote task distribution management method and system.

[0005] Firstly, this application provides a remote task distribution and management method, which adopts the following technical solution:

[0006] A remote task distribution and management method includes the following steps:

[0007] Get the tasks to be issued, the task cycle, and the task objects; count the number of task objects; calculate the initial issuance frequency based on the number of task objects and the task cycle; and formulate the initial issuance strategy based on the tasks to be issued, the task objects, and the initial issuance frequency.

[0008] Construct a fuzzy control model and set its membership function and rule base;

[0009] The initial distribution strategy is deployed to the server, and the server's real-time resource utilization and network bandwidth utilization are obtained. Based on the real-time resource utilization and network bandwidth utilization, a concurrency coefficient is set through a fuzzy control model. The initial distribution frequency in the initial distribution strategy is adjusted in real time according to the concurrency coefficient to obtain the target distribution strategy. The server sends the tasks to be distributed to the task distribution object according to the target distribution strategy.

[0010] This application calculates the initial task distribution frequency based on the number of task recipients and the task cycle. It then formulates an initial distribution strategy by combining the tasks to be distributed, the task recipients, and the initial distribution frequency. Based on objective data, this improves the rationality and predictability of task distribution, reducing resource waste and the risk of task backlog. Subsequently, this application uses fuzzy logic to set a concurrency coefficient based on server resource utilization (CPU, memory, etc.) and network bandwidth utilization. The initial distribution strategy is adjusted according to the concurrency coefficient to obtain the target distribution strategy. This allows for dynamic adjustment of the task distribution frequency using real-time server resource utilization and network bandwidth utilization, ensuring that task distribution matches the current resource status and improving resource utilization. Finally, the server executes task distribution according to the target strategy. By fuzzy control balancing task distribution speed and resource consumption, this application reduces the risk of server overload or network congestion and improves task execution efficiency.

[0011] Optionally, before counting the number of objects to be assigned the task, the method further includes:

[0012] Status judgment: Determine whether the i-th task distribution object is online. If yes, mark the i-th task distribution object as an intermediate object and execute the load judgment step; otherwise, update the (i+1)-th task distribution object to the i-th task distribution object and re-execute the status judgment step.

[0013] Load assessment: Real-time acquisition of intermediate object's running data, including CPU utilization, memory usage, and task failure rate. Calculation of the load index using a weighted average algorithm and the running data. Determination of whether the load index is less than a preset threshold. If so, the intermediate object is updated to the target object; otherwise, no action is taken.

[0014] Update Object: Update the target object to the task assignment object.

[0015] By adopting the above scheme, this application can distribute tasks to online task distribution objects with low load index, reducing the risk of task failure or repeated retries due to offline objects, and improving the reliability of task distribution.

[0016] Optionally, after calculating the initial distribution frequency based on the number of task recipients and the task cycle, the method further includes:

[0017] Monitor the task execution status of the task-issuing object, obtain the task start time and task completion time, calculate the actual execution time based on the task start time and task completion time, calculate the initial execution time based on the initial issuance frequency, record the minimum value between the initial execution time and the actual execution time as the first data, and calculate the new initial issuance frequency based on the first data.

[0018] This application calculates the initial distribution frequency based on the number of task distribution objects and the task cycle, using this initial distribution frequency as the theoretical maximum distribution capacity benchmark. Subsequently, this application records the start and end times of each task's download and calculates the actual execution time based on this, quantifying the actual processing time of the task on the task distribution object's side and reflecting the actual load capacity of the task distribution object. Finally, this application calculates the initial execution time based on the initial distribution frequency, using the minimum of the initial execution time and the actual execution time as the first data. A new initial distribution frequency is then calculated based on this first data. Through this scheme, this application can dynamically adjust the frequency according to the actual execution time, automatically adapting to the performance fluctuations of the task distribution object and reducing task backlog or timeouts.

[0019] Optionally, before performing the state determination step, the method further includes:

[0020] Each task-assigned object sends a heartbeat packet to the server according to a preset heartbeat period. The server updates the running status of the task-assigned object based on the heartbeat message in the heartbeat packet. The heartbeat packet includes the UUID, timestamp, and running status of the task-assigned object. The running status includes online status and offline status.

[0021] A task object queue is constructed, which includes an offline queue and an online queue. Task objects in the offline state are placed in the offline queue according to the heartbeat packet sending time, and task objects in the online state are placed in the online queue according to the heartbeat packet sending time.

[0022] This application uses a heartbeat mechanism to monitor the status of task distribution objects in real time, which can reduce the status update delay. This application also incorporates a dynamic queue management scheme to improve the reliability, efficiency and maintainability of the task distribution process.

[0023] Optionally, the method further includes:

[0024] Status verification: The server marks task distribution objects that have not received a heartbeat packet after exceeding the heartbeat timeout threshold as objects with questionable status. The server initiates active probing on objects with questionable status, obtains the active probing results, and updates the running status of objects with questionable status based on the active probing results.

[0025] Get the updated running status of the object with questionable status, and determine whether the running status of the object with questionable status has changed. If yes, deploy the object with questionable status to the tail of the corresponding task object queue according to the updated status, and output the new online queue and the new offline queue; if no, resend the task to be sent to the task sending object.

[0026] The server marks task assignment objects that fail to send heartbeat packets within the heartbeat timeout threshold as objects with questionable status, reducing false positives caused by network interruptions or object processing delays. The server then initiates active probing of these objects to obtain the results. If the object is still alive (i.e., online), the timeout is considered to have occurred due to lost or delayed heartbeat packets; otherwise, it is considered truly offline or faulty. The server then corrects the object's running status based on the probing results and re-places it at the tail of the corresponding queue with the updated status, reducing the risk of unstable task allocation caused by frequent queue head adjustments. By employing this scheme, brief heartbeat loss will not cause objects with questionable status to be mistakenly removed from the online queue, and the active probing mechanism can quickly restore their status, improving fault tolerance.

[0027] Optionally, the method further includes: the task distribution object that has been updated from offline to online status automatically sends an init command to the server, and the server deploys the task distribution object that has been updated from offline to online status to the tail of the online queue.

[0028] By adopting the above technical solution, this application uses the init instruction to force synchronization of the state of the task distribution object, making the state of the server and the task distribution object mutually visible. Figure 1 Since periodically probing all offline task assignment objects by the server consumes significant resources, this approach allows task assignment objects to proactively report status changes, requiring the server to handle only a small number of init commands, thus reducing network load and computational overhead. Subsequently, this application redeploys these objects to the tail of the online queue, enabling them to quickly rejoin the task allocation process after restarting or network recovery, minimizing service interruption time.

[0029] Optionally, before performing the state verification step, the method further includes:

[0030] Obtain the timestamps from the N historical heartbeat packets of each task-issued object, and record them as historical timestamps. Calculate the time interval between adjacent historical heartbeat packets according to the historical timestamps. Use the DBSCAN algorithm to cluster all time intervals to obtain multiple clusters. Count the number of time intervals contained in each cluster. Record the cluster with the largest number of time intervals as the target cluster. Record the largest time interval in the target cluster as the heartbeat timeout threshold.

[0031] This application uses cluster analysis to analyze historical heartbeat data, identifying the central trend of normal heartbeat intervals. This allows for the automatic identification of normal fluctuation ranges under the current network and task load, making the heartbeat timeout threshold more closely aligned with real-world scenarios. Furthermore, this application selects the maximum value of the target cluster as the heartbeat timeout threshold. The maximum value of the target cluster reflects the worst-case heartbeat interval of the task under normal conditions, thus balancing sensitivity and fault tolerance.

[0032] Optionally, before using the largest time interval in the target cluster as the heartbeat timeout threshold, the method further includes:

[0033] Determine if there are multiple clusters where the number of time intervals exceeds a preset threshold. If so, the clusters with the number of time intervals exceeding the preset threshold are recorded as valid clusters. If not, the largest time interval in the target cluster is used as the heartbeat timeout threshold.

[0034] Label the time intervals in each valid cluster, construct a BI-LSTM model, and train the BI-LSTM model using the labeled time intervals to obtain the trained BI-LSTM model.

[0035] Get the time intervals of the M heartbeat packets sent by the task recipient before the current time, and denote them as the second data. Input all the second data into the trained BI-LSTM model in chronological order, and output the predicted labels.

[0036] The maximum time interval in the effective cluster corresponding to the predicted label is recorded as the third data, and the third data is used as the heartbeat timeout threshold.

[0037] This application identifies multiple effective patterns of heartbeat time intervals through cluster analysis, combines a BI-LSTM model to dynamically predict the current heartbeat pattern and adaptively adjust the timeout threshold, thereby improving the sensitivity to network fluctuations and device differences, and realizing the function of setting different heartbeat timeout thresholds according to different effective models.

[0038] Optionally, when the task distribution object is offline or the number of times the task to be distributed is resent to the task distribution object exceeds the preset retry threshold, the server starts the task caching mechanism to store the tasks to be distributed in the Redis queue in chronological order.

[0039] When a task cannot be directly delivered due to the task object being offline or exceeding the retry limit, the server directly discards the offline or failed retry tasks. This may result in critical operations (such as device configuration updates and data synchronization) not being executed, causing business anomalies. Therefore, this application activates a task caching mechanism in the above situations, storing tasks to be delivered in a Redis queue in chronological order. After the task object is restored to online status or the fault is repaired, the server can retrieve the task from the cache queue and redeliver it without manual intervention or external triggering, achieving self-healing fault tolerance. When a task object is offline or has a persistent failure, continuous retries waste network bandwidth, server CPU, and thread resources. The caching mechanism delays retries until the object becomes available, reducing resource consumption.

[0040] Secondly, this application provides a remote task distribution and management system, which adopts the following technical solution:

[0041] A remote task distribution and management system includes: a memory and a processor.

[0042] The memory contains a computer-readable storage medium;

[0043] When the processor processes a computer program stored on the computer-readable storage medium, it implements the method described in the first aspect.

[0044] In summary, this application includes at least one of the following beneficial technical effects:

[0045] 1. This application calculates the initial task distribution frequency based on the number of task recipients and the task cycle. It then formulates an initial distribution strategy by combining the tasks to be distributed, the task recipients, and the initial distribution frequency. Based on objective data, this improves the rationality and predictability of task distribution, reducing resource waste and the risk of task backlog. Subsequently, this application uses fuzzy logic to set a concurrency coefficient based on server resource utilization (CPU, memory, etc.) and network bandwidth utilization. The initial distribution strategy is adjusted according to the concurrency coefficient to obtain the target distribution strategy. This allows for dynamic adjustment of the task distribution frequency using real-time server resource utilization and network bandwidth utilization, ensuring that task distribution matches the current resource status and improving resource utilization. Finally, the server executes task distribution according to the target strategy. By fuzzy control balancing task distribution speed and resource consumption, this application can reduce the risk of server overload or network congestion and improve task execution efficiency.

[0046] 2. This application can distribute tasks to online task distribution objects with low load, reducing the risk of task failure or repeated retries due to offline objects, and improving the reliability of task distribution. Attached Figure Description

[0047] Figure 1 This is a flowchart of Embodiment 1 of this application;

[0048] Figure 2 This is a flowchart of Embodiment 2 of this application;

[0049] Figure 3 This is a flowchart of Embodiment 3 of this application. Detailed Implementation

[0050] The following combination Figures 1 to 3 This application will be described in further detail.

[0051] Example 1: This example discloses a remote task distribution and management method, referring to... Figure 1 The method includes: S11 data acquisition, S12 modeling, and S13 task distribution. First, the tasks to be distributed, their cycles, and the objects to be distributed are obtained, and the number of objects is counted. Based on this, the initial distribution frequency is calculated, and an initial distribution strategy is formulated. Then, a fuzzy control model is constructed, and membership functions and rule bases are set. Next, the initial strategy is deployed to the server, and its real-time resource and bandwidth utilization are obtained. Concurrency coefficients are set using the fuzzy control model, and the initial distribution frequency is adjusted in real-time to obtain the target distribution strategy. Finally, the server sends tasks according to this strategy. The execution of each step in this embodiment is as follows:

[0052] S11 data acquisition obtains the tasks to be issued, the task cycle, and the task recipients.

[0053] The tasks to be distributed refer to files used for application installation or upgrades on different platforms, including two categories: installation packages and portable packages. Installation packages are special compressed files that require clicking to install or upgrade on different platforms, such as DEB files, RPM files, and EXE files. Portable packages are collections of binary files that can be run directly after decompression.

[0054] In this embodiment, multiple tasks for the same application will not be issued. The uniqueness of the upgrade package is determined by the following criteria: category + version number + CPU architecture + applicable device type.

[0055] The task cycle depends on the nature and requirements of the task. For periodically executed tasks, such as regularly reporting application data, the cycle is set to a fixed time interval, such as hourly, daily, or weekly, depending on business requirements. For ad-hoc tasks, such as patching an application, the cycle is shorter, and may even require immediate execution. The task cycle is expressed in units of time, such as seconds, minutes, hours, and days.

[0056] The task distribution target refers to the terminal that needs to receive and execute the task, that is, the client corresponding to the task to be distributed.

[0057] The server maintains a list of task distribution objects, which is used to update the status information of each task distribution object in real time, including whether it is online and its load status. The server can count the number of task distribution objects by iterating through the list or using database statistical functions (such as the COUNT function). For example, if the database stores a list of task distribution objects, which includes fields such as UUID of the task distribution objects, the number of task distribution objects can be obtained by executing the SQL statement "SELECT COUNT(device_id) FROM device_table".

[0058] The initial distribution frequency can be calculated based on the task cycle and the number of task distribution objects. The calculation method is: initial distribution frequency = 1 / (task cycle / number of task distribution objects).

[0059] For example, if the task period is 3600 seconds and the number of objects to be tasked is 10, then the initial task sending frequency = 1 / (3600 / 10) ≈ 0.0278 times / second, that is, the server sends out a task approximately every 36 seconds.

[0060] The initial delivery strategy clearly defines how to allocate tasks to be delivered to various task delivery objects, including the delivery time order and delivery method. For example, for a sequential delivery strategy, tasks can be sent in order according to a certain sorting rule of the task delivery objects (such as ascending or descending order of device ID); for a broadcast delivery strategy, tasks can be sent to all task delivery objects in parallel.

[0061] S12 modeling constructs a fuzzy control model, which is a control system based on fuzzy logic capable of handling uncertain and fuzzy information. The fuzzy control model includes a fuzzification module, a fuzzy inference module, and a defuzzification module. The fuzzification module converts the precise input values ​​into fuzzy sets; the fuzzy inference module infers from the fuzzy set according to rules in the fuzzy rule base, deriving a fuzzy output result; and the defuzzification module converts the fuzzy output result into concurrency coefficients.

[0062] There is a dynamic coupling relationship between server-side resource utilization (CPU / memory) and network bandwidth utilization, and their impact on concurrency coefficients exhibits non-linear characteristics (e.g., bandwidth changes have a sudden impact on the system when resources are saturated), making them difficult to describe with precise numerical values. Fuzzy control models, by establishing a fuzzy rule base and membership functions, map the aforementioned fuzzy input information into concurrency coefficients, thereby adjusting the initial distribution frequency.

[0063] First, determine the parameters of the membership function based on the actual range of real-time resource utilization and network bandwidth utilization on the server side and business requirements.

[0064] For example, real-time resource utilization and network bandwidth utilization are divided into three fuzzy sets: low, medium, and high, and the vertex coordinates of the triangular membership function corresponding to each fuzzy set are determined.

[0065] In this embodiment, the range of real-time resource utilization or network bandwidth utilization is 0%-100%. The cases for the three fuzzy sets of low, medium, and high are as follows:

[0066] The vertex coordinates of the low-fuzzy set are (0,0), (30,1), and (30,0), indicating that the real-time resource utilization rate or network bandwidth utilization rate is between 0% and 30%. The membership function calculation model is as follows:

[0067] ;

[0068] represents the membership degree; x represents the resource utilization rate.

[0069] The vertex coordinates of the medium fuzzy set are (20,0), (50,1), and (70,0), indicating that the real-time resource utilization rate or network bandwidth utilization rate is between 20% and 70%, belonging to the medium fuzzy set. Its membership function calculation model is as follows:

[0070] ;

[0071] The vertex coordinates of the highly fuzzy set are (60,0), (100,1), and (100,0), indicating that the real-time resource utilization rate or network bandwidth utilization rate is between 60% and 100%. The membership function calculation model is as follows:

[0072] .

[0073] In other embodiments, the membership function may also be a trapezoidal membership function or a Gaussian membership function.

[0074] The rules in the rule base are formulated based on expert experience or actual business needs, and are used to describe the logical relationship between input variables (real-time resource utilization and network bandwidth utilization) and output variables (concurrency coefficient).

[0075] In this embodiment, the rule base for setting the fuzzy control model includes the following rules:

[0076] Rule 1: If both real-time resource utilization and network bandwidth utilization are low, then the concurrency coefficient is high;

[0077] Rule 2: If the real-time resource utilization rate is low and the network bandwidth utilization rate is medium, then the concurrency coefficient is medium.

[0078] Rule 3: If real-time resource utilization is low and network bandwidth utilization is high, then the concurrency coefficient is low;

[0079] Rule 4: If the real-time resource utilization rate is medium and the network bandwidth utilization rate is low, then the concurrency coefficient is medium;

[0080] Rule 5: If the real-time resource utilization rate is medium and the network bandwidth utilization rate is medium, then the concurrency coefficient is medium.

[0081] Rule 6: If the real-time resource utilization is medium and the network bandwidth utilization is high, then the concurrency coefficient is low;

[0082] Rule 7: If real-time resource utilization is high and network bandwidth utilization is low, then the concurrency coefficient is low;

[0083] Rule 8: If real-time resource utilization is high and network bandwidth utilization is medium, then the concurrency coefficient is low;

[0084] Rule 9: If both real-time resource utilization and network bandwidth utilization are high, then the concurrency coefficient is low.

[0085] The rule base uses the Mamdani inference method for fuzzy inference. The activation strength of each rule is taken as the minimum value of the membership degree. The inference results are defuzzified by the centroid method to obtain the specific values ​​of the concurrency coefficients.

[0086] S13 issues tasks by deploying the pre-defined initial task issuance strategy to the server in the form of configuration files or program code. The configuration files use formats such as XML and JSON for easy reading and modification; the program code can be integrated into the server's task scheduling module to achieve automated task issuance.

[0087] Real-time resource utilization on the server side includes CPU utilization, memory utilization, etc. This can be obtained through interfaces provided by the operating system or third-party monitoring tools.

[0088] Network bandwidth utilization can be obtained using network monitoring tools such as iftop and nload.

[0089] The acquired real-time resource utilization and network bandwidth utilization are fuzzified and converted into fuzzy sets that the fuzzy control model can recognize. The fuzzified input variables are then fed into the rule base of the fuzzy control model for inference. Based on the membership degrees of the input variables and the rules in the rule base, the fuzzy values ​​of the concurrency coefficients are calculated. The fuzzy values ​​of the concurrency coefficients obtained from fuzzy inference are then defuzzified and converted into precise values.

[0090] For example, if the server's real-time resource utilization is 65% and the network bandwidth utilization is 25%, then according to the above formula for calculating the membership function, the membership degree corresponding to a real-time resource utilization of 65% is 0.125 for the high-level membership and 0.25 for the middle-level membership. Similarly, the membership degree corresponding to a network bandwidth utilization of 25% is approximately 0.17 for the middle-level membership and approximately 0.83 for the low-level membership.

[0091] Based on the logic of fuzzy inference, the membership degrees of the input variables are combined and matched. The matching rules in this embodiment are as follows:

[0092] Rule 4: If the real-time resource utilization rate is medium and the network bandwidth utilization rate is low, then the concurrency coefficient is medium and the activation strength is 0.25;

[0093] Rule 5: If the real-time resource utilization rate is medium and the network bandwidth utilization rate is medium, then the concurrency coefficient is medium and the activation strength is 0.17.

[0094] Rule 7: If the real-time resource utilization rate is high and the network bandwidth utilization rate is low, then the concurrency coefficient is low and the activation strength is 0.125;

[0095] Rule 8: If the real-time resource utilization rate is high and the network bandwidth utilization rate is medium, then the concurrency coefficient is low and the activation strength is 0.125;

[0096] Based on the activation rules, the Mamdani inference method is used to prune the output fuzzy set:

[0097] Rule 4: The membership degree from x=40% to x=70% is limited to 0.25.

[0098] Rule 5: The membership degree from x=40% to x=70% is limited to 0.17.

[0099] Rule 7 / Rule 8: The membership degree from x=0% to x=60% is limited to 0.125.

[0100] The membership degree for x=80% to x=100% is limited to 0 because there is no corresponding rule.

[0101] Merge all cropped output fuzzy sets, calculate the centroid, and the calculation model is as follows:

[0102] ;

[0103] After discretization, the calculation model is as follows:

[0104] ;

[0105] The membership values ​​of the concurrency coefficients after discretization are shown in Table 1.

[0106] Table 1. Schematic diagram of the membership values ​​of the concurrency coefficients after discretization.

[0107] Concurrency coefficient Membership degree 0% 0.125 10% 0.125 20% 0.125 30% 0.125 40% 0.25 50% 0.25 60% 0.25 70% 0.25 80% 0 90% 0 100% 0

[0108] The calculated concurrency coefficient values ​​are:

[0109] 0.125×(0+10+20+30)+0.25×(40+50+60+70)=62.5;

[0110] 0.125×4+0.25×4=1.5;

[0111] 62.5 ÷ 1.5 ≈ 0.4167;

[0112] The initial distribution frequency is adjusted using a concurrency coefficient, calculated using the following formula:

[0113] The adjusted initial distribution frequency = initial distribution frequency × concurrency coefficient.

[0114] The adjusted initial distribution frequency is integrated with parameters in other initial distribution strategies (such as distribution method, distribution order, etc.) to obtain a complete target distribution strategy, which is then stored in the server's database or configuration file.

[0115] According to the delivery method specified in the target delivery strategy, the server sends the tasks to be delivered to the task delivery objects. If it's a unicast method, the server needs to establish a connection with each task delivery object and send the task; if it's a broadcast method, the server can send the task to all task delivery objects via a network broadcast protocol. During the task delivery process, the server monitors the task delivery status, recording information such as the delivery time and result. If a task delivery failure is detected, it can be retried according to a preset retry mechanism, or the failed task can be logged.

[0116] Example 2: Refer to Figure 2 The difference between this embodiment and Embodiment 1 is that, before counting the number of objects to which tasks are issued, the method further includes:

[0117] S21 constructs a queue. To ensure that the server can monitor the running status of each task-assigned object in real time, this embodiment introduces a heartbeat mechanism. Each task-assigned object will periodically send heartbeat packets to the server according to a preset heartbeat cycle, just like the heartbeat of a living organism, periodically sending signals to indicate its survival status and current situation, so that the server can understand the running status of the task-assigned objects in a timely manner.

[0118] The heartbeat packet includes: the UUID of the task-issuing object, the timestamp, and the running status, which includes online status and offline status.

[0119] UUID stands for Universally Unique Identifier, which is a unique identifier for each task-assigned object. Through UUID, the server can accurately distinguish between different task-assigned objects. Regardless of the number of task-assigned objects, each object's UUID is unique and will not be repeated, thus ensuring accurate identification and management of each object by the server.

[0120] The timestamp in the heartbeat packet records the specific time the heartbeat packet was sent. The server can calculate the time interval since the last heartbeat packet received from the object based on the timestamp. If the time interval exceeds the heartbeat timeout threshold, it can be preliminarily determined that the object to which the task was sent may have encountered an abnormal situation.

[0121] The running status reflects the current working status of the task-assigned object, such as online or offline status.

[0122] When the server receives a heartbeat packet from a task dispatch object, it parses it to extract the UUID, timestamp, and running status information. The server then searches its internal data structure for the task dispatch object record corresponding to that UUID. If a record is found, the server updates the existing status information with the new running status from the heartbeat packet and records the timestamp within the heartbeat packet. If no record is found, it indicates that the task dispatch object may be newly connected, and the server creates a new record for it, storing the relevant information from the heartbeat packet. By employing this approach, the server can maintain the latest running status of each task dispatch object in real time.

[0123] Construct a sequence of task objects, with the task object queue divided into an offline queue and an online queue.

[0124] The online queue stores task assignment objects that are in an online state, indicating that the task assignment object can normally receive and process tasks assigned by the server. The offline queue stores task assignment objects that are in an offline state, indicating that the task cannot be received and processed normally due to object failure, network interruption, or other reasons.

[0125] When the server receives a heartbeat packet from an online task assignment object, it checks whether the task assignment object already exists in the online queue. If it exists, it updates the task assignment object's position in the queue based on the timestamp of the heartbeat packet, and moves it to the corresponding position in the queue according to the order of the timestamps of other task assignment objects in the online queue. If it does not exist, it adds the task assignment object to the end of the online queue and records its UUID, timestamp, and running status.

[0126] For task assignment objects that are offline, when the server detects that they are offline (i.e., it has not received a heartbeat packet from the object after the heartbeat timeout threshold has expired) or receives a heartbeat packet from the task assignment object indicating that it is offline, it will remove them from the online queue and then place them in the offline queue in the order of the heartbeat packet sent (or the time when offline was detected).

[0127] S22 status verification involves the server continuously monitoring the heartbeat packet sending status of each task-delivered object. Each task-delivered object sends a heartbeat packet to the server according to a preset heartbeat cycle, and the server uses this as the basis to confirm the running status of each task-delivered object. However, due to various reasons such as network failures and equipment malfunctions, some task-delivered objects may fail to send a heartbeat packet even after exceeding the heartbeat timeout threshold.

[0128] In this embodiment, the heartbeat timeout threshold is a pre-set time value based on the actual needs of the system and factors such as the network environment. When the server does not receive a heartbeat packet from a task-delivered object within this time frame, it will mark the task-delivered object as an object with questionable status. For example, if the heartbeat period is set to 5 minutes and the heartbeat timeout threshold is set to 10 minutes, then if a task-delivered object does not send a heartbeat packet within 10 minutes, the server will consider the status of the task-delivered object to be questionable and record the task-delivered object with questionable status as an object with questionable status.

[0129] Once the server determines that a task distribution object is in question, it will immediately initiate an active probe on that object.

[0130] Active probing includes sending specific probe packets and initiating network connection requests. For example, the server sends a probe packet containing a specific identifier to an object with questionable state on another network link, requesting the object to return an acknowledgment response upon receipt. In this way, the server can determine whether the heartbeat packet sent by the object with questionable state was lost due to network factors or whether the network link is congested.

[0131] Upon receiving an active probe request from the server, an object with questionable status will respond based on its actual status. If the object is running normally and can receive and process the probe request, it will return a response message in a pre-defined manner, such as an acknowledgment packet containing its own operational status information. If the object experiences a malfunction, network interruption, or other issues and cannot receive or process the probe request normally, it will not return a response message. After sending an active probe request, the server will wait for a certain period of time (the waiting time will always be greater than the heartbeat timeout threshold, typically 3-5 times the heartbeat timeout threshold) to receive a response from the object with questionable status. If a response is received from the object with questionable status within the specified time, the active probe is considered successful; otherwise, the active probe is considered a failure.

[0132] The server updates the running status of objects with questionable status based on the results of the active probe. If the active probe is successful, the server updates the running status of the object with questionable status to online; if the active probe fails, the server updates the running status of the object to offline.

[0133] After the server obtains the updated running status of an object with questionable status, it compares it with the previously recorded running status to determine whether the running status has changed. If the running status has changed, such as from offline to online or from online to offline, the server will deploy the object to the tail of the corresponding task object queue according to the updated status and output the new online queue and the new offline queue.

[0134] If the running status of an object with a questionable status has not changed, that is, it was originally online and is still online after active detection, the server will resend the task to be sent to that task sending object.

[0135] Once the running status of a task-deploying object changes from offline to online, the object will proactively send an `init` command to the server. The `init` command is a signal from the task-deploying object to the server that it has resumed normal operation and is ready to receive tasks. When sending the `init` command, the object will include some of its own information, such as its UUID and current system resource usage.

[0136] After receiving the init command from the task distribution object whose running status has been updated from offline to online, the server will deploy the task distribution object to the tail of the online queue.

[0137] S23 Status Judgment: To ensure accurate and efficient allocation of tasks to each task assignment object, the running status of each task assignment object must first be analyzed and judged. Since there may be multiple task assignment objects, and their running status changes dynamically over time, it is necessary to check the status of each task assignment object individually to determine whether it is online. Specifically:

[0138] Select the i-th task distribution object from the list of task distribution objects as the current judgment object. i is a counter with an initial value of 1, which is used to traverse all task distribution objects in turn.

[0139] The server determines whether the task-issuing object is online by parsing the heartbeat message in the heartbeat packet sent by the i-th task-issuing object.

[0140] If the i-th task assignment object is online, the server records it as an intermediate object. An intermediate object is a task assignment object that is currently considered capable of executing tasks but requires further load assessment. Then, the S24 load judgment is executed to determine whether the task assignment object is suitable to receive new tasks.

[0141] If the i-th task assignment object is not online, it means that the task assignment object cannot execute the task at present. Then, the (i+1)-th task assignment object is updated to the i-th task assignment object, that is, the counter i is incremented by 1, and then the S23 status judgment is re-executed until the server sends the tasks to be assigned to all task assignment objects.

[0142] S24 Load Assessment: Even if the task assignment object is online, its current load status can still affect the task's execution efficiency and success rate. If the task assignment object's load is too high, it may lead to task processing delays, resource contention, and other issues. Therefore, after determining that the task assignment object is online, its load status still needs to be evaluated to decide whether to assign the task to that object.

[0143] Real-time acquisition of intermediate object runtime data, the runtime data including:

[0144] CPU utilization reflects the current CPU resource usage of the intermediate object. The higher the CPU utilization, the heavier the task being processed by the intermediate object and the less computing resources are left.

[0145] Memory utilization rate indicates the current memory resource usage of an intermediate object. Excessive memory utilization rate may cause the intermediate object to run out of memory when processing tasks, affecting the normal operation of the tasks.

[0146] The task failure rate refers to the proportion of intermediate objects that fail to complete their tasks. The higher the task failure rate, the weaker the task processing capability of the intermediate objects and the lower their reliability.

[0147] The load index of the intermediate object is obtained by comprehensively calculating the normalized running data using a weighted average algorithm. If the calculated load index is less than a preset threshold, it means that the load of the intermediate object is within an acceptable range and can normally handle new tasks to be sent. In this case, the intermediate object is updated to the target object. If the load index is greater than or equal to the preset threshold, it means that the current load of the intermediate object is too high and it is not suitable to receive new tasks. In this case, no action is taken.

[0148] S25 updates the object, changing the target object to the task assignment object.

[0149] Subsequently, the number of task distribution objects in the S25 update objects is counted, the initial distribution frequency is calculated based on the number of task distribution objects and the task cycle, and the S26 update frequency is executed.

[0150] The S26 update frequency involves the server establishing a long connection with the task dispatcher or periodically sending heartbeats to obtain the task execution status. Upon receiving a task, the task dispatcher records the task start time and completion time, then sends these times back to the server via heartbeats.

[0151] The actual execution time is calculated based on the task start time and task completion time. That is, the actual execution time is equal to the difference between the task completion time and the task start time. The actual execution time measures the actual time spent by the task on the task delivery object, reflecting the actual processing capacity of the task delivery object and the efficiency of task execution.

[0152] The initial execution time is calculated based on the initial distribution frequency. As shown in Example 1, the initial execution time is 36 seconds. The initial execution time and the actual execution time are compared, and the minimum value is recorded as the first data. A new initial distribution frequency is then calculated based on the first data. The reason for taking the minimum value is that the initial distribution frequency is calculated based on theoretical conditions, while the actual execution time reflects the actual task processing situation. If the actual execution time is longer than the time interval corresponding to the initial distribution frequency, the task to be distributed is distributed according to the time interval corresponding to the initial distribution frequency, so that the task to be distributed can be completed within the task cycle. If the actual execution time is shorter than the time interval corresponding to the initial distribution frequency, it indicates that the task is executing faster, and the distribution frequency can be appropriately increased to improve resource utilization efficiency.

[0153] For example, if the initial execution time is 36 seconds, but the actual execution time of a certain task is 33 seconds, since 33 < 36, the first data is 33 seconds. The new initial distribution frequency corresponds to a distribution interval of 33 seconds, that is, a task is distributed every 0.55 minutes.

[0154] By adopting the above scheme, this embodiment can automatically adapt to changes in the number of task assignment objects and task execution efficiency according to actual conditions. When the number of available task assignment objects increases or the task execution efficiency improves, the assignment frequency will increase accordingly, thereby improving task processing capacity; when the number of task assignment objects decreases or the task execution efficiency decreases, the assignment frequency will decrease accordingly, minimizing task backlog and system overload, which helps improve stability, reliability and resource utilization, enabling tasks to be completed efficiently and in an orderly manner.

[0155] In other embodiments, a long connection is maintained between the server and the task distribution object. When the long connection is broken and cannot be re-established within a certain period of time (such as 5 minutes), it can also be determined that the task distribution object is offline.

[0156] If a task fails to be sent, the server will retry according to the set maximum number of retries (3 times). Each retry is spaced 2 seconds apart. If the task still fails to be sent after multiple retries (more than 3 times), the task will be marked as failed and will send the failure mark back to the server.

[0157] When the task assignment object is offline, the server cannot directly send the task to be assigned to that object. If the number of times the server resends the task to be assigned to the task assignment object exceeds the preset retry threshold, it indicates that the task assignment object may have a serious fault or network problem and cannot resume normal task reception in a short period of time.

[0158] Using Redis queues as a list data structure can implement a first-in, first-out (FIFO) queue function, which ensures that tasks to be sent are processed in chronological order. Tasks that enter the cache queue first are retrieved and attempted to be sent first.

[0159] The server inserts the encapsulated task information into a Redis queue in chronological order of task creation. Redis provides the LPUSH command to insert elements at the head of the list and the RPUSH command to insert elements at the tail. To ensure that tasks are processed in chronological order, this embodiment uses the LPUSH command. This command inserts newly created tasks at the head of the list, while the earliest created task is placed at the tail. Subsequent tasks are retrieved from the tail of the list using the RPOP command, implementing a first-in, first-out (FIFO) processing logic.

[0160] The server periodically checks whether offline task delivery objects or previously failed delivery objects have recovered. When the recovery is detected, the server retrieves the earliest task (i.e. the task at the end of the list) from the Redis queue and attempts to resend it to the object.

[0161] If the task retry succeeds, the server removes the task from the Redis queue and records information such as the task's issuance time and execution status for subsequent task monitoring and statistical analysis. Simultaneously, the server updates the status information of the task object, marking it as online, and resets the retry count for that object. If the task retry still fails, the server can continue to keep the task in the Redis queue and record the retry failure information.

[0162] Example 3: Reference Figure 3 The difference between this embodiment and embodiment 2 is that, before performing the S22 state verification, the method further includes:

[0163] In S31 clustering, the server maintains a historical heartbeat record for each task-issuing object. By periodically obtaining the heartbeats sent by the task-issuing object and parsing them to obtain the timestamps, the timestamps recorded in the historical heartbeats are recorded as historical timestamps.

[0164] For the obtained historical timestamp sequence [t1, t2, t3, ..., t N ] Calculate the time interval Δt between adjacent heartbeats. n The calculation formula is:

[0165] Δt n =t n+1 -t n , where n=1,2,...,N-1.

[0166] Where N is the number of historical heartbeat packets; t n+1 The timestamp of the (n+1)th historical heartbeat packet; t n This is the historical timestamp in the nth historical heartbeat packet.

[0167] In this embodiment, time intervals are used as data points. The DBSCAN algorithm can identify clusters with similar time interval characteristics. These clusters correspond to different working states of the task-issuing object, such as normal and stable operation, network fluctuation, and offline status.

[0168] In this embodiment, the DBSCAN algorithm parameters are set as follows:

[0169] Calculate the percentile (e.g., 90th percentile) of the time interval data, use this percentile as the radius value, and set the minimum number of points to 5-10.

[0170] Using a selected radius and minimum number of points, DBSCAN clustering is performed on all time interval data. The DBSCAN algorithm traverses every point in the dataset and divides the data points into different clusters based on density relationships.

[0171] Count the number of time intervals in each cluster, and denote the cluster with the largest number of time intervals as the target cluster. The target cluster represents the time interval pattern corresponding to the most common working state of the task-issued object.

[0172] S32 Quantity judgment: Determine whether there are multiple clusters where the number of time intervals is greater than a preset quantity threshold. In this embodiment, the preset quantity threshold is 0.1N. In other embodiments, the preset quantity threshold can be set according to requirements.

[0173] If there are multiple clusters where the number of time intervals exceeds a preset threshold, then these clusters with a number of time intervals exceeding the preset threshold are recorded as valid clusters, and the S33 model training steps are executed.

[0174] If there are no multiple clusters where the number of time intervals exceeds a preset threshold, then the largest time interval in the target cluster will be used as the heartbeat timeout threshold.

[0175] The heartbeat timeout threshold is used to determine whether the task-delivered object is offline. If the server does not receive a heartbeat response from the task-delivered object within the time limit specified in subsequent heartbeat checks, the object can be determined to be offline.

[0176] This step determines the heartbeat timeout threshold through cluster analysis based on historical heartbeat packet intervals. This allows for setting different offline judgment methods for different working states of the task-issuing object, i.e., one working state corresponds to one heartbeat timeout threshold.

[0177] S33 model training involves adding labels to the time intervals in each effective cluster and constructing a BI-LSTM model.

[0178] In this embodiment, the time interval sequence can be viewed as a time series data. The BI-LSTM model can learn the patterns and regularities in the time interval sequence, thereby classifying and predicting new time intervals.

[0179] The BI-LSTM model consists of an input layer, a bidirectional LSTM layer, and a fully connected layer.

[0180] The input layer is used to input the normalized time interval. The bidirectional LSTM layer is used to process the forward and backward information of the time series data. In this embodiment, two directional LSTM layers are set, each containing 64 LSTM units. The fully connected layer is used to perform a fully connected transformation on the output of the bidirectional LSTM layer, mapping the high-dimensional features to the low-dimensional label space. The output layer uses the softmax activation function to output the label probability of each effective cluster.

[0181] The labeled time interval data is divided into training and validation sets in a 7:3 ratio. Training parameters such as learning rate, batch size, and number of training epochs are set. In this embodiment, the learning rate is set to 0.001, the batch size is set to 32, and the number of training epochs is set to 50.

[0182] The BI-LSTM model is trained using a training set. During training, the parameters of the BI-LSTM model are updated using the backpropagation algorithm, enabling the BI-LSTM model to minimize the loss function between the predicted and true labels. Simultaneously, the performance of the BI-LSTM model is evaluated using a validation set to prevent overfitting.

[0183] S34 Prediction: Obtain the time interval of the M heartbeat packets sent by the task-issuing object before the current time, and record it as the second data. In this step, M takes a value greater than 2.

[0184] The acquired second data is preprocessed in the same way as the training data, including normalization and other operations.

[0185] All the second data are input into the trained BI-LSTM model in chronological order. The trained BI-LSTM model will classify and predict the input time interval sequence based on the learned time interval sequence patterns and rules, and output a predicted label. This predicted label indicates which effective cluster the input time interval sequence is most likely to belong to. For example, if the trained BI-LSTM model outputs a label of cluster A, it means that the current heartbeat time interval pattern is most similar to the working state represented by cluster A.

[0186] S35 sets a threshold, obtains the maximum time interval in the effective cluster corresponding to the predicted label, records it as the third data, and uses the third data as the new heartbeat timeout threshold.

[0187] After using the third data as the heartbeat timeout threshold, the method further includes:

[0188] Set a dynamic update cycle for the heartbeat timeout threshold. When the update cycle is reached, reacquire the latest M historical heartbeat packet time intervals of the task-issued object, input the latest time interval data into the BI-LSTM model, and output a new predicted label. If the maximum time interval in the effective cluster corresponding to the new predicted label deviates from the current heartbeat timeout threshold by more than the preset deviation threshold, then the maximum time interval in the effective cluster corresponding to the new predicted label is updated to the heartbeat timeout threshold.

[0189] This embodiment updates the heartbeat timeout threshold in real time based on the prediction results of the current heartbeat packet time interval, which can more flexibly adapt to changes in the working status of the task-issuing object and improve the accuracy of offline judgment.

[0190] Example 4: This example discloses a remote task distribution and management system, the system including: a memory and a processor.

[0191] The memory contains a computer-readable storage medium;

[0192] When the processor processes the computer program stored on the computer-readable storage medium, it implements the remote task dispatch management method.

[0193] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A remote task distribution and management method, characterized in that, include: Get the tasks to be issued, the task cycle, and the task objects; count the number of task objects; calculate the initial issuance frequency based on the number of task objects and the task cycle; and formulate the initial issuance strategy based on the tasks to be issued, the task objects, and the initial issuance frequency. Construct a fuzzy control model and set its membership function and rule base; The initial distribution strategy is deployed to the server, and the real-time resource utilization and network bandwidth utilization of the server are obtained. Based on the real-time resource utilization and network bandwidth utilization, the concurrency coefficient is set through a fuzzy control model. The initial distribution frequency in the initial distribution strategy is adjusted in real time according to the concurrency coefficient to obtain the target distribution strategy. The server sends the tasks to be distributed to the task distribution object according to the target distribution strategy. Before counting the number of objects issued by the task, the method further includes: Status judgment: Determine whether the i-th task distribution object is online. If yes, mark the i-th task distribution object as an intermediate object and execute the load judgment step; otherwise, update the (i+1)-th task distribution object to the i-th task distribution object and re-execute the status judgment step. Load assessment: Real-time acquisition of intermediate object's running data, including CPU utilization, memory usage, and task failure rate. Calculation of the load index using a weighted average algorithm and the running data. Determination of whether the load index is less than a preset threshold. If so, the intermediate object is updated to the target object; otherwise, no action is taken. Update Object: Update the target object to the task assignment object; The method further includes: Status verification: The server marks task distribution objects that have not received a heartbeat packet after exceeding the heartbeat timeout threshold as objects with questionable status. The server initiates active probing on objects with questionable status, obtains the active probing results, and updates the running status of objects with questionable status based on the active probing results. Get the updated running status of the object with questionable status, and determine whether the running status of the object with questionable status has changed. If yes, deploy the object with questionable status to the tail of the corresponding task object queue according to the updated status, and output the new online queue and the new offline queue; if no, resend the task to be sent to the task sending object. Prior to performing the state verification step, the method further includes: Obtain the timestamps from the N historical heartbeat packets of each task-issued object and record them as historical timestamps. Calculate the time interval between adjacent historical heartbeat packets according to the historical timestamps. Use the DBSCAN algorithm to cluster all time intervals to obtain multiple clusters. Count the number of time intervals in each cluster. Record the cluster with the largest number of time intervals as the target cluster. Record the largest time interval in the target cluster as the heartbeat timeout threshold. When the task assignment object is offline or the number of times the task to be assigned is resent to the task assignment object exceeds the preset retry threshold, the server starts the task caching mechanism and stores the tasks to be assigned in the order of time to the Redis queue.

2. The remote task distribution and management method according to claim 1, characterized in that, After calculating the initial distribution frequency based on the number of task recipients and the task cycle, the method further includes: Monitor the task execution status of the task-issuing object, obtain the task start time and task completion time, calculate the actual execution time based on the task start time and task completion time, calculate the initial execution time based on the initial issuance frequency, record the minimum value between the initial execution time and the actual execution time as the first data, and calculate the new initial issuance frequency based on the first data.

3. The remote task distribution and management method according to claim 1, characterized in that, Before performing the status determination step, the method further includes: Each task-assigned object sends a heartbeat packet to the server according to a preset heartbeat period. The server updates the running status of the task-assigned object based on the heartbeat message in the heartbeat packet. The heartbeat packet includes the UUID, timestamp, and running status of the task-assigned object. The running status includes online status and offline status. A task object queue is constructed, which includes an offline queue and an online queue. Task objects in the offline state are placed in the offline queue according to the heartbeat packet sending time, and task objects in the online state are placed in the online queue according to the heartbeat packet sending time.

4. The remote task distribution and management method according to claim 1, characterized in that, The method further includes: the task distribution object that has been updated from offline to online status automatically sends an init command to the server, and the server deploys the task distribution object that has been updated from offline to online status to the tail of the online queue.

5. The remote task distribution and management method according to claim 1, characterized in that, Before using the largest time interval in the target cluster as the heartbeat timeout threshold, the method further includes: Determine if there are multiple clusters where the number of time intervals exceeds a preset threshold. If so, the clusters with the number of time intervals exceeding the preset threshold are recorded as valid clusters. If not, the largest time interval in the target cluster is used as the heartbeat timeout threshold. Label the time intervals in each valid cluster, construct a BI-LSTM model, and train the BI-LSTM model using the labeled time intervals to obtain the trained BI-LSTM model. Get the time intervals of the M heartbeat packets sent by the task recipient before the current time, and denote them as the second data. Input all the second data into the trained BI-LSTM model in chronological order, and output the predicted labels. The maximum time interval in the effective cluster corresponding to the predicted label is recorded as the third data, and the third data is used as the heartbeat timeout threshold.

6. A remote task distribution and management system, characterized in that, include: Memory and processor The memory contains a computer-readable storage medium; When the processor processes a computer program stored on the computer-readable storage medium, it implements the method as described in any one of claims 1-5.

Images