Remote task issuing management method and system

Abstract

The invention provides a remote task issuing management method and system, and relates to the technical field of task issuing management, and the method comprises the steps: firstly obtaining a to-be-issued task, a task period and task issuing objects, carrying out the statistics of the number of the task issuing objects, calculating the initial issuing frequency, and formulating an initial issuing strategy; constructing a fuzzy control model and setting a membership function and a rule base; and deploying the initial strategy to a server, obtaining real-time resource and bandwidth occupancy rate, setting a concurrency coefficient through a fuzzy control model, adjusting the initial issuing frequency in real time to obtain a target issuing strategy, and sending a task by the server according to the strategy. According to the method and the device, the issuing frequency and the concurrency coefficient of the task can be dynamically adjusted according to the real-time resource occupancy rate and the network bandwidth occupancy rate of the server, so that the risk of server overload or network congestion is reduced, and the task is efficiently executed according to a predetermined plan.

Description

Technical Field

[0001] The present application relates to the technical field of task dispatch management, and in particular to a remote task dispatch management method and system. Background Art

[0002] In today's digital and information-based era, various business systems and applications are widely distributed across various locations and devices. Many businesses and organizations require unified task management and scheduling for these dispersed systems and devices to achieve efficient business operations. Remote task dispatch management has emerged as a key enabler. It allows administrators to centrally send task instructions to multiple remote task dispatch targets (such as distributed servers and mobile devices), ensuring that tasks are executed according to pre-defined plans and requirements.

[0003] Currently, existing remote task delivery management technologies primarily utilize a fixed-frequency delivery strategy. Specifically, after determining the tasks to be delivered, the task cycle, and the target, the system sets a fixed delivery frequency for each task based on pre-set rules. However, in situations where server resources are limited or network bandwidth is constrained, this fixed-frequency delivery can lead to server overload and even system crashes. This can also cause network congestion, impacting the normal operation of other services. Summary of the Invention

[0004] In order to dynamically adjust the frequency of task issuance to reduce the risk of server overload or network congestion and enable tasks to be executed efficiently according to the predetermined plan, the present application provides a remote task issuance management method and system.

[0005] In the first aspect, this application provides a remote task dispatch management method, which adopts the following technical solutions: A remote task distribution management method includes the following steps: Obtain tasks to be issued, task cycles, and task issuing targets, count the number of task issuing targets, calculate the initial issuing frequency based on the number of task issuing targets and task cycles, and formulate the initial issuing strategy based on the tasks to be issued, task issuing targets, and initial issuing frequency; Construct a fuzzy control model and set the membership function and rule base of the fuzzy control model; The initial delivery strategy is deployed to the server, and the real-time resource occupancy rate and network bandwidth occupancy rate of the server are obtained. The concurrency coefficient is set through the fuzzy control model based on the real-time resource occupancy rate and network bandwidth occupancy rate. The initial delivery frequency in the initial delivery strategy is adjusted in real time according to the concurrency coefficient to obtain the target delivery strategy. The server sends the tasks to be delivered to the task delivery object according to the target delivery strategy.

[0006] This application calculates the initial dispatch frequency based on the number of task dispatch objects and the task cycle, and formulates an initial dispatch strategy based on the tasks to be dispatched, the task dispatch objects, and the initial dispatch frequency. This improves the rationality and predictability of task distribution based on objective data, and reduces the risk of resource waste and task backlog. Subsequently, this application uses fuzzy logic to set the concurrency coefficient based on the server's resource occupancy (CPU, memory, etc.) and network bandwidth occupancy, adjusts the initial dispatch strategy based on the concurrency coefficient, and obtains the target dispatch strategy. This utilizes the server's real-time resource occupancy and network bandwidth occupancy to dynamically adjust the task dispatch frequency, so that task distribution matches the current resource status and improves resource utilization. Finally, the server executes task dispatch according to the target strategy, and balances the task dispatch speed and resource consumption through fuzzy control. This application can reduce the risk of server overload or network congestion and improve the efficiency of task execution.

[0007] Optionally, before counting the number of task delivery objects, the method further includes: Status judgment: Determine whether the i-th task delivery object is online. If so, record the i-th task delivery object as an intermediate object and execute the load judgment step; if not, update the i+1-th task delivery object to the i-th task delivery object and execute the status judgment step again; Load judgment: Real-time acquisition of the intermediate object's operating data, including CPU occupancy, memory usage, and task failure rate. A load index is calculated using a weighted average algorithm and the operating data. The load index is then determined to be 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 delivery object.

[0008] By adopting the above solution, the present application can dispatch tasks to task dispatching objects that are online and have a low load index, reducing the risk of task failure or repeated retries due to the object being offline, and improving the reliability of task distribution.

[0009] Optionally, after calculating the initial delivery frequency according to the number of task delivery objects and the task period, the method further includes: Monitor the task execution status of the task issuing object, obtain the task download start time and the task download completion time, calculate the actual execution time based on the task download start time and the task download completion time, calculate the initial execution time based on the initial issuing frequency, record the minimum value between the initial execution time and the actual execution time as the first data, and calculate the new initial issuing frequency based on the first data.

