A device reconnection scheduling method

Abstract

The application discloses a device reconnection scheduling method, and relates to the technical field of automation testing. The method comprises the following steps: acquiring connection state information, failure count information and current weight information of a device; when the connection state information is abnormal, distributing the device to a first queue or a second queue based on the failure count information and the current weight information; when the device is distributed to the first queue, controlling the device to execute a first reconnection strategy; when the device is distributed to the second queue, controlling the device to execute a second reconnection strategy, wherein the reconnection strength of the first reconnection strategy is higher than that of the second reconnection strategy; updating the failure count information and the current weight information of the device based on the reconnection result of the device; and determining the queue distribution of the device according to the updated failure count information and the current weight information.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, and in particular to a device reconnection scheduling method. Background Technology

[0002] In the existing field of device cluster management and automated testing, traditional reconnection scheduling mechanisms typically employ a uniform and fixed retry strategy for all faulty devices. When the device cluster is large or parallel testing tasks are heavy, this single scheduling method cannot distinguish the actual fault severity and historical behavior characteristics of different devices, resulting in high-fault-risk devices and low-fault-risk devices being treated equally in terms of reconnection resource acquisition. This undifferentiated scheduling method not only causes high-fault-risk devices to occupy system resources for extended periods due to frequent invalid retries, further exacerbating congestion in the overall task queue, but also forces low-risk devices that should recover quickly to wait passively, causing a serious mismatch between system resource allocation and actual device needs, ultimately leading to a decrease in overall cluster resource utilization and task processing efficiency. Therefore, a device reconnection scheduling method is urgently needed to solve the aforementioned technical problems. Summary of the Invention

[0003] The summary section introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. This summary section is not intended to limit the key and essential technical features of the claimed technical solutions, nor is it intended to determine the scope of protection of the claimed technical solutions.

[0004] Firstly, this application provides a device reconnection scheduling method, comprising:

[0005] Obtain the device's connection status information, failure count information, and current weight information;

[0006] When the connection status information is abnormal, the device is assigned to the first queue or the second queue based on the failure count information and the current weight information;

[0007] When the device is assigned to the first queue, the device is controlled to execute the first reconnection strategy;

[0008] When the device is assigned to the second queue, the device is controlled to execute a second reconnection strategy, wherein the reconnection strength of the first reconnection strategy is higher than that of the second reconnection strategy.

[0009] Based on the reconnection results of the device, update the failure count information and current weight information of the device;

[0010] The queue allocation for the device is determined based on the updated failure count information and the current weight information.

[0011] In some implementations, when the connection status information is abnormal, allocating the device to a first queue or a second queue based on the failure count information and the current weight information includes:

[0012] When the failure count information is greater than or equal to a preset failure count threshold, the device is assigned to the first queue;

[0013] When the current weight information is greater than or equal to a preset weight threshold, the device is assigned to the first queue;

[0014] When the failure count information is less than the preset failure count threshold and the current weight information is less than the preset weight threshold, the device is assigned to the second queue.

[0015] In some implementations, the current weight information is determined in the following way:

[0016] Obtain the device's basic weight value, the failure count information, and the time difference information between the current failure event and the previous failure event;

[0017] The current weight information is calculated based on the base weight value, the failure count information, and the time difference information.

[0018] In some implementations, calculating the current weight information based on the base weight value, the failure count information, and the time difference information includes:

[0019] Based on the time difference information, the time decay factor is determined;

[0020] Based on the failure count information and the time decay factor, calculate the weighted failure count;

[0021] The current weight information is calculated based on the base weight value and the number of weighting failures.

[0022] In some implementations, the first reconnection strategy includes a first number of attempts and a first time interval. The step of controlling the device to execute the first reconnection strategy when the device is assigned to the first queue includes:

[0023] When the device is assigned to the first queue, the device is controlled to perform a reconnection operation according to the first number of attempts and the first time interval.

[0024] In some implementations, the second reconnection strategy includes a second number of attempts and a second time interval. The step of controlling the device to execute the second reconnection strategy when the device is assigned to the second queue includes:

[0025] When the device is assigned to the second queue, the device is controlled to perform a reconnection operation according to the second number of attempts and the second time interval;

[0026] Wherein, the first number of attempts is greater than the second number of attempts, and the first time interval is less than the second time interval. When the first number of attempts is greater than the second number of attempts and the first time interval is less than the second time interval, it is determined that the reconnection strength of the first reconnection strategy is higher than that of the second reconnection strategy.

[0027] In some implementations, updating the failure count information and current weight information of the device based on the reconnection result of the device includes:

[0028] When the reconnection result is successful, the failure count information is cleared to zero, and the current weight information is reset to the basic weight value;

[0029] When the reconnection result is a failure, an accumulation operation is performed based on the failure count information to obtain the updated failure count information, and the updated current weight information is calculated based on the updated failure count information and the time difference from the last failure.

[0030] In some implementations, it also includes:

[0031] Based on the reconnection results, determine the number of consecutive successful connections for the device;

[0032] When the number of consecutive successes is greater than or equal to the preset threshold for consecutive successes, the current weight information is reset to the basic weight value.

[0033] In some implementations, it also includes:

[0034] Based on a preset time period, the current weight information of all devices is decremented to determine the current weight information after decay.

[0035] Based on the decayed current weight information, update the current weight information of the device.

[0036] In some implementations, after determining the queue allocation of the device based on the updated failure count information and the current weight information, the method further includes:

[0037] Based on the device presence status of the first queue and the second queue, determine the devices to be scheduled;

[0038] When a device exists in the first queue, the device in the first queue is identified as the device to be scheduled; or, when no device exists in the first queue, the device in the second queue is identified as the device to be scheduled.

[0039] Secondly, this application provides a device reconnection scheduling apparatus, comprising:

[0040] The information acquisition unit is used to acquire the device's connection status information, failure count information, and current weight information.

[0041] A queue allocation unit is used to allocate the device to a first queue or a second queue based on the failure count information and the current weight information when the connection status information is abnormal.

[0042] The first execution unit is configured to control the device to execute a first reconnection strategy when the device is allocated to the first queue.

[0043] The second execution unit is used to control the device to execute a second reconnection strategy when the device is allocated to the second queue, wherein the reconnection strength of the first reconnection strategy is higher than that of the second reconnection strategy.

[0044] The information update unit is used to update the failure count information and current weight information of the device based on the reconnection result of the device;

[0045] The queue reallocation unit is used to determine the queue allocation of the device based on the updated failure count information and the current weight information.