[0010] This application calculates the initial sending frequency based on the number of task sending objects and the task cycle, and uses the initial sending frequency as the theoretical maximum sending capacity benchmark. Subsequently, this application records the start download time and download completion time of each task, and calculates the actual execution time based on this to quantify the actual processing time of the task on the task sending object side, reflecting the actual load capacity of the task sending object. Finally, this application calculates the initial execution time based on the initial sending frequency, uses the minimum value of the initial execution time and the actual execution time as the first data, and calculates the new initial sending frequency based on the first data. Through the above scheme, this application can dynamically adjust the frequency according to the actual execution time, automatically adapt to the performance fluctuations of the task sending object, and reduce task backlogs or timeouts.

[0011] Optionally, before executing the state determination step, the method further includes: Each task-issuing object sends a heartbeat packet to the server according to a preset heartbeat cycle. The server updates the running status of the task-issuing object based on the heartbeat message in the heartbeat packet. The heartbeat packet includes the UUID, timestamp and running status of the task-issuing object. The running status includes online status and offline status; Construct a task object queue, which includes an offline queue and an online queue. Task objects in an offline state are placed in the offline queue in the order of heartbeat packet sending time, and task objects in an online state are placed in the online queue in the order of heartbeat packet sending time.

[0012] This application uses a heartbeat mechanism to monitor the status of the task issuance object in real time, which can reduce the status update delay. This application also combines a dynamic queue management solution to improve the reliability, efficiency and maintainability of the task issuance process.

[0013] Optionally, the method further includes: Status verification: The server marks the task delivery object that has not received a heartbeat packet after the heartbeat timeout threshold has expired as an object with questionable status. The server initiates an active probe on the object with questionable status, obtains the active probe results, and updates the running status of the object with questionable status based on the active probe results. Get the updated running status of the object in questionable state, and determine whether the running status of the object in questionable state has changed. If so, deploy the object in questionable state to the end of the corresponding task object queue according to the updated status, and output the new online queue and the new offline queue; if not, resend the pending task to the task sending object.

[0014] The server marks the task-issuing object that has not sent a heartbeat packet within the heartbeat timeout threshold as an object with questionable status, which can reduce misjudgments caused by network outages or object processing delays. Afterwards, the server initiates active detection to the object with questionable status and obtains the active detection results. If the object with questionable status is still alive (that is, the object with questionable status is online), it is considered that the timeout was caused by heartbeat packet loss or processing delay. Otherwise, it is considered that the object with questionable status is truly offline or faulty. The running status of the object is then corrected based on the detection results, and the object with questionable status is then put back to the end of the corresponding queue according to the updated status to reduce the risk of unstable task allocation caused by frequent adjustments to the head of the queue. By adopting the above solution, a brief loss of heartbeats will not cause the object with questionable status to be mistakenly kicked out of the online queue. The active detection mechanism can quickly restore its status and improve fault tolerance.

[0015] Optionally, the method further includes: the task delivery object updated from offline state to online state automatically sends an init instruction to the server, and the server deploys the task delivery object updated from offline state to online state to the end of the online queue.

[0016] By adopting the above technical solution, this application uses the init instruction to force the synchronization of the status of the task sending object, so that the status of the server and the task sending object are synchronized. Figure 1 Because the server consumes a lot of resources by regularly detecting all offline task dispatchers, the task dispatchers proactively report status changes, so the server only needs to process a small number of init commands, thereby reducing network load and computing overhead. Subsequently, this application redeploys them to the end of the online queue, allowing them to quickly rejoin the task dispatch process after restarting or network recovery, reducing service interruption time.

[0017] Optionally, before performing the status verification step, the method further includes: Obtain the timestamps of N historical heartbeat packets of each task delivery object and record them as historical timestamps. Calculate the time intervals 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, and record the largest time interval in the target cluster as the heartbeat timeout threshold.

[0018] This application uses cluster analysis of historical heartbeat data to identify the central trend of normal heartbeat intervals, and then automatically identifies the normal fluctuation range under the current network and task dispatch object load, making the heartbeat timeout threshold more suitable for actual scenarios. Afterwards, 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 heartbeat interval of the task dispatch object under normal conditions. This threshold can balance sensitivity and fault tolerance.

[0019] Optionally, before using the maximum time interval in the target cluster as the heartbeat timeout threshold, the method further includes: Determine whether there are multiple clusters whose number of time intervals is greater than a preset number threshold. If so, record the cluster whose number of time intervals is greater than the preset number threshold as a valid cluster; if not, use the largest time interval in the target cluster as the heartbeat timeout threshold; Label the time intervals in each valid cluster, build a BI-LSTM model, and train the BI-LSTM model using the labeled time intervals to obtain a trained BI-LSTM model. Obtain the time intervals of the M heartbeat packets sent by the task issuing object before the current time, record them as the second data, input all the second data into the trained BI-LSTM model in chronological order, and output the predicted label; The maximum time interval in the valid cluster corresponding to the predicted label is obtained, recorded as the third data, and the third data is used as the heartbeat timeout threshold.

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

[0021] Optionally, when the task dispatching object is offline or the number of times the task to be dispatched is resent to the task dispatching object exceeds a preset retry threshold, the server starts the task caching mechanism and stores the tasks to be dispatched in a Redis queue in chronological order.

[0022] When the task dispatch object cannot be delivered directly due to being offline or the number of retries exceeding the limit, the server directly discards the offline or retried failed task, which may cause key operations (such as device configuration updates and data synchronization) to not be executed, causing business anomalies. Therefore, this application starts the task caching mechanism in the above situation, and stores the tasks to be dispatched in the Redis queue in chronological order. After the task dispatch object is restored online or the fault is repaired, the server can take the task out of the cache queue and re-distribute it without manual intervention or external triggering, thus achieving self-healing fault tolerance. When the task dispatch object is offline or has a persistent fault, continuous retries will waste network bandwidth, server CPU and thread resources. The caching mechanism delays the retry until the object is available, reducing resource consumption.

[0023] Secondly, this application provides a remote task dispatching management system, which adopts the following technical solutions: A remote task distribution management system, comprising: a memory and a processor, The memory stores a computer-readable storage medium; When the processor processes the computer program stored on the computer-readable storage medium, the method described in the first aspect is implemented.

[0024] In summary, this application includes at least one of the following beneficial technical effects: 1. This application calculates the initial dispatch frequency based on the number of task dispatch objects and the task cycle, and formulates an initial dispatch strategy based on the tasks to be dispatched, the task dispatch objects, and the initial dispatch frequency. This improves the rationality and predictability of task distribution based on objective data, and reduces the risk of resource waste and task backlogs. Subsequently, this application uses fuzzy logic to set the concurrency coefficient based on the server's resource utilization (CPU, memory, etc.) and network bandwidth utilization. The initial dispatch strategy is adjusted according to the concurrency coefficient to obtain the target dispatch strategy, thereby utilizing the server's real-time resource utilization and network bandwidth utilization to dynamically adjust the task dispatch frequency, aligning task distribution with the current resource status and improving resource utilization. Finally, the server executes task dispatch according to the target strategy, balancing task dispatch speed and resource consumption through fuzzy control. This application can reduce the risk of server overload or network congestion and improve the efficiency of task execution.

[0025] 2. This application can dispatch tasks to task dispatching objects that are online and have a low load index, reducing the risk of task failure or repeated retries due to the object being offline, and improving the reliability of task distribution. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is a flow chart of Example 1 of the present application; Figure 2 This is a flow chart of Example 2 of the present application; Figure 3 This is a flowchart of Example 3 of the present application. DETAILED DESCRIPTION

[0027] The following combination Figures 1 to 3 This application is described in further detail.

[0028] Example 1: This example discloses a remote task distribution management method, referring to Figure 1The method includes: S11 data collection, S12 modeling, and S13 task delivery. First, the tasks to be delivered, the period, and the task delivery objects are obtained and the number of task delivery objects is counted. Based on this, the initial delivery frequency is calculated and the initial delivery strategy is formulated. Then, a fuzzy control model is constructed and the membership function and rule base are set. Then, the initial strategy is deployed to the server, and its real-time resource and bandwidth occupancy rate is obtained. The concurrency coefficient is set through the fuzzy control model, and the initial delivery frequency is adjusted in real time to obtain the target delivery strategy. Finally, the server sends the task according to this strategy. The execution of each step of this embodiment is as follows: S11 data collection, obtains tasks to be issued, task cycles and task issuing objects.

[0029] The tasks to be delivered are files used to install or upgrade applications on different platforms. These include installation packages and free installation packages. Installation packages are special compressed packages suitable for different platforms that require a single click to install or upgrade, such as DEB files, RPM files, and EXE files. Free installation packages are collections of binary files that can be run directly after decompression.

[0030] In this embodiment, multiple tasks to be delivered for the same application will not be delivered, and the conditions for determining the uniqueness of the upgrade package are: category + version number + CPU architecture + applicable device type.

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

[0032] The task delivery object refers to the terminal that needs to receive and execute the task, that is, the client corresponding to the task to be delivered.

[0033] The server maintains a list of task-dispatching objects, which is used to update the status of each task-dispatching object in real time, including online availability and load conditions. The server can count the number of task-dispatching objects by traversing the list or using database statistical functions (such as the COUNT function). For example, if the database stores a list of task-dispatching objects, including fields such as the UUID of the task-dispatching object, the number of task-dispatching objects can be obtained by executing the SQL statement "SELECT COUNT(device_id) FROM device_table".

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

[0035] For example, if the task cycle is 3600 seconds and the number of task delivery objects is 10, then the initial delivery frequency = 1 / (3600 / 10) ≈ 0.0278 times / second, that is, the server delivers a task approximately every 36 seconds.

[0036] The initial delivery strategy specifies how to assign tasks to each task delivery target, including the time sequence and delivery method. For example, for a sequential delivery strategy, tasks can be sent sequentially based on a certain sorting rule of the task delivery targets (such as ascending or descending device ID); for a broadcast delivery strategy, tasks can be sent to all task delivery targets in parallel.

[0037] S12 modeling constructs a fuzzy control model. A fuzzy control model is a control system based on fuzzy logic that can handle uncertainty and ambiguity. The fuzzy control model consists of a fuzzification module, a fuzzy inference module, and a defuzzification module. The fuzzification module converts precise input values ​​into fuzzy sets; the fuzzy inference module infers the fuzzy sets based on the rules in the fuzzy rule base, producing fuzzy outputs; and the defuzzification module converts the fuzzy outputs into concurrency coefficients.

[0038] There's a dynamic coupling between server-side resource utilization (CPU / memory) and network bandwidth utilization, and their impact on the concurrency coefficient exhibits nonlinear characteristics (for example, when resources are saturated, bandwidth changes can have a sudden impact on the system), making it difficult to describe with precise numerical values. The fuzzy control model maps this fuzzy input information into the concurrency coefficient by establishing a fuzzy rule base and membership functions, thereby adjusting the initial delivery frequency.

[0039] First, the parameters of the membership function are determined according to the actual range of the server's real-time resource utilization and network bandwidth utilization and business requirements.

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