[0046] In summary, the device reconnection scheduling method provided in this application, by acquiring the connection status information, failure count information, and current weight information of the devices, enables the scheduling system to grasp the current health status and historical behavioral characteristics of each device. When an abnormal connection status information of a device is detected, the device is dynamically allocated to a first queue or a second queue based on the failure count information and current weight information. This step allows the scheduling strategy to classify and process devices according to their specific fault severity and historical performance, avoiding the disorderly resource competition caused by using a uniform scheduling method for all faulty devices. When a device is allocated to the first queue, the control device executes a first reconnection strategy with higher reconnection strength, so as to centrally allocate resources to prioritize devices with deeper fault severity or poor historical performance, preventing such devices from occupying system resources for a long time and dragging down the overall task queue due to frequent invalid reconnections. When a device is allocated to the second queue, the control device executes a second reconnection strategy with lower reconnection strength, so that devices with milder fault severity or good historical performance can complete the reconnection attempt with less system resources, avoiding unnecessary resource idleness for low-risk devices waiting passively for high-risk devices. After a device executes its corresponding reconnection strategy, its failure count and current weight information are updated based on the reconnection result. This ensures that the device's historical fault data is corrected according to the latest reconnection execution result, guaranteeing that scheduling decisions are always based on the latest device status. This prevents devices from being penalized for extended periods due to short-term, intermittent failures or from failing to recover to the normal scheduling queue in a timely manner due to their historical high failure rate. Based on the updated failure count and current weight information, the device's queue allocation is redefined, allowing devices to be promptly reclassified after a status change. Devices that recover quickly exit the high-intensity reconnection queue to release scheduling resources, while devices with persistent failures remain in the high-intensity reconnection queue until they successfully recover. Thus, this application, through a collaborative mechanism of hierarchical scheduling and status feedback updates, achieves a match between scheduling resources and the actual degree of device failure, improving cluster resource utilization efficiency and overall task processing performance. Attached Figure Description

[0047] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0048] Figure 1 This is a schematic flowchart of a device reconnection scheduling method provided in an embodiment of this application;

[0049] Figure 2 This is a schematic diagram of a device reconnection scheduling device provided in an embodiment of this application. Detailed Implementation

[0050] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0051] The device reconnection scheduling method provided in this application can be applied to multi-device parallel testing scenarios in the field of automated testing technology, and is particularly suitable for network stability assurance scenarios of large-scale device clusters. In practical applications, test device clusters typically contain dozens or even hundreds of monitored test devices, which need to execute parallel test tasks simultaneously. Due to network fluctuations, changes in device load, or hardware failures, some devices may experience connection interruptions. In such cases, a reconnection mechanism is needed to restore the connection between the device and the test system to ensure the continuity of test tasks. However, traditional reconnection scheduling methods use a uniform retry strategy for all faulty devices, failing to differentiate based on the historical fault behavior of the devices. This application constructs a hierarchical scheduling mechanism, suitable for test environments with large-scale device clusters, complex fault types, and high requirements for resource utilization efficiency. It effectively solves the conflict problem in reconnection resource allocation between high-fault and low-fault devices, improving the overall task processing performance of the cluster.

[0052] To facilitate understanding of the technical solution of this application, the meanings of specific terms used in this application are explained below:

[0053] The connection status information in this application refers to the indication information used to characterize whether the network connection between the device and the system is normal, including two states: normal connection and abnormal connection, which is used to trigger the reconnection scheduling process.

[0054] The failure count information in this application refers to the cumulative number of connection failure events that occur during the historical operation of the device. This count information serves as one of the data for assessing the degree of device failure and is dynamically updated as reconnection succeeds or fails.

[0055] The current weight information in this application refers to a numerical indicator used to quantify the current scheduling priority of a device. The higher the weight information, the greater the likelihood that the device will be assigned to the high-intensity reconnection policy queue. The value is calculated based on the device's basic weight value, failure count information, and the time distribution characteristics of failure events.

[0056] The basic weight value in this application refers to the weight benchmark value set by the device in the initial or reset state, which serves as the starting point for weight calculation and can be configured within a preset range.

[0057] The time difference information in this application refers to the time interval between the occurrence time of the current failure event and the occurrence time of the previous failure event. It is used to reflect the temporal density of equipment failures. The smaller the time difference information, the more concentrated the equipment failures are, and the greater the corresponding weight adjustment range.

[0058] The time decay factor in this application refers to the decay coefficient calculated based on time difference information, which is used to weight and correct the failure count information so that devices that fail frequently in the near future receive a higher weight adjustment value, while the impact of failure events that occur in the distant future on the current weight gradually weakens.

[0059] The weighted failure count in this application refers to the corrected value obtained by calculating the failure count information and the time decay factor. This corrected value is used to replace the original failure count information in the weight calculation, so as to reflect the impact of the time distribution characteristics of the failure on the scheduling priority.

[0060] The first queue in this application refers to a queue used to store devices that need to implement a high-intensity reconnection strategy. The devices in this queue usually have a high failure count or high current weight information, that is, devices with a deep fault degree or poor historical performance.

[0061] The second queue in this application refers to a queue for storing devices that need to implement the basic reconnection policy. The devices in this queue have a low failure count and low current weight information, that is, devices with a minor failure or good historical performance.

[0062] The first reconnection strategy of this application refers to a high-intensity reconnection operation scheme performed on devices in the first queue, which includes a higher number of attempts and a shorter time interval, aiming to centrally schedule resources to prioritize the processing of high-risk devices.

[0063] The second reconnection strategy of this application refers to the basic reconnection operation scheme performed on devices in the second queue, which includes a lower number of attempts and a longer time interval, aiming to restore low-risk devices with less system resources.

[0064] The reconnection strength in this application refers to an indicator used to measure the resource consumption of a reconnection strategy. It is characterized by a combination of the number of attempts and the time interval. The more attempts and the shorter the time interval, the higher the reconnection strength.

[0065] The reconnection result in this application refers to the feedback status after the device performs a reconnection operation, including two results: reconnection success and reconnection failure, which are used to trigger the update of failure count information and the adjustment of current weight information.

[0066] The consecutive success count in this application refers to the cumulative number of times the device has continuously executed tasks without failure after a successful reconnection. This is used to determine whether the device has entered a stable operating state and to trigger a weight reset operation.

[0067] The preset time period in this application refers to a fixed time interval set by the system, which is used to periodically trigger the decrement operation of the weight information of all devices in order to avoid devices being in a penalized state for a long time due to historical faults.

[0068] The device to be scheduled in this application refers to the next device selected from the first queue or the second queue that needs to perform a reconnection operation. The selection rule follows the principle of priority of the first queue, that is, when there is a device in the first queue, it is selected from the first queue first.

[0069] Please see Figure 1 This is a schematic flowchart of a device reconnection scheduling method provided in an embodiment of this application, which may specifically include:

[0070] S110. Obtain the device's connection status information, failure count information, and current weight information;

[0071] For example, connection status information is used to identify whether a device is currently in an abnormal state requiring reconnection, failure count information is used to quantify the frequency of failures accumulated by the device during historical operation, and current weight information reflects the scheduling urgency of the device under both failure frequency and time distribution dimensions. By simultaneously collecting these three types of information, the scheduling system can grasp the operating characteristics of each device from three levels: real-time status, historical performance, and dynamic priority, providing a data foundation for performing hierarchical scheduling based on individual device differences.