[0041] In this embodiment, the range of real-time resource utilization or network bandwidth utilization is 0%-100%, and the three fuzzy sets of low, medium, and high are as follows: The vertex coordinates of the low fuzzy set are (0,0), (30,1), and (30,0), indicating that the real-time resource utilization or network bandwidth utilization between 0% and 30% belongs to the low fuzzy set. The membership function calculation model is as follows: ; represents the degree of membership; x is the resource occupancy rate.

[0042] 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 between 20% and 70% belongs to the medium fuzzy set. The membership function calculation model is as follows: ; The vertex coordinates of the high fuzzy set are (60, 0), (100, 1), and (100, 0), indicating that the real-time resource utilization rate or network bandwidth utilization rate between 60% and 100% belongs to the high fuzzy set. The membership function calculation model is as follows: .

[0043] In other embodiments, the membership function may also adopt a trapezoidal membership function and a Gaussian membership function.

[0044] The rules in the rule base are developed 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).

[0045] In this embodiment, the rule base for setting the fuzzy control model includes the following rules: Rule 1: If the real-time resource utilization is low and the network bandwidth utilization is low, the concurrency coefficient is high; Rule 2: If the real-time resource utilization is low and the network bandwidth utilization is medium, the concurrency coefficient is medium; Rule 3: If the real-time resource utilization is low and the network bandwidth utilization is high, the concurrency coefficient is low; Rule 4: If the real-time resource utilization is medium and the network bandwidth utilization is low, the concurrency coefficient is medium; Rule 5: If the real-time resource utilization rate is medium and the network bandwidth utilization rate is medium, the concurrency coefficient is medium; Rule 6: If the real-time resource utilization is medium and the network bandwidth utilization is high, the concurrency coefficient is low; Rule 7: If the real-time resource utilization is high and the network bandwidth utilization is low, the concurrency coefficient is low; Rule 8: If the real-time resource utilization is high and the network bandwidth utilization is medium, the concurrency coefficient is low; Rule 9: If the real-time resource utilization rate is high and the network bandwidth utilization rate is high, the concurrency coefficient is low; The rule base adopts Mamdani reasoning method to perform fuzzy reasoning, the activation strength of each rule takes the minimum value of membership, and the reasoning result is defuzzified by the center of gravity method to obtain the specific value of the concurrency coefficient.

[0046] S13 issues tasks and deploys the formulated initial issuance strategy to the server in the form of configuration files or program codes. The configuration files are in XML, JSON and other formats for easy reading and modification; the program code can be integrated into the task scheduling module on the server to realize automated task issuance.

[0047] The real-time resource usage of the server includes CPU usage, memory usage, etc. You can obtain the real-time resource usage of the server through the interface provided by the operating system or third-party monitoring tools.

[0048] Network bandwidth usage can be obtained through network monitoring tools such as iftop and nload.

[0049] The acquired real-time resource utilization and network bandwidth utilization are fuzzified and converted into fuzzy sets that can be recognized by the fuzzy control model. The fuzzified input variables are then fed into the fuzzy control model's rule base for inference. Based on the membership of the input variables and the rules in the rule base, the fuzzy value of the concurrency coefficient is calculated. The fuzzy value of the concurrency coefficient obtained by fuzzy inference is defuzzified and converted into a precise value.

[0050] For example, if the real-time resource utilization rate of the server is 65% and the network bandwidth utilization rate is 25%, then according to the calculation formula of the above membership function, the real-time resource utilization rate of 65% corresponds to a high membership of 0.125 and a medium membership of 0.25. Similarly, the network bandwidth utilization rate of 25% corresponds to a medium membership of approximately 0.17 and a low membership of approximately 0.83.

[0051] According to the logic of fuzzy reasoning, the membership of the input variables is combined and matched. The matching rules in this embodiment are: Rule 4: If the real-time resource utilization is medium and the network bandwidth utilization is low, the concurrency coefficient is medium and the activation intensity is 0.25; Rule 5: If the real-time resource utilization is medium and the network bandwidth utilization is medium, the concurrency coefficient is medium and the activation intensity is 0.17; Rule 7: If the real-time resource utilization is high and the network bandwidth utilization is low, the concurrency coefficient is low and the activation intensity is 0.125; Rule 8: If the real-time resource utilization is high and the network bandwidth utilization is medium, the concurrency coefficient is low and the activation intensity is 0.125; According to the activation rules, the Mamdani inference method is used to trim the output fuzzy set: Rule 4: The membership from x=40% to x=70% is limited to 0.25.

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

[0053] Rule 7 / Rule 8: The membership limit from x=0% to x=60% is 0.125.

[0054] The membership limits from x=80% to x=100% are 0 because there is no corresponding rule.

[0055] Merge all the clipped output fuzzy sets and calculate the center of gravity. The calculation model is as follows: ; After discretization, the calculation model is as follows: ; The membership values ​​of the discretized concurrency coefficients are shown in Table 1.

[0056] Table 1 Schematic table of membership values ​​of discretized concurrency coefficients Concurrency coefficient Membership 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 The value of the concurrency coefficient is calculated as: 0.125×(0+10+20+30)+0.25×(40+50+60+70)=62.5; 0.125×4+0.25×4=1.5; 62.5÷1.5≈0.4167; The concurrency coefficient is used to adjust the initial delivery frequency. The calculation formula is: Adjusted initial delivery frequency = initial delivery frequency × concurrency coefficient.

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

[0058] Based on the delivery method specified in the target delivery policy, the server sends pending tasks to the task delivery recipients. If unicast is used, the server establishes a connection with each task delivery recipient and sends the task. If broadcast is used, the server sends the task to all task delivery recipients via the network broadcast protocol. During the task delivery process, the server monitors the task delivery status, recording information such as the task delivery time and delivery results. If a task delivery fails, it can retry according to the pre-defined retry mechanism or log the failed task.

[0059] Example 2: Reference Figure 2The difference between this embodiment and embodiment 1 is that, before counting the number of task delivery objects, the method further includes: S21 builds a queue. To ensure that the server can grasp the running status of each task-issuing object in real time, this embodiment introduces a heartbeat mechanism. Each task-issuing object will periodically send heartbeat packets to the server according to a preset heartbeat period. Just like the heartbeat of a living organism, it regularly sends signals to indicate its own survival status and current situation, allowing the server to promptly understand the running status of the task-issuing object.

[0060] The heartbeat packet includes: the UUID of the task delivery object, a timestamp, and the running status, where the running status includes an online state and an offline state.

[0061] A UUID is a universally unique identifier for each task delivery object. This unique identifier allows the server to accurately distinguish between different task delivery objects. Regardless of the number of task delivery objects, each object's UUID is unique and unique, ensuring accurate identification and management of each object on the server.

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

[0063] The running status reflects the current working status of the task delivery object, such as online status or offline status.

[0064] When the server receives the heartbeat packet sent by the task dispatch object, it parses it and extracts the UUID, timestamp, and running status information. The server then searches for the task dispatch object record corresponding to the UUID in its internal data structure. If the record is found, the original status information is updated with the new running status in the heartbeat packet, and the timestamp in the heartbeat packet is recorded. If no record is found, it means that the task dispatch object may be newly connected. The server will create a new record for it and store the relevant information in the heartbeat packet. By adopting the above solution, the server can maintain the latest running status of each task dispatch object in real time.

[0065] Build a task object sequence. The task object queue is divided into offline queue and online queue.

[0066] The online queue is used to store task dispatch objects that are in an online state. The online state indicates that the task dispatch object can normally receive and process tasks issued by the server. The offline queue is used to store task dispatch objects that are in an offline state. The offline state indicates that the task dispatch object cannot normally receive and process tasks due to reasons such as object failure and network interruption.

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