[0072] S120. When the connection status information is abnormal, the device is assigned to the first queue or the second queue based on the failure count information and the current weight information.

[0073] For example, when an abnormal connection status is detected in a device, it indicates that the device has exited normal communication and a reconnection scheduling process needs to be initiated. At this time, the scheduling system evaluates the device based on its historical failure count and current weight information. The failure count quantifies the degree of fault accumulation during the device's historical operation, while the current weight information characterizes the scheduling urgency of the device after considering the fault time distribution characteristics. Based on these two evaluation indicators, the device is assigned to either a first queue or a second queue, thus separating devices with deeper faults or higher scheduling urgency from those with shallower faults or lower scheduling urgency.

[0074] S130. When a device is assigned to the first queue, the control device executes the first reconnection strategy.

[0075] For example, when a device is assigned to the first queue, the control device executes the first reconnection strategy. This step is designed based on the characteristics of the devices carried in the first queue. Devices in the first queue usually have a high failure count or a high current weight information, which means that such devices have shown a high failure frequency or a more urgent scheduling need in the historical operation. If the same reconnection method is used as normal devices, such devices will occupy system resources for a long time due to frequent invalid reconnections. Not only will their own recovery efficiency be low, but they will also block the scheduling process of subsequent devices, creating a risk of fault propagation. Therefore, for devices in the first queue, the scheduling system assigns them a first reconnection strategy with a higher reconnection strength. By strengthening the investment of reconnection resources, high-risk devices are given priority. This allows such devices to obtain more frequent reconnection attempts within a limited scheduling window, shortens their recovery time, and prevents high-risk devices from staying at the front of the scheduling queue for a long time, which would have a negative impact on the overall task processing efficiency.

[0076] S140. When a device is assigned to the second queue, the control device executes the second reconnection strategy, and the reconnection strength of the first reconnection strategy is higher than that of the second reconnection strategy.

[0077] For example, when a device is assigned to the second queue, the control device executes the second reconnection strategy, and the reconnection strength of the first reconnection strategy is higher than that of the second reconnection strategy. Based on the fact that the devices in the second queue have shown lower failure counts and lower current weights in their historical operation, the fault severity of such devices is relatively mild or the scheduling urgency is relatively low. If the same high-strength reconnection strategy as the first queue is implemented for them, it will lead to excessive investment of system resources on low-risk devices, which will not only waste resources, but also crowd out the reconnection channels of high-risk devices. This will cause the already vulnerable high-risk devices to aggravate the spread of faults because they cannot obtain timely reconnection resources. Therefore, a second reconnection strategy with lower reconnection strength is adopted for the devices in the second queue to match their lower fault severity and scheduling needs, so that system resources are reasonably allocated among devices of different risk levels, avoiding low-risk devices occupying too many resources and delaying the recovery process of high-risk devices.

[0078] S150. Based on the device's reconnection results, update the device's failure count information and current weight information;

[0079] For example, the reconnection result directly reflects the recovery status of the device after undergoing a differentiated reconnection strategy. Based on this result, the device's failure count and current weight information are updated, allowing the system to promptly incorporate the device's latest operational performance into scheduling decisions. When reconnection is successful, it indicates that the device has restored normal communication capabilities. In this case, reducing its failure count and adjusting its weight helps release recovered devices from the high-intensity reconnection strategy, preventing stable devices from continuing to occupy additional scheduling resources due to historical fault records. When reconnection fails, it indicates that the device fault has not been resolved. In this case, increasing its failure count and recalculating its weight ensures that the device continues to maintain a high scheduling priority or remains in the high-intensity reconnection queue in subsequent scheduling, ensuring that devices with persistent faults repeatedly have the opportunity to reconnect until they recover. Through this mechanism of updating with reconnection results, the device's failure count and current weight information always remain consistent with the actual operational status.

[0080] S160. Determine the queue allocation for the device based on the updated failure count information and the current weight information.

[0081] For example, based on the updated failure count information and the current weight information, the queue allocation of devices is redefined so that after a device has undergone a reconnection attempt and updated its status, it is reassigned to a queue that matches its current status according to its latest failure accumulation level and scheduling urgency. Devices that have completed recovery are promptly removed from the high-intensity reconnection queue to release scheduling resources, while devices that have not yet recovered remain in the high-intensity reconnection queue to maintain their priority scheduling status. This ensures that the distribution of devices in the queue reflects the latest operating status of each device at the start of the next scheduling cycle, thus forming a dynamic scheduling mechanism.

[0082] In summary, the device reconnection scheduling method provided in this application, by acquiring the connection status information, failure count information, and current weight information of the devices, enables the scheduling system to grasp the current health status and historical behavioral characteristics of each device. When an abnormal connection status information of a device is detected, the device is dynamically allocated to a first queue or a second queue based on the failure count information and current weight information. This step allows the scheduling strategy to classify and process devices according to their specific fault severity and historical performance, avoiding the disorderly resource competition caused by using a uniform scheduling method for all faulty devices. When a device is allocated to the first queue, the control device executes a first reconnection strategy with higher reconnection strength, so as to centrally allocate resources to prioritize devices with deeper fault severity or poor historical performance, preventing such devices from occupying system resources for a long time and dragging down the overall task queue due to frequent invalid reconnections. When a device is allocated to the second queue, the control device executes a second reconnection strategy with lower reconnection strength, so that devices with milder fault severity or good historical performance can complete the reconnection attempt with less system resources, avoiding unnecessary resource idleness for low-risk devices waiting passively for high-risk devices. After a device executes its corresponding reconnection strategy, its failure count and current weight information are updated based on the reconnection result. This ensures that the device's historical fault data is corrected according to the latest reconnection execution result, guaranteeing that scheduling decisions are always based on the latest device status. This prevents devices from being penalized for extended periods due to short-term, intermittent failures or from failing to recover to the normal scheduling queue in a timely manner due to their historical high failure rate. Based on the updated failure count and current weight information, the device's queue allocation is redefined, allowing devices to be promptly reclassified after a status change. Devices that recover quickly exit the high-intensity reconnection queue to release scheduling resources, while devices with persistent failures remain in the high-intensity reconnection queue until they successfully recover. Thus, this application, through a collaborative mechanism of hierarchical scheduling and status feedback updates, achieves a match between scheduling resources and the actual degree of device failure, improving cluster resource utilization efficiency and overall task processing performance.

[0083] In some instances, when the connection status information is abnormal, the device is assigned to a first queue or a second queue based on the failure count information and the current weight information, including:

[0084] When the failure count is greater than or equal to the preset failure count threshold, the device will be assigned to the first queue.

[0085] When the current weight information is greater than or equal to the preset weight threshold, the device will be assigned to the first queue;