[0068] For a task dispatch object in an offline state, when the server detects that it is offline (that is, 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 dispatch object indicating an offline state, it will remove it from the online queue and then place it in the offline queue in the order of the time when the heartbeat packet was sent (or the time when the offline state was detected).

[0069] S22 Status Verification: The server continuously monitors the heartbeat packet transmission status of each task dispatcher. Each task dispatcher sends heartbeat packets to the server according to the preset heartbeat period, and the server uses this as a basis to confirm the operation status of each task dispatcher. However, due to various reasons such as network failures and device anomalies, some task dispatchers may not send heartbeat packets even after the heartbeat timeout threshold has expired.

[0070] In this embodiment, the heartbeat timeout threshold is a pre-set time value based on factors such as the actual needs of the system and the network environment. When the server does not receive a heartbeat packet from a task dispatch object within a time range exceeding this threshold, the task dispatch object will be marked as an object with a 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 dispatch object does not send a heartbeat packet within 10 minutes, the server will consider the task dispatch object's status to be questionable and record the task dispatch object with a questionable status as an object with a questionable status.

[0071] Once the server determines that a task is assigned to an object with a questionable status, it will immediately initiate an active detection of the object with a questionable status.

[0072] Active probing involves sending specific probe packets and initiating network connection requests. For example, a server sends a probe packet containing a specific identifier to an object in question over another network link, requesting the object to return a confirmation response upon receipt. This allows the server to determine whether network factors have caused the loss of the heartbeat packet sent by the object in question or whether the network link is congested.

[0073] After receiving an active probe request from the server, an object with questionable status will respond based on its actual status. If the object is operating normally and can receive and process the probe request, it will return a response in the agreed-upon manner, such as a confirmation packet containing its operating status. If the object with questionable status experiences a malfunction, network outage, or other issues, preventing it from receiving or processing the probe request, it will not return a response. After sending an active probe request, the server will wait for a certain period of time (the waiting period must 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; if no response is received from the object with questionable status, the active probe is considered a failure.

[0074] The server updates the status of the object in question based on the results of the active probe. If the active probe is successful, the server updates the object's status to online. If the active probe fails, the server updates the object's status to offline.

[0075] After the server obtains the updated running status of the object in question, it will compare it with the last recorded running status to determine whether its running status has changed. If the running status has changed, for example, from offline to online, or from online to offline, the server will deploy the object to the end of the corresponding task object queue according to the updated status, and output a new online queue and a new offline queue.

[0076] If the running status of the object in question has not changed, that is, it was originally online and is still online after active detection, the server will resend the pending task to the task sending object.

[0077] When the task-issuing object's running status changes from offline to online, it proactively sends an init command to the server. This init command signals to the server that the task-issuing object has resumed normal operation and is ready to accept tasks. When the object sends the init command, it includes some relevant information about itself, such as its UUID and current system resource usage.

[0078] After receiving the init command sent by the task delivery object to update the running status from offline to online, the server will deploy the task delivery object to the end of the online queue.

[0079] S23 Status Judgment: To ensure that the tasks to be issued can be accurately and efficiently assigned to each task issuing object, the running status of each task issuing object must first be analyzed and judged. Since there may be multiple task issuing objects, and their running status will change dynamically over time, it is necessary to check the status of each task issuing object one by one to determine whether it is online. Specifically: The i-th task delivery object is selected from the task delivery object list as the current judgment object, where i is a counter with an initial value of 1, and is used to traverse all task delivery objects in sequence.

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

[0081] If the i-th task dispatch object is online, the server records the task dispatch object as an intermediate object. An intermediate object is a task dispatch object that is currently considered capable of executing tasks but requires further load evaluation. Then, load evaluation S24 is performed to determine whether the task dispatch object is suitable for receiving new tasks.

[0082] If the i-th task dispatching object is not in an online state, it means that the task dispatching object cannot currently execute the task. Then the i+1-th task dispatching object is updated to the i-th task dispatching object, that is, the counter i is increased by 1, and then the S23 status judgment is re-executed until the server sends the pending tasks to all task dispatching objects.

[0083] S24 Load Assessment: Even if the task assignee is online, its current load may affect the task's execution efficiency and success rate. If the task assignee's load is too high, it may lead to task processing delays, resource contention, and other issues. Therefore, after confirming that the task assignee is online, its load needs to be assessed to determine whether to assign the task to it.

[0084] Obtaining real-time operational data of intermediate objects, including: The CPU usage reflects the current CPU resource usage of the intermediate object. The higher the CPU usage, the heavier the task being processed by the intermediate object and the fewer remaining computing resources.

[0085] Memory usage indicates the current memory usage of the intermediate object. Excessive memory usage may cause the intermediate object to run out of memory when processing tasks, affecting the normal operation of the task.

[0086] The task failure rate refers to the proportion of uncompleted tasks of intermediate objects. The higher the task failure rate, the weaker the task processing capability of the intermediate objects and the lower the reliability.

[0087] The normalized operational data is comprehensively calculated using a weighted average algorithm to determine the intermediate object's load index. If the calculated load index is less than the preset index threshold, the intermediate object's load is within an acceptable range and can normally process new pending tasks. The intermediate object is then updated to the target object. If the load index is greater than or equal to the preset index threshold, the intermediate object's current load is too high and unsuitable for receiving new tasks. No action is taken in this case.

[0088] S25 updates the object, updating the target object to the task delivery object.

[0089] Subsequently, the number of task delivery objects in the update object is counted in S25, the initial delivery frequency is calculated according to the number of task delivery objects and the task period, and the frequency is updated in S26.

[0090] S26 Update Frequency: The server establishes a persistent connection with the task dispatcher or periodically sends heartbeat packets to obtain the task dispatcher's task execution status. Upon receiving a task, the task dispatcher records the task download start time and the task download completion time. The task download start and completion times are then fed back to the server via heartbeat packets.

[0091] The actual execution time is calculated based on the task download start time and task download completion time. That is, the actual execution time is equal to the difference between the task download completion time and the task download start time. The actual execution time measures the actual time spent on the task delivery object. It reflects the actual processing capability of the task delivery object and the efficiency of task execution.

[0092] The initial execution time is calculated based on the initial sending 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 taken as the first data. The new initial sending frequency is calculated based on the first data. The reason for taking the minimum value is that the initial sending 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 sending frequency, the task to be sent will be sent based on the time interval corresponding to the initial sending frequency, so that the task to be sent can be sent within the task cycle; if the actual execution time is shorter than the time interval corresponding to the initial sending frequency, it means that the task is executed faster, and the sending frequency can be appropriately increased to improve resource utilization efficiency.

[0093] For example, the initial execution time is 36 seconds, and the actual execution time of a task is 33 seconds. Since 33<36, the first data is 33 seconds, and the delivery interval corresponding to the new initial delivery frequency is 33 seconds, that is, a task is delivered every 0.55 minutes.

[0094] By adopting the above solution, this embodiment can automatically adapt to changes in the number of task delivery targets and task execution efficiency based on actual conditions. When the number of available task delivery targets increases or task execution efficiency improves, the delivery frequency will increase accordingly, thereby improving task processing capabilities. When the number of task delivery targets decreases or task execution efficiency decreases, the delivery frequency will decrease accordingly, minimizing task backlogs and system overloads, helping to improve stability, reliability, and resource utilization, and enabling tasks to be completed efficiently and orderly.

[0095] In other embodiments, a long connection is maintained between the server and the task issuing object. When the long connection is disconnected and cannot be re-established within a certain period of time (such as 5 minutes), the task issuing object may also be determined to be offline.

[0096] If a pending task fails to be delivered, the server will retry according to the set maximum number of retries (3 times). Each retry interval is 2 seconds. If delivery fails after multiple retries (more than 3 times), the task delivery object will be marked as delivery failure and the task delivery object will return the delivery failure mark to the server.

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

[0098] The list data structure of the Redis queue can be used to implement the first-in-first-out (FIFO) queue function, which can ensure that the tasks to be issued are processed in chronological order. The tasks to be issued that enter the cache queue first are taken out and attempted to be issued first.

[0099] The server inserts the encapsulated task information into the Redis queue in chronological order. Redis provides the LPUSH command to insert elements at the head of a list, and the RPUSH command to insert elements at the tail of a list. To ensure that tasks are processed in chronological order, this embodiment uses the LPUSH command, which inserts newly generated tasks at the head of the list and the oldest tasks at the tail. Subsequent tasks are retrieved using the RPOP command, implementing first-in, first-out processing.

[0100] The server will periodically check whether the offline task delivery object or the object that failed to be sent before has returned to normal. When it detects that the object has returned to normal, the server will take out the earliest task from the Redis queue (that is, the task at the end of the list) and try to resend it to the object.

[0101] If the task retry succeeds, the server removes the task from the Redis queue and records information such as the task's dispatch time and execution status for subsequent task monitoring and statistical analysis. At the same time, the server updates the status of the task's dispatched object, marking it as online, and resets the task's retry count. If the task retry still fails, the server can retain the task in the Redis queue and record the retry failure.

[0102] Example 3: Reference Figure 3 The difference between this embodiment and embodiment 2 is that, before performing S22 status verification, the method further includes: S31 clustering, the server maintains a historical heartbeat packet record for each task issuing object. It periodically obtains the heartbeat packet sent by the task issuing object, parses it to obtain the timestamp, and records the timestamp recorded in the historical heartbeat packet as the historical timestamp.

[0103] For the acquired historical timestamp sequence [t1, t2, t3, ..., t N ], calculate the time interval Δt between adjacent heartbeat packets n , the calculation formula is: Δt n =t n+1 -t n , where n=1,2,...,N-1.

[0104] Where N is the number of historical heartbeat packets; tn+1 is the historical timestamp in the n+1th historical heartbeat packet; t n The historical timestamp in the nth historical heartbeat packet.

[0105] In this embodiment, time intervals are used as data points, and clusters with similar time interval characteristics can be identified through the DBSCAN algorithm. These clusters correspond to different working states of the task delivery objects, such as normal and stable operation state, network fluctuation state, offline state, etc.

[0106] In this embodiment, the DBSCAN algorithm parameters are set as follows: Calculate the percentile of the time interval data (such as the 90% quantile), use this quantile as the value of the radius, and set the minimum number of points to 5-10.

[0107] Using the selected radius and minimum number of points, all time interval data are clustered using DBSCAN. The DBSCAN algorithm traverses each point in the data set and divides the data points into different clusters based on density relationships.

[0108] The number of time intervals contained in each cluster is counted, and the cluster with the largest number of time intervals is recorded as the target cluster. The target cluster represents the time interval pattern corresponding to the most common working status of the task delivery object.

[0109] S32 is a quantity judgment, which judges whether the number of time intervals in multiple clusters is greater than a preset quantity threshold. In this embodiment, the value of the preset quantity threshold is 0.1N. In other embodiments, the value of the preset quantity threshold can also be set according to needs.

[0110] If there are multiple clusters in which the number of time intervals is greater than the preset number threshold, the clusters in which the number of time intervals is greater than the preset number threshold are recorded as valid clusters, and the step of model training in S33 is executed.

[0111] If the number of time intervals in no cluster is greater than the preset number threshold, the largest time interval in the target cluster is used as the heartbeat timeout threshold.

[0112] The heartbeat timeout threshold is used to determine whether the task delivery object is offline. If, in subsequent heartbeat detection, the server does not receive a heartbeat response from the task delivery object within the heartbeat timeout threshold, the object can be determined to be offline.

[0113] This step determines the heartbeat timeout threshold by clustering analysis based on historical heartbeat packet time intervals, which can set different offline judgment methods for different working states of the task delivery object, that is, one working state corresponds to one heartbeat timeout threshold.

[0114] S33 model training, adds labels to the time intervals in each valid cluster and builds a BI-LSTM model.

[0115] In this embodiment, the time interval sequence can be regarded as a time series data. The BI-LSTM model can learn the patterns and regularities in the time interval sequence, thereby performing classification prediction on new time intervals.

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

[0117] The input layer is used to input the normalized time intervals. The bidirectional LSTM layer is used to process the forward and backward information of the time series data. In this embodiment, two LSTM layers are set, each containing 64 LSTM units. The fully connected layer is used to fully connect the output of the bidirectional LSTM layer and map 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 valid cluster.

[0118] Split the labeled time interval data into a training set and a validation set in a ratio of 7:3. Set training parameters such as the learning rate, batch size, and number of training rounds. In this example, the learning rate is set to 0.001, the batch size is set to 32, and the number of training rounds is set to 50.

[0119] The BI-LSTM model is trained using the training set. During training, the backpropagation algorithm is used to update the model's parameters, enabling the BI-LSTM model to minimize the loss function between the predicted labels and the true labels. Furthermore, the validation set is used to evaluate the model's performance and prevent overfitting.

[0120] S34 predicts that the time interval of M heartbeat packets sent by the task issuing object before the current time is obtained and recorded as the second data. The value of M in this step is greater than 2.

[0121] The obtained second data is preprocessed in the same manner as the training data, including normalization and other operations.

[0122] All secondary data is fed into the trained BI-LSTM model in chronological order. Based on the learned patterns and regularities of the time interval sequences, the model classifies and predicts the input time interval sequence and outputs a predicted label, indicating the valid cluster to which the input time interval sequence most likely belongs. For example, if the trained BI-LSTM model outputs the label Cluster A, it indicates that the current heartbeat packet time interval pattern is most similar to the operating state represented by Cluster A.

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

[0124] After taking the third data as the heartbeat timeout threshold, the method further includes: Set the dynamic update cycle of the heartbeat timeout threshold. When the update cycle is reached, re-obtain the latest M historical heartbeat packet time intervals of the task delivery object, input the latest time interval data into the BI-LSTM model, and output a new prediction label. If the deviation between the maximum time interval in the valid cluster corresponding to the new prediction label and the current heartbeat timeout threshold exceeds the preset deviation threshold, the maximum time interval in the valid cluster corresponding to the new prediction label is updated to the heartbeat timeout threshold.

[0125] This embodiment updates the heartbeat timeout threshold in real time according to the prediction result of the current heartbeat packet time interval, which can more flexibly adapt to the changes in the working status of the task delivery object and improve the accuracy of offline determination.

[0126] Example 4: This embodiment discloses a remote task delivery management system, the system comprising: a memory and a processor, The memory stores a computer-readable storage medium; When the processor processes the computer program stored on the computer-readable storage medium, the remote task delivery management method is implemented.

[0127] The above are all preferred embodiments of the present application, and are not intended to limit the scope of protection of the present application. Therefore, any equivalent changes made based on the structure, shape, and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A remote task distribution management method, characterized in that: include: Obtain tasks to be issued, task cycles, and task issuing targets, count the number of task issuing targets, calculate the initial issuing frequency based on the number of task issuing targets and task cycles, and formulate the initial issuing strategy based on the tasks to be issued, task issuing targets, and initial issuing frequency; Construct a fuzzy control model and set the membership function and rule base of the fuzzy control model; The initial delivery strategy is deployed to the server, and the real-time resource occupancy rate and network bandwidth occupancy rate of the server are obtained. The concurrency coefficient is set through the fuzzy control model based on the real-time resource occupancy rate and network bandwidth occupancy rate. The initial delivery frequency in the initial delivery strategy is adjusted in real time according to the concurrency coefficient to obtain the target delivery strategy. The server sends the tasks to be delivered to the task delivery object according to the target delivery strategy.

2. The remote task distribution management method according to claim 1, characterized in that: Before counting the number of objects to which tasks are issued, the method further includes: Status judgment: Determine whether the i-th task delivery object is online. If so, record the i-th task delivery object as an intermediate object and execute the load judgment step; if not, update the i+1-th task delivery object to the i-th task delivery object and execute the status judgment step again; Load judgment: Real-time acquisition of the intermediate object's operating data, including CPU occupancy, memory usage, and task failure rate. A load index is calculated using a weighted average algorithm and the operating data. The load index is then determined to be 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 delivery object.

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

4. The remote task distribution management method according to claim 2, characterized in that: Before executing the state determination step, the method further includes: Each task-issuing object sends a heartbeat packet to the server according to a preset heartbeat cycle. The server updates the running status of the task-issuing object based on the heartbeat message in the heartbeat packet. The heartbeat packet includes the UUID, timestamp and running status of the task-issuing object. The running status includes online status and offline status; Construct a task object queue, which includes an offline queue and an online queue. Task objects in an offline state are placed in the offline queue in the order of heartbeat packet sending time, and task objects in an online state are placed in the online queue in the order of heartbeat packet sending time.

5. The remote task distribution management method according to claim 4, characterized in that: The method further comprises: Status verification: The server marks the task delivery object that has not received a heartbeat packet after the heartbeat timeout threshold has expired as an object with questionable status. The server initiates an active probe on the object with questionable status, obtains the active probe results, and updates the running status of the object with questionable status based on the active probe results. Get the updated running status of the object in questionable state, and determine whether the running status of the object in questionable state has changed. If so, deploy the object in questionable state to the end of the corresponding task object queue according to the updated status, and output the new online queue and the new offline queue; if not, resend the pending task to the task sending object.

6. The remote task distribution management method according to claim 5, characterized in that: The method further includes: the task delivery object updated from the offline state to the online state automatically sends an init instruction to the server, and the server deploys the task delivery object updated from the offline state to the end of the online queue.

7. The remote task distribution management method according to claim 5, characterized in that: Before performing the state verification step, the method further includes: Obtain the timestamps of N historical heartbeat packets of each task delivery object and record them as historical timestamps. Calculate the time intervals 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, and record the largest time interval in the target cluster as the heartbeat timeout threshold.

8. The remote task distribution management method according to claim 7, characterized in that: Before using the maximum time interval in the target cluster as the heartbeat timeout threshold, the method further includes: Determine whether there are multiple clusters whose number of time intervals is greater than a preset number threshold. If so, record the cluster whose number of time intervals is greater than the preset number threshold as a valid cluster; if not, use the largest time interval in the target cluster as the heartbeat timeout threshold; Label the time intervals in each valid cluster, build a BI-LSTM model, and train the BI-LSTM model using the labeled time intervals to obtain a trained BI-LSTM model. Obtain the time intervals of the M heartbeat packets sent by the task issuing object before the current time, record them as the second data, input all the second data into the trained BI-LSTM model in chronological order, and output the predicted label; The maximum time interval in the valid cluster corresponding to the predicted label is obtained, recorded as the third data, and the third data is used as the heartbeat timeout threshold.

9. The remote task distribution management method according to claim 1, characterized in that: When the task delivery object is offline or the number of times the task to be delivered is resent to the task delivery object exceeds the preset retry threshold, the server starts the task caching mechanism and stores the tasks to be delivered in the Redis queue in chronological order.

10. A remote task distribution management system, characterized in that: include: memory and processor, The memory stores a computer-readable storage medium; When the processor processes the computer program stored on the computer-readable storage medium, the method according to any one of claims 1 to 9 is implemented.

Images