[0086] When the failure count is less than the preset failure count threshold and the current weight is less than the preset weight threshold, the device will be assigned to the second queue.

[0087] For example, when the device connection status information is abnormal, the device is judged based on the failure count information. When the device's failure count information is greater than or equal to a preset failure count threshold, the device is assigned to the first queue. Here, the preset failure count threshold is used to define whether the device has accumulated a significant failure frequency during historical operation. When the failure count information reaches or exceeds this threshold, it indicates that the device has repeatedly experienced connection interruptions in past test or operation cycles, and is considered a high-risk failure device. If such devices are handled in the same way as ordinary failure devices, their high-frequency failures will continuously occupy the reconnection channel, causing subsequent pending tasks to wait for a long time. Therefore, such devices are directly assigned to the first queue, putting them into the scheduling scope of the high-intensity reconnection strategy, ensuring that devices with high failure frequencies receive priority and more frequent reconnection attempts, and preventing the continuous drag on the overall task execution efficiency caused by their frequent failures.

[0088] If the failure count does not reach the preset failure threshold, the current weight information is used for determination. When the current weight information of a device is greater than or equal to the preset weight threshold, the device is also assigned to the first queue. The current weight information is a comprehensive evaluation indicator, which not only reflects the device's failure count but also incorporates the time difference between the current failure event and the previous failure event. When the time interval between two failure events is short, the weight information will increase to reflect that the device is in a state of concentrated failure. The preset weight threshold is used to define the scheduling urgency of the device at the current moment. When the weight information reaches or exceeds the threshold, it indicates that although the cumulative number of failures of the device may not be high, its failures are continuous or high-frequency. If processing is delayed, it is very likely to develop into a more serious and persistent failure state. Devices with such short-term high-frequency failures are identified by the weight threshold and classified into the first queue, so that scheduling resources can intervene in a timely manner and provide high-intensity intervention in the initial but concentrated stage of the failure to prevent it from evolving into a long-term intractable failure.

[0089] When the failure count is less than a preset failure threshold and the current weight is less than a preset weight threshold, the device is assigned to the second queue. This assignment condition corresponds to two types of devices: one type is low-risk devices with a low number of failures and no high-frequency history; the other type is devices that have experienced failures, but the time interval between the two failure events is relatively large, resulting in a low current weight. Both types of devices share the characteristics of minor failures and low scheduling urgency, and can recover within a reasonable number of attempts even with a relatively mild reconnection strategy. Assigning these devices to the second queue allows them to execute a lower-intensity reconnection strategy, preventing low-risk devices from passively occupying resources due to being in the same scheduling queue when high-risk devices urgently need a large number of reconnection resources, thus avoiding the congestion of reconnection channels for high-risk devices.

[0090] In summary, this application embodiment, based on the aforementioned queue allocation mechanism, achieves hierarchical isolation and targeted resource allocation for faulty devices. When a device with a high failure count is assigned to the first queue, high-intensity reconnection resources are concentrated to prioritize its persistent faults, preventing the entire scheduling process from being blocked due to repeated reconnection failures of a single high-risk device. When a device with a weight exceeding a threshold is assigned to the first queue, timely intervention is provided in the early stages of a concentrated outbreak, interrupting its continuous failure trend through a high-intensity strategy, preventing short-term high-frequency faults from deteriorating into long-term persistent faults. Simultaneously, devices with low failure counts and low weights are assigned to the second queue and restored using a basic reconnection strategy, preventing them from interfering with the processing of high-risk devices by occupying high-intensity reconnection resources. Thus, through the dual judgment conditions of failure count and weight information, devices are diverted to queues that match their fault severity and scheduling urgency, ensuring that high-intensity reconnection resources are only allocated to devices that truly require priority processing, while low-risk devices are restored with lower resource overhead. This creates a match between scheduling resources and actual device needs, improving the utilization efficiency of reconnection resources and the overall smoothness of task queue processing.

[0091] In some instances, the current weight information is determined in the following way:

[0092] Obtain the device's basic weight value, failure count information, and the time difference between the current failure event and the previous failure event;

[0093] The current weight information is calculated based on the base weight value, failure count information, and time difference information.

[0094] For example, the determination of current weight information is achieved by acquiring the device's base weight value, failure count information, and the time difference information between the current failure event and the previous failure event. The base weight value, serving as the starting benchmark for weight calculation, is assigned a fixed value within a preset range during device initialization or state reset. This base weight value determines the device's initial scheduling priority when no failure events have occurred. The failure count information records the cumulative number of connection failure events that have occurred during the device's historical operation. This count accumulates with each failure event and resets to zero upon successful reconnection, reflecting the cumulative degree of device faults. The time difference information characterizes the length of the time interval between the current failure event and the previous failure event. This information is used to determine the distribution characteristics of device faults in the time dimension. When the time interval between two failure events is short, it indicates that the device is in a phase of concentrated failure outbreaks; when the time interval is long, it indicates that the device faults are sporadic events.

[0095] After obtaining the above three types of information, a time decay factor is determined based on the time difference information. This time decay factor is negatively correlated with the time difference information; that is, the smaller the time difference, the larger the time decay factor, and vice versa. A weighted failure count is calculated based on the failure count information and the time decay factor. The weighted failure count is calculated by operating on the failure count information and the time decay factor, ensuring that multiple failure events occurring in a recent cluster contribute more to the weighted failure count than multiple failure events occurring in a dispersed manner. This reflects the temporal distribution characteristics of equipment failures in the weighted calculation results. Current weight information is calculated based on the base weight value and the weighted failure count. The calculated current weight information increases with the weighted failure count, giving higher weight values ​​to equipment with concentrated failures, thus granting them higher scheduling priority or a greater probability of being assigned to the first queue.

[0096] Through the aforementioned weight determination method, this application achieves the assessment of equipment failure severity. When equipment experiences multiple failures with short time intervals between them, the time decay factor is larger, and the weighted failure count is significantly higher than the original failure count. Such equipment will be prioritized for allocation to the first queue and subjected to a high-intensity reconnection strategy due to its weight information exceeding the threshold, receiving timely intervention from centralized scheduling resources in the early stages of a failure outbreak. When equipment experiences multiple failures but with long time intervals between them, the time decay factor is smaller, and the difference between the weighted failure count and the original failure count is smaller or even close. The current weight information will not remain high due to the accumulation of historical failure records, preventing equipment with occasional failures from suffering the same scheduling penalties as equipment with frequent failures for extended periods due to early failure events. Thus, the weight determination method ensures that the current weight information reflects not only the number of equipment failures but also the distribution density of these failure events over time. This allows the scheduling system to accurately distinguish between frequent continuous failures and occasional intermittent failures, allocating high-intensity reconnection resources to equipment truly in a period of high failure intensity, while avoiding unnecessary resource consumption on equipment with occasional failures, achieving a match between scheduling resources and the actual urgency of equipment failures.

[0097] As an exemplary implementation, in this embodiment, the preset failure count threshold can be set to 3 times, the preset weight threshold can be set to 5 times, and the basic weight value can be set to 5 times. It should be noted that the above values ​​are merely illustrative; in actual applications, these parameters can be adaptively adjusted according to the size of the device cluster, the complexity of the fault type, and the requirements for resource utilization efficiency. For example, the preset failure count threshold can be configured within an integer range of 2 to 5 times, the preset weight threshold can be configured within an integer range of 3 to 8 times, and the basic weight value can be configured within an integer range of 3 to 8 times.

[0098] In some instances, the current weight information is calculated based on the base weight value, failure count information, and time difference information, including:

[0099] Determine the time decay factor based on the time difference information;

[0100] Calculate the weighted number of failures based on failure count information and time decay factor;

[0101] Calculate the current weight information based on the base weight value and the number of weighting failures.

[0102] For example, when determining the time decay factor based on time difference information, the value of the time decay factor is negatively correlated with the magnitude of the time difference information. When the time difference information approaches zero, it indicates that the current failure event and the previous failure event are closely adjacent in time, and the device is in a dense phase of frequent failures. At this time, the time decay factor is set to a preset maximum value to enhance the contribution of recently concentrated failure events to the weight calculation. As the time difference information gradually increases, it indicates that the interval between the current failure event and the previous failure event is gradually lengthening, and the density of device failures is gradually weakening. At this time, the time decay factor decreases linearly with the increase of the time difference information. When the time difference information exceeds a preset time decay threshold, it indicates that the interval between the two failure events is long enough, and the current failure event is an occasional failure rather than a dense failure. At this time, the time decay factor is set to zero so that the current failure event no longer has an additional gain effect on the weight calculation, avoiding the device with occasional failures from suffering the same scheduling penalty in the weight calculation as the device with dense failures due to historical failure records.

[0103] Based on failure count information and a time decay factor, the weighted failure count is calculated by multiplying the failure count information and the time decay factor. The failure count information records the total number of connection failure events that have occurred during the device's historical operation, reflecting the cumulative degree of device failure. The time decay factor, as a weighting coefficient, adjusts the failure count information. When the time decay factor is large, it indicates that the time interval between the current failure event and the previous failure event is short, and the device is in a period of concentrated failures. The calculated weighted failure count is significantly higher than the failure count itself, amplifying the impact of recent concentrated failures on the weighting calculation. When the time decay factor is small, it indicates that the time interval between the current failure event and the previous failure event is long, and the degree of device failure density is low. The calculated weighted failure count is close to or even equal to the failure count information, minimizing the impact of scattered failure events on the weighting calculation result. When the time decay factor is zero, it indicates that the time interval between the current failure event and the previous failure event has exceeded the preset time decay threshold. The result of the weighted failure count calculation is zero, so that the current failure event no longer participates in the weight calculation, thus avoiding the unnecessary impact of occasional failures on the equipment scheduling priority.

[0104] Based on the base weight value and the weighted failure count, the current weight information is calculated by summing the base weight value and the weighted failure count. The base weight value serves as the initial weight benchmark for the device when no failure events occur. It is assigned a fixed value within a preset range during device initialization or state reset, and this benchmark value determines the device's basic scheduling priority during normal operation. The weighted failure count, as a quantitative indicator of the device's failure density, reflects the penalty increment after considering the time distribution characteristics of failures. When no failure events occur, the weighted failure count is zero, the current weight information equals the base weight value, and the device is in the lowest scheduling priority state. When a failure event occurs, the weighted failure count adjusts according to changes in time difference information, causing the current weight information to increase by a corresponding amount based on the base weight value. The magnitude of this increase depends on the density of failures.

[0105] In summary, the weight calculation process described in this application's embodiments introduces time difference information to weight and correct the failure count information, ensuring that the current weight information accurately reflects the distribution characteristics of device failures in the time dimension. When a device experiences multiple failures consecutively within a short period, the time difference information approaches zero, the time decay factor reaches its maximum value, the weighted failure count is amplified, and the current weight information experiences a significant increase based on the base weight value. This allows devices in the period of concentrated failure outbreaks to obtain higher weight values, and in subsequent scheduling, they are prioritized for allocation to the first queue and subjected to a high-intensity reconnection strategy. When a device experiences multiple failures but the interval between each failure is long, the time difference information is large, the time decay factor decreases accordingly, the amplification effect of the weighted failure count is weakened, and the increase in the current weight information is smaller, preventing scattered, intermittent failures from causing the device weight to remain consistently high. When the time difference information exceeds a preset time decay threshold, the time decay factor returns to zero, the weighted failure count returns to zero, and the current weight information falls back to the base weight value, allowing devices with intermittent failures to automatically release the scheduling penalty caused by the failure after a sufficiently long period of stable operation. Therefore, the weight calculation results enable the response to dense faults and the smooth handling of occasional faults, allowing scheduling resources to be allocated to devices that are truly in the period of dense faults.

[0106] As an exemplary implementation, the time decay factor is determined based on a comparison between the time difference information and a preset time threshold. When the time difference information is less than or equal to the preset time threshold, the time decay factor is set to 2; when the time difference information is greater than the preset time threshold, the time decay factor is set to 1. The weighted failure count is obtained by multiplying the failure count information by the time decay factor. The current weight information is obtained by adding the base weight value to the weighted failure count. It should be noted that the above-described value and calculation method of the time decay factor are merely examples, and the functional relationship between the time decay factor and the time difference information may be replaced by linear decay, exponential decay, or other reasonable functional relationships depending on the requirements for determining the fault density.

[0107] In some instances, the first reconnection policy includes a first number of attempts and a first time interval. When a device is assigned to the first queue, the control device executes the first reconnection policy, including:

[0108] When a device is assigned to the first queue, the control device performs a reconnection operation according to the first number of attempts and the first time interval.

[0109] For example, when a device is assigned to the first queue, the control device performs a reconnection operation according to a first number of attempts and a first time interval. The first queue is used to store devices that are judged to have a high degree of failure or a high degree of scheduling urgency based on the failure count information being greater than or equal to a preset failure count threshold or the current weight information being greater than or equal to a preset weight threshold. Such devices have a large number of accumulated failures or short intervals between failures in their historical operation. If the same number of reconnection attempts and time intervals as ordinary faulty devices are used, the frequent invalid reconnections will occupy system resources for a long time, resulting in low recovery efficiency and blocking the processing of subsequent devices by repeatedly occupying the scheduling channel.

[0110] Based on this, the first reconnection strategy configures a higher number of first attempts than the second reconnection strategy, and the first time interval configures a lower time interval than the second reconnection strategy. When a device is assigned to the first queue, the scheduling system performs reconnection operations according to the first number of attempts and the first time interval. That is, it initiates more frequent reconnection attempts for the device within a unit of time, so that devices in the period of concentrated fault outbreaks or high cumulative fault states can obtain more reconnection opportunities within a limited scheduling window, shortening the time window required for their recovery. At the same time, by increasing the density of reconnection attempts, the continuous occupation of the scheduling queue by the device during the waiting period for reconnection is reduced, so that scheduling resources are concentrated on high-risk devices in a short period of time, preventing such devices from being stuck at the front of the queue for a long time due to excessively long reconnection attempt intervals, thereby reducing their negative impact on the overall task processing efficiency.

[0111] Through the above configuration, the first reconnection strategy achieves intensive reconnection intervention for high-risk devices with a higher number of first attempts and a shorter first time interval. This allows devices with high failure counts or high weights to complete multiple reconnection attempts within a short period after entering the first queue. Compared to a strategy with fewer attempts and longer intervals, this avoids situations where devices continuously occupy scheduling resources between attempts without effective recovery due to excessively long reconnection attempt intervals. This concentrates system resources within the critical recovery window of high-risk devices, reducing ineffective waiting time. Simultaneously, after executing the first reconnection strategy, devices in the first queue update their failure counts and current weights based on the reconnection result, regardless of success or failure, and reassign queues. This ensures that devices that successfully recover through intensive intervention promptly exit the first queue, releasing the scheduling resources they occupy. Devices that fail to recover after intensive intervention remain in the first queue for the next round of intensive intervention because their failure counts continue to accumulate or their weights remain high, creating a continuous resource allocation bias towards high-risk devices.

[0112] Correspondingly, the devices in the second queue, employing a second reconnection strategy with fewer attempts and longer intervals, complete recovery with limited resource consumption. This avoids low-risk devices competing with high-risk devices for dense reconnection resources, allowing devices of different risk levels to receive reconnection resource investment commensurate with their fault severity. With a fixed total amount of overall scheduling resources, this enables the targeted redistribution of resources from low-risk devices to high-risk devices, improving the efficiency of scheduling resource utilization.

[0113] In some instances, the second reconnection strategy includes a second number of attempts and a second time interval. When a device is assigned to the second queue, the control device executes the second reconnection strategy, including:

[0114] When a device is assigned to the second queue, the control device performs a reconnection operation according to the second number of attempts and the second time interval.

[0115] For example, when a device is assigned to the second queue, the control device performs a reconnection operation according to the second number of attempts and the second time interval. The second queue is used to store devices that are judged to have low fault level and low scheduling urgency based on the failure count information being less than a preset failure number threshold and the current weight information being less than a preset weight threshold. Such devices have historically exhibited a small number of cumulative failures and long intervals between failures, and their connection interruptions are mostly occasional or transient anomalies, rather than continuous or frequent failures. If the same high-intensity reconnection strategy as the first queue is adopted for such devices, i.e., using a higher number of attempts and a shorter time interval, it will result in the same level of reconnection resources being allocated to low-risk devices as to high-risk devices. On the one hand, devices with occasional failures can usually restore normal communication after a few reconnection attempts. An excessive number of attempts will cause them to continue to perform meaningless additional reconnection operations after successful recovery, resulting in the invalid occupation of reconnection channels and the waste of system computing resources. On the other hand, the excessively short time interval will cause low-risk devices to initiate a dense number of reconnection requests in a short period of time, crowding out the reconnection channel bandwidth that should be allocated to high-risk devices. This will cause high-risk devices in the period of dense failures to prolong their recovery time because they cannot obtain reconnection opportunities in time, exacerbating the congestion of the overall scheduling queue.

[0116] Therefore, for devices in the second queue with low failure rates and low scheduling urgency, a lower number of second attempts is configured to match their characteristic of recovering after a few attempts. This avoids continuing redundant reconnection operations after the device has recovered. Simultaneously, a longer second time interval is configured to reduce the frequency of reconnection requests per unit time, allowing low-risk devices to relinquish scheduling channel resources during reconnection attempts and ensuring that high-risk devices receive priority scheduling rights within the reconnection window. When a device is assigned to the second queue, the scheduling system performs reconnection operations according to the specified number of second attempts and the second time interval. That is, it initiates a limited number of tentative reconnections within a preset longer time interval to attempt to restore the device connection.

[0117] In some instances, based on the device's reconnection results, the device's failure count and current weight information are updated, including:

[0118] When the reconnection result is successful, the failure count information is cleared to zero, and the current weight information is reset to the base weight value;

[0119] When the reconnection result is a failure, an accumulation operation is performed based on the failure count information to obtain the updated failure count information. Based on the updated failure count information and the time difference from the last failure, the updated current weight information is calculated.

[0120] For example, when the reconnection is successful, the failure count is cleared to zero, and the current weight is reset to the base weight value. A successful reconnection indicates that the device has recovered from the connection failure state, its communication link with the system has been re-established, and the device can re-participate in task scheduling. In this scenario, if the device's failure count still retains the previously accumulated value, the device will continue to suffer scheduling penalties corresponding to historical failure records, causing recovered devices to unnecessarily remain in the first queue or maintain a high weight value, crowding out reconnection resources that should be allocated to other devices still in a faulty state. Therefore, clearing the failure count eliminates the continued impact of historical failure records on the device's scheduling priority, allowing the device to re-participate in scheduling in its initial state. Simultaneously, resetting the current weight to the base weight value ensures the device maintains the lowest scheduling priority unless new failure events occur, preventing residual weights from historical failure records from interfering with the accuracy of queue allocation. Through these operations, successfully recovered devices exit the scheduling scope of the high-intensity reconnection strategy, releasing the scheduling channel resources they occupy in the first queue, allowing the system to concentrate limited intensive reconnection resources on faulty devices that have not yet recovered.

[0121] When reconnection fails, an accumulation operation is performed based on the failure count information to obtain updated failure count information. Then, based on the updated failure count information and the time difference from the previous failure, the updated current weight information is calculated. A reconnection failure indicates that the device has not restored its connection after experiencing the reconnection strategy corresponding to its queue, the device's fault state persists, and this failure event constitutes another connection anomaly record for the device in the time series. In this case, an accumulation operation is performed on the failure count information, adding this failure event to the historical cumulative count, so that the updated failure count information accurately reflects the cumulative frequency of connection failures of the device. This updated failure count information is used to increase the device's current weight value, enabling the device to maintain or further improve its scheduling priority in subsequent scheduling. Simultaneously, the time difference between this failure event and the previous failure event is obtained; this time difference is used to determine the distribution characteristics of the device's faults in the time dimension. When the time difference is small, it indicates that the equipment is in a period of concentrated failures. The calculated time decay factor is large, and the weighted failure count calculated based on the updated failure count and the time decay factor is significantly amplified. This results in a substantial increase in the updated current weight information compared to the base weight value, keeping the equipment stably in the first queue and subjecting it to continuous high-intensity reconnection strategies. When the time difference is large, it indicates that the equipment failure is an occasional event. The calculated time decay factor is small or zero, and the increase in the updated current weight information is small, preventing the equipment from being kept in a high scheduling priority state for an extended period due to a single, occasional failure.

[0122] In summary, this application's embodiments, through the aforementioned reconnection result-driven state update mechanism, form a closed-loop control link with the actual recovery status of the device as the feedback signal. Upon successful reconnection, by clearing the failure count information and resetting the current weight information to the base weight value, the device that has restored normal communication quickly exits the high-intensity reconnection queue, preventing it from continuously occupying scarce intensive reconnection resources due to historical fault records. This achieves the release and reallocation of scheduling resources from recovered devices to unrecovered devices. Upon reconnection failure, by performing an accumulation operation on the failure count information and incorporating the time distribution characteristics of this failure event into the weight calculation, the adjustment range of the current weight information matches the density of device faults: for devices experiencing continuous failures and in a period of high fault density, the weight information is increased, ensuring its stable retention in the first queue and acceptance of centralized intervention from the high-intensity reconnection strategy; for devices experiencing occasional failures with long intervals between failures, the increase in weight information is limited, preventing them from being placed in the high-intensity reconnection queue for an extended period due to a single occasional failure and enduring unnecessary intensive reconnection attempts. Therefore, this state update mechanism keeps the device's failure count information and current weight information synchronized with the latest operating state of the device. The result of each reconnection attempt is converted into a correction of the scheduling parameters, ensuring that the data on which subsequent queue allocation and reconnection strategy selection are based reflects the current degree of fault accumulation and time distribution characteristics of the device, thus forming a match between scheduling decisions and the actual device state.

[0123] In some instances, it also includes:

[0124] Based on the reconnection results, determine the number of consecutive successful connections for the device;

[0125] When the number of consecutive successes is greater than or equal to the preset threshold for consecutive successes, the current weight information is reset to the base weight value.

[0126] For example, the reconnection result reflects the device's recovery status after executing the reconnection strategy. When the reconnection result is successful, it indicates that the device has recovered from the connection anomaly. However, a single successful reconnection only represents that the device has completed connection reconstruction at a certain moment, which is insufficient to prove that the device has entered a stable operating state. If the device's failure count information and current weight information are reset based solely on a single successful reconnection, and the device experiences another connection anomaly shortly after recovery, its historical failure records will have been cleared due to the single success, making it impossible to identify that the device was recently in a fault state. This would cause the device, which should continue to be monitored by the high-intensity reconnection strategy, to be downgraded to the low-intensity reconnection queue. Therefore, the stability of the device after recovery is verified by the number of consecutive successful reconnections. When the device continues to operate stably after a successful reconnection and continuously completes the successful record of the preset consecutive success threshold, it indicates that the device has escaped the fault state and has stable operating capabilities. At this time, the current weight information is reset to the base weight value, so that the device is restored to the lowest scheduling priority state in subsequent scheduling, exits the high-intensity reconnection queue, and releases the intensive reconnection resources it occupies. This mechanism distinguishes between single, occasional recovery and continuous stable operation by setting a verification threshold for the number of consecutive successful operations. This ensures that the scheduling penalty caused by the device's historical fault records can only be lifted after the device has experienced multiple consecutive successful operations. This avoids repeated fluctuations in scheduling priority due to the device experiencing connection anomalies again after a brief recovery. At the same time, it ensures that devices that have truly entered a stable state are promptly removed from the high-intensity reconnection queue, and scheduling resources are allocated to other devices that are still in a fault state.

[0127] As an exemplary implementation, the preset consecutive success count threshold is set to 3 times. That is, when a device's consecutive success count reaches the preset threshold, the device's current weight information is reset to the base weight value, causing the device to leave the first queue. This prevents devices that have entered a stable operating state from continuously occupying scheduling resources due to historical failure records. It should be noted that the preset consecutive success count threshold can be set to other values, such as 2 or 5 times, depending on the device stability assessment requirements.

[0128] In some instances, it also includes:

[0129] Based on a preset time period, the current weight information of all devices is decremented to determine the current weight information after decay.

[0130] Update the device's current weight information based on the decayed current weight information.

[0131] For example, during the operation of a device, the device may accumulate a high current weight information due to multiple failure events that occurred in a certain period of history. Even if the device does not experience any new failure events in the long term, its current weight information may still remain at a high value due to the continued existence of historical failure records. This may cause the device to be continuously assigned to the first queue or to maintain a high scheduling priority during the scheduling process, and to bear the reconnection resource investment that is not commensurate with the current actual operating state.

[0132] To avoid long-term penalties caused by historical fault records, a global attenuation operation is initiated according to a preset time period. This preset time period is a fixed time interval used to uniformly control the attenuation frequency of weight information for all devices. At the end of each attenuation period, the current weight information of all devices is reduced, that is, a subtraction operation of a preset step size is performed on the current weight information of each device, so that the current weight information of the device is reduced by a preset value from the original value, resulting in the attenuated current weight information.

[0133] This decrementing process does not distinguish between the current queue type or the current failure count status of a device; it is executed uniformly on all devices to ensure that any weight information accumulated due to historical fault records gradually returns to near the base weight value over time. After determining the decremented current weight information, this decremented current weight information is used as the device's new current weight information for updating, enabling the device to participate in queue allocation based on the decremented weight information in subsequent scheduling.

[0134] Through this periodic decay mechanism, the current weight information of a device is no longer determined solely by historical failure records. Instead, it converges towards the base weight value over time. After a sufficiently long period of stable operation, even if the historical failure records have not been cleared, the current weight information of the device will gradually decrease to a level below the preset weight threshold due to periodic decay, and it will automatically leave the first queue. This avoids the device suffering unnecessary scheduling penalties during long-term operation due to early failure events, and achieves a balance between the device scheduling priority and its current actual operating status.

[0135] As an exemplary implementation, the preset time period can be set to 1 hour, and the step size for the decrementing process can be set to 1. That is, according to the preset time period, a decrementing operation is performed on the current weight information of all devices every hour, reducing the current weight information of each device by 1 from its original value until the current weight information drops to the base weight value. This periodic decay mechanism prevents devices from maintaining a high current weight information for an extended period due to occasional failure events in historical records, ensuring that the current weight information matches the current real-time operating status of the devices. It should be noted that the preset time period and the step size for the decrementing process can be configured according to the fault recovery characteristics and real-time scheduling requirements of the device cluster. For example, the preset time period can be set to 30 minutes or 2 hours, and the step size for the decrementing process can be set to 0.5 or 2.

[0136] In some instances, after determining the queue allocation for a device based on the updated failure count and current weight information, the process also includes:

[0137] Based on the device existence status of the first and second queues, determine the devices to be scheduled;

[0138] When a device exists in the first queue, the device in the first queue is identified as a device to be scheduled; or, when no device exists in the first queue, the device in the second queue is identified as a device to be scheduled.

[0139] For example, after the devices complete the queue allocation, the first queue contains devices that are judged to have a high degree of failure or a high degree of scheduling urgency based on the failure count information being greater than or equal to a preset failure number threshold or the current weight information being greater than or equal to a preset weight threshold. The second queue contains devices with a low degree of failure and a low degree of scheduling urgency, whose failure count information is less than the preset failure number threshold and whose current weight information is less than the preset weight threshold.

[0140] If devices to be scheduled are selected from two queues in no particular order at the same time, devices with low scheduling urgency may be scheduled first, causing devices with high failure rates to remain in the first queue because they cannot get a chance to reconnect in time. Their failure count information cannot be updated because they have not been reconnected for a long time, and their current weight information remains high because they lack feedback on reconnection results. This results in a scheduling congestion state in which devices with high failure rates continuously occupy the storage resources of the first queue without being effectively dealt with.

[0141] Therefore, when determining the devices to be scheduled, the first step is to check if any devices exist in the first queue. If so, the devices are selected from the first queue, giving high-failure-level devices priority in each scheduling cycle. This priority scheduling ensures that such devices can execute the first reconnection strategy promptly, striving to restore connections as quickly as possible amidst intensive reconnection attempts and preventing them from remaining in a faulty state for an extended period due to their lower scheduling order. Only when no devices exist in the first queue, indicating that there are currently no high-failure-level or high-schedule-urgency devices requiring priority processing, are devices selected from the second queue. This allows low-failure-level devices to execute the second reconnection strategy in an orderly manner without crowding out scheduling resources for high-risk devices. Through this priority scheduling rule, devices in the first queue always receive reconnection attempt opportunities before devices in the second queue. This ensures that scheduling resources are allocated according to the priority order of device failure severity and scheduling urgency, guaranteeing that high-failure-level devices receive priority in resource contention while preventing low-failure-level devices from preempting scheduling channels before high-risk devices have finished processing, thus forming a scheduling order that matches device priority.

[0142] Please see Figure 2 The diagram below illustrates the structure of a device reconnection scheduling device according to an embodiment of this application, comprising:

[0143] Information acquisition unit 21 is used to acquire device connection status information, failure count information and current weight information;

[0144] The queue allocation unit 22 is used to allocate the device to the first queue or the second queue based on the failure count information and the current weight information when the connection status information is abnormal.

[0145] The first execution unit 23 is used to control the device to execute the first reconnection strategy when the device is assigned to the first queue;

[0146] The second execution unit 24 is used to control the device to execute a second reconnection strategy when the device is assigned to the second queue, wherein the reconnection strength of the first reconnection strategy is higher than that of the second reconnection strategy.

[0147] Information update unit 25 is used to update the device's failure count information and current weight information based on the device's reconnection result;

[0148] The queue reallocation unit 26 is used to determine the queue allocation of the device based on the updated failure count information and the current weight information.

[0149] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features.

[0150] Although preferred embodiments have been described in this specification, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications that fall outside the scope of this specification.

[0151] Obviously, those skilled in the art can make various modifications to this specification without departing from its spirit and scope. Therefore, this specification also intends to include any modifications that fall within the scope of the claims and their equivalents.

Claims

1. A device reconnection scheduling method, characterized in that, include: Obtain the device's connection status information, failure count information, and current weight information; When the connection status information is abnormal, the device is assigned to the first queue or the second queue based on the failure count information and the current weight information; When the device is assigned to the first queue, the device is controlled to execute the first reconnection strategy; When the device is assigned to the second queue, the device is controlled to execute a second reconnection strategy, wherein the reconnection strength of the first reconnection strategy is higher than that of the second reconnection strategy. Based on the reconnection results of the device, update the failure count information and current weight information of the device; The queue allocation for the device is determined based on the updated failure count information and the current weight information.

2. The method according to claim 1, characterized in that, When the connection status information is abnormal, the device is assigned to a first queue or a second queue based on the failure count information and the current weight information, including: When the failure count information is greater than or equal to a preset failure count threshold, the device is assigned to the first queue; When the current weight information is greater than or equal to a preset weight threshold, the device is assigned to the first queue; When the failure count information is less than the preset failure count threshold and the current weight information is less than the preset weight threshold, the device is assigned to the second queue.

3. The method according to claim 1, characterized in that, The current weight information is determined in the following way: Obtain the device's basic weight value, the failure count information, and the time difference information between the current failure event and the previous failure event; The current weight information is calculated based on the base weight value, the failure count information, and the time difference information.

4. The method according to claim 3, characterized in that, The calculation of the current weight information based on the base weight value, the failure count information, and the time difference information includes: Based on the time difference information, the time decay factor is determined; Based on the failure count information and the time decay factor, calculate the weighted failure count; The current weight information is calculated based on the base weight value and the number of weighting failures.

5. The method according to claim 1, characterized in that, The first reconnection strategy includes a first number of attempts and a first time interval. When the device is assigned to the first queue, controlling the device to execute the first reconnection strategy includes: When the device is assigned to the first queue, the device is controlled to perform a reconnection operation according to the first number of attempts and the first time interval.

6. The method according to claim 5, characterized in that, The second reconnection strategy includes a second number of attempts and a second time interval. When the device is assigned to the second queue, controlling the device to execute the second reconnection strategy includes: When the device is assigned to the second queue, the device is controlled to perform a reconnection operation according to the second number of attempts and the second time interval; Wherein, the first number of attempts is greater than the second number of attempts, and the first time interval is less than the second time interval. When the first number of attempts is greater than the second number of attempts and the first time interval is less than the second time interval, it is determined that the reconnection strength of the first reconnection strategy is higher than that of the second reconnection strategy.

7. The method according to claim 3, characterized in that, The step of updating the failure count information and current weight information of the device based on the reconnection result of the device includes: When the reconnection result is successful, the failure count information is cleared to zero, and the current weight information is reset to the basic weight value; When the reconnection result is a failure, an accumulation operation is performed based on the failure count information to obtain the updated failure count information, and the updated current weight information is calculated based on the updated failure count information and the time difference from the last failure.

8. The method according to claim 7, characterized in that, Also includes: Based on the reconnection results, determine the number of consecutive successful connections for the device; When the number of consecutive successes is greater than or equal to the preset threshold for consecutive successes, the current weight information is reset to the basic weight value.

9. The method according to claim 1, characterized in that, Also includes: Based on a preset time period, the current weight information of all devices is decremented to determine the current weight information after decay. Based on the decayed current weight information, update the current weight information of the device.

10. The method according to claim 1, characterized in that, After determining the queue allocation for the device based on the updated failure count information and the current weight information, the process further includes: Based on the device presence status of the first queue and the second queue, determine the devices to be scheduled; When a device exists in the first queue, the device in the first queue is identified as the device to be scheduled; or, when no device exists in the first queue, the device in the second queue is identified as the device to be scheduled.

Images