Fusing processing method and device, storage medium and electronic equipment

Abstract

The invention discloses a fusing processing method and device, a storage medium and electronic equipment. Relates to the technical field of computer software, and the method comprises the following steps: obtaining historical execution durations corresponding to a plurality of commands of a development system in a historical time period, the plurality of commands being commands of the same type as a target command, and the historical time period being a time period of a predetermined duration before a current moment; determining a target timeout threshold based on the historical execution durations corresponding to the plurality of commands; under the condition that the execution duration of the target command exceeds a target timeout threshold value, obtaining a task priority corresponding to the target command and a system resource state; and determining a fusing processing strategy of the target command based on the task priority and the system resource state. According to the invention, the technical problems of overtime misjudgment and resource overload during command execution in an open system in the prior art are solved.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and more specifically, to a circuit breaker processing method, apparatus, storage medium, and electronic device. Background Technology

[0002] In modern open system environments, especially high-concurrency, distributed environments, the accuracy of command execution (such as Shell commands) and the effective management of system resources have become major challenges. In related technologies, command execution timeout thresholds are often statically set, meaning a fixed duration is manually estimated at the beginning of program design. This approach has revealed significant limitations in actual operation. On the one hand, due to the dynamic nature of variables such as system load, network conditions, and data volume, fixed thresholds are difficult to adapt to changes in the execution environment. This leads to thresholds that are too strict when resources are plentiful, causing commands to be mistakenly killed; while thresholds that are too lenient when resources are scarce can easily trigger system-wide avalanche effects. On the other hand, circuit breaker strategies in related technologies, such as the Hystrix circuit breaker mechanism, treat all command requests equally, uniformly breaking them without considering the differences in business priorities of different tasks. This can cause critical business operations to be affected or even interrupted due to resource competition from non-core tasks, seriously impacting the stability and business continuity of the developed system.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a circuit breaker processing method, apparatus, storage medium, and electronic device to at least solve the technical problems of timeout misjudgment and resource overload during command execution in open systems in related technologies.

[0005] According to one aspect of the present invention, a circuit breaker method is provided, comprising: obtaining the historical execution duration of multiple commands corresponding to each command in a development system within a historical time period, wherein the multiple commands are commands of the same type as a target command, and the historical time period is a time period of predetermined duration prior to the current time; determining a target timeout threshold based on the historical execution duration of each command; if the execution duration of the target command exceeds the target timeout threshold, obtaining the task priority and system resource status corresponding to the target command; and determining a circuit breaker strategy for the target command based on the task priority and system resource status.

[0006] According to another aspect of the present invention, a circuit breaker processing apparatus is also provided, comprising: a historical execution duration acquisition module, configured to acquire the historical execution duration of multiple commands corresponding to each command in a development system within a historical time period, wherein the multiple commands are commands of the same type as the target command, and the historical time period is a time period of predetermined duration prior to the current time; a timeout threshold determination module, configured to determine a target timeout threshold based on the historical execution duration of each of the multiple commands; an information acquisition module, configured to acquire the task priority and system resource status corresponding to the target command when the execution duration of the target command exceeds the target timeout threshold; and a strategy determination module, configured to determine the circuit breaker processing strategy for the target command based on the task priority and the system resource status.

[0007] According to another aspect of the present invention, a non-volatile storage medium is also provided, which stores a plurality of instructions adapted for a circuit breaker method to be loaded by a processor and executed at any one of them.

[0008] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any one of the circuit breaker methods.

[0009] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of any one of the circuit breaker processing methods.

[0010] In this embodiment of the invention, the historical execution durations of multiple commands corresponding to each command within a historical time period are obtained from the development system. These multiple commands are of the same type as the target command, and the historical time period is a predetermined duration prior to the current moment. Based on the historical execution durations of each command, a target timeout threshold is determined. If the execution duration of the target command exceeds the target timeout threshold, the task priority and system resource status corresponding to the target command are obtained. Based on the task priority and system resource status, a circuit breaker strategy for the target command is determined. This achieves the goal of dynamically analyzing historical execution time to adaptively predict the timeout threshold and dynamically deciding on the circuit breaker strategy by combining business priority and real-time system operation information. This results in reducing the command execution failure rate, ensuring the continuity of core business operations, and improving the overall stability of the system. Furthermore, it solves the technical problems of timeout misjudgment and resource overload during command execution in open systems in related technologies. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0012] Figure 1 This is a flowchart of a circuit breaker processing method according to an embodiment of the present invention;

[0013] Figure 2 This is a flowchart of an optional circuit breaker method according to an embodiment of the present invention;

[0014] Figure 3 This is an optional dynamic timeout prediction flowchart according to an embodiment of the present invention;

[0015] Figure 4 This is an optional tiered circuit breaker decision-making flowchart according to an embodiment of the present invention;

[0016] Figure 5 This is a schematic diagram of a fuse-breaking device according to an embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention 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 of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises 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.

[0019] First, to facilitate understanding of the embodiments of the present invention, some terms or nouns involved in the present invention will be explained below:

[0020] Shell commands are a type of programming language. As a command language, it interactively interprets and executes user-input commands or automatically interprets and executes a pre-defined series of commands; as a programming language, it defines various variables and parameters and provides many control structures typically found in high-level languages, including loops and branches.

[0021] Command normalization is a common concept in system design, software engineering (especially middleware, API gateways, and microservice architecture), and automation control. It refers to the process of converting instructions / requests from different sources, formats, or protocols into a unified, standardized internal representation or execution format. This is achieved by standardizing input shell commands, ignoring variable parameters (such as file paths and timestamps).

[0022] Sliding window search is an efficient algorithm strategy primarily used to handle contiguous subarrays or subsequences of arrays / strings. Its core idea is to maintain a fixed-size or variable-size "window" and dynamically move the start and end positions of the window to efficiently traverse the data, avoiding redundant calculations and thus reducing time complexity.

[0023] A Circular Input / Output (FIFO) queue is a fixed-length queue that automatically deletes the oldest element and adds a new element when the capacity is full. It is often used in scenarios that require a fixed capacity and cyclic processing.

[0024] An open system environment refers to a system environment that supports interoperability and compatibility of different hardware, software, network and other technologies, and allows various components, services and applications to communicate and collaborate freely on the basis of standard interfaces and protocols.

[0025] According to an embodiment of the present invention, a method embodiment for circuit breaker processing is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0026] Figure 1 This is a flowchart of a circuit breaker processing method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0027] Step S102: Obtain the historical execution duration of each of the multiple commands in the development system within the historical time period. The multiple commands are commands of the same type as the target command, and the historical time period is a time period with a predetermined duration before the current time.

[0028] Optionally, the target command can be a shell command. This step aims to collect historical command execution data of the same type as the target command to be executed. This data comes from a historical time period, which is a predefined time period preceding the current moment, such as the last 24 hours. By collecting this historical data, the system can understand the execution performance of the target command type under different conditions, including the average execution time and the range of fluctuation in execution time when the system load changes, providing a basis for predicting subsequent timeout thresholds.

[0029] In one optional embodiment, obtaining the historical execution duration of multiple commands in the development system within a historical period includes: normalizing the target command to obtain a normalized command; determining the command type corresponding to the normalized command; and determining multiple commands and their respective historical execution durations based on the command type.

[0030] Optionally, the target command can be normalized to eliminate dynamic or irrelevant parts, such as specific dates or file paths in filenames, transforming it into a standardized template command, i.e., a normalized command. The purpose of this is to enable searching the system for all execution records of the same type as the target command, even if their parameters differ. For example, normalizing the command `grep "error" / nas / log / pod_20250701.log` to `grep "error" / nas / log / pod_` .log. Through normalization, the system can focus on the behavioral patterns of commands of the same type, without being influenced by subtle differences in specific instances. The command type is the category of operations to which a command belongs after normalization. By comparing the normalized command with standard templates stored in a known command type library, the current command can be mapped to a specific category, ensuring that the acquired data is a historical record consistent with the target command type. After determining the type of the target command, a historical data store, such as a database or similar data structure, is accessed to find all past commands matching that type and their execution durations. Multiple commands refer to all command execution instances of the same type as the target command within a predefined historical period. Timeout thresholds can be calculated using the corresponding historical execution durations, allowing for dynamic prediction of the expected execution time of the target command.

[0031] This embodiment establishes a basic data collection process for obtaining timeout thresholds through normalization, command type determination, and historical execution duration retrieval. This process ensures that the system can accurately identify and classify commands, and then make predictions based on the historical behavior of similar commands, providing solid data support for subsequent timeout threshold setting and circuit breaker decisions. This mechanism enables the developed system to more intelligently and flexibly respond to the execution characteristics of different types of commands in different environments, improving overall processing efficiency and stability.

[0032] Step S104: Determine the target timeout threshold based on the historical execution duration of each of the multiple commands.

[0033] Optionally, after collecting historical execution times, statistical analysis methods can be used to predict the timeout threshold of the target command to adapt to the uncertainty of command execution time, ensure that the threshold setting can cover the vast majority (e.g., 99.73%) of normal execution situations, and reduce the possibility of timeout misjudgment.

[0034] In one optional embodiment, determining a target timeout threshold based on the historical execution duration of each of the multiple commands includes: determining the average and standard deviation of the historical execution duration of each of the multiple commands; and determining the timeout threshold based on the average and standard deviation in the following manner: Where timeout represents the target timeout threshold. This represents the average value. Indicates standard deviation, It is the multiple factor of the normal distribution.

[0035] Optionally, after collecting the execution times of historical commands of the same type as the target command, statistical analysis of this time data should be performed first. Average value ( The calculation is the arithmetic mean of all historical execution times, representing the average command execution time. The standard deviation (...) The mean and standard deviation are used to measure the dispersion of these execution times relative to the average, i.e., the magnitude of the fluctuation in execution time. Together, the mean and standard deviation help to understand the typical range and uncertainty of command execution time. Once the mean and standard deviation are obtained, the principle of normal distribution can be applied to dynamically set the target timeout threshold. In a normal distribution, most (approximately 99.73%) of the data points will fall within three standard deviations (μ ± 3σ) of the mean. Therefore, by setting the timeout threshold to be a multiple of the standard deviation added to the mean (i.e.,...), the target timeout threshold can be set accordingly. The K factor can largely cover the execution time under normal circumstances, while K, as a normality distribution factor, can be dynamically adjusted according to business needs and the real-time status of the system to adapt to timeout tolerance in different scenarios. The choice of the K factor is particularly critical. In most cases, K is set to 3 by default. However, when the system observes frequent timeout events or the command execution time distribution shows a high positive skewness, K can be adaptively increased to 4 to capture a wider range of execution time distributions and reduce the probability of false timeouts, especially for commands with long-tailed execution time distributions.

[0036] The above methods not only provide mathematically accurate timeout predictions but also adapt to the dynamic changes and uncertainties in command execution time, effectively reducing resource waste and false positives caused by fixed timeout mechanisms, while improving system responsiveness and overall stability. By dynamically adjusting the timeout threshold, the method in this embodiment can intelligently respond to fluctuations in system load, ensuring reasonable and timely circuit breaker decisions under various conditions, thereby better protecting system resources and the continuous operation of critical services.

[0037] In an optional embodiment, before determining the target timeout threshold based on the historical execution duration of each of the multiple commands, the method further includes: determining the proportion of timeout commands among the multiple commands based on the historical execution duration of each of the multiple commands and the corresponding timeout threshold, wherein the timeout command proportion represents the proportion of the number of commands whose historical execution duration exceeds the corresponding timeout threshold to the total number of multiple commands; and determining the normal distribution factor based on the timeout command proportion and the task priority.

[0038] Optionally, before calculating the timeout threshold, the command execution data in historical data should be analyzed to statistically determine the proportion of timeout commands among similar command executions. The timeout command proportion refers to the ratio of the number of commands whose actual execution time exceeded their respective timeout thresholds to the total number of all historical command execution records. This statistic helps understand the accuracy and efficiency of past circuit breaker decisions and whether there were excessive or insufficient circuit breakers. The calculated timeout command proportion, along with task business priority information, is used to dynamically adjust the value of the normality distribution factor K. The adjustment strategy for the K factor can be based on the following logic: if the timeout command proportion is too high, it indicates that the currently set timeout threshold may be too low and insufficient to cover the execution time of most commands. In this case, K should be appropriately increased, for example, from the default 3 to 4, to expand the range of timeout thresholds and reduce the false alarm rate of circuit breakers. Conversely, if the timeout command proportion is very low, it indicates that the threshold may be too lenient, leading to resource waste. The K factor may remain unchanged or be appropriately reduced to improve the system's resource utilization efficiency. Additionally, the task's business priority also affects the adjustment of the K factor. For example, a more conservative circuit breaker strategy can be configured for high-priority tasks, using a larger K value to ensure these critical tasks have a longer time window to complete, even if it means tolerating lower efficiency. For low-priority tasks, a more aggressive strategy can be adopted, setting a lower K value to trigger circuit breakers or degradation earlier, thereby protecting system resources and ensuring the stable operation of core business processes.

[0039] By introducing the analysis of the proportion of timeout commands and dynamically adjusting the K-factor based on this, the method in this embodiment can more intelligently adapt to the needs of different business scenarios and the actual state of system resources, improving the accuracy and flexibility of the circuit breaker mechanism. This adaptive adjustment mechanism can not only reduce the impact on core businesses, but also more effectively release the resources of non-core services when the system is overloaded, thereby achieving the dual goals of system-level resource optimization and business operation stability.

[0040] As an optional embodiment, the normal distribution factor can be determined based on the proportion of timed-out commands and the task priority in the following manner: determine the first weight corresponding to the proportion of timed-out commands and the second weight corresponding to the task priority; perform a weighted calculation based on the proportion of timed-out commands, the task priority, the first weight and the second weight to obtain a weighted score; and determine the normal distribution factor based on the weighted score.

[0041] The percentage of timeout commands represents the proportion of commands that time out within a given period, reflecting the accuracy and necessity of the circuit breaker strategy. A higher percentage of timeout commands indicates that the circuit breaker strategy may be too strict, requiring a relaxation of the threshold by increasing the K value to avoid unnecessary timeouts. Conversely, a low percentage of timeout commands may mean the threshold is too lenient, and the K value should be reduced to improve resource utilization. Task priority reflects the importance of commands in the business logic. High-priority commands should have higher K values ​​to provide sufficient execution time windows, while low-priority commands can have lower K values, sacrificing some execution time to ensure efficient use of system resources. Each priority level corresponds to a preset second weight, reflecting its importance in resource allocation decisions. The weighted score calculation comprehensively considers the impact of the percentage of timeout commands and task priority. Specifically, the percentage of timeout commands and task priority are multiplied by their corresponding first and second weights, respectively, and then these two products are added together to obtain a comprehensive score reflecting the command execution characteristics and business requirements. This scoring calculation ensures that the resource allocation strategy considers both the actual system conditions (resource load and timeout frequency) and the importance of business logic (priority). Based on the calculated weighted score, the normality distribution factor K can be dynamically adjusted. The score directly affects the setting of K; a high score may indicate that the system should adopt a more lenient circuit breaker threshold, allowing for longer timeouts, while a low score may prompt the system to tighten the threshold and reduce resource waste. The adjustment range of K can be determined based on actual business needs and real-time monitoring data of system resources. Generally, the higher the score, the greater the adjustment range of K, and vice versa.

[0042] By introducing a weighted scoring calculation method, this embodiment can more accurately balance the relationship between resource utilization and business continuity, achieving adaptive optimization of resource allocation strategies in both time and space dimensions. This dynamic adjustment mechanism based on weighted analysis not only improves the overall responsiveness and fault tolerance of the system, but also strengthens the protection of core businesses. It ensures that, under conditions of limited resources, critical services are prioritized for stable operation, while non-core services are appropriately downgraded. This also avoids excessive resource consumption and potential system overload risks, thereby improving the overall efficiency and reliability of the system.

[0043] Step S106: If the execution time of the target command exceeds the target timeout threshold, obtain the task priority and system resource status corresponding to the target command.

[0044] Optionally, when the execution time of the target command exceeds the dynamic timeout threshold determined in the previous two steps, the business priority information of the command is immediately obtained. Business priority reflects the importance of the command in the business logic and can be predefined; for example, the payment service has a higher priority than the log cleanup service. Simultaneously, the current resource status of the development system is monitored and obtained in real time, including key indicators such as CPU utilization, memory usage, and network latency. This information will be used for the next step of circuit breaker strategy decision-making.

[0045] Step S108: Determine the circuit breaker strategy for the target command based on task priority and system resource status.

[0046] Optionally, based on the collected business priorities and system resource status, a circuit breaker strategy for target commands can be dynamically determined. The circuit breaker strategy may include, but is not limited to, immediate execution (for high-priority commands), delayed execution (for medium-priority commands), or rejection (for low-priority commands), as well as resource protection measures during system overload. Implementing this strategy ensures that the system prioritizes the continuity and stability of core business operations when resources are scarce, while simultaneously preventing system crashes or service avalanches by degrading the execution of non-core commands, thus improving the overall fault tolerance and response efficiency of the system. In summary, the above-mentioned circuit breaker method predicts the likelihood of command timeouts in advance through statistical analysis of historical data, and dynamically adjusts the circuit breaker strategy in conjunction with real-time resource monitoring and business priorities. This achieves precise control and efficient utilization of system resources, enhancing the robustness and flexibility of the system while ensuring critical business services.

[0047] In one optional embodiment, the circuit breaker strategy for the target command is determined based on task priority and system resource status, including: if the system resource status exceeds a preset occupancy threshold and the task priority is the first priority, determining the circuit breaker strategy to continue executing the target command; or if the system resource status exceeds the preset occupancy threshold and the task priority is the second priority, determining the circuit breaker strategy to add the target command to a delayed execution queue; or if the system resource status exceeds the preset occupancy threshold and the task priority is the third priority, determining the circuit breaker strategy to refuse to execute the target command.

[0048] Optionally, the system first monitors the usage status of critical resources in the development system in real time, such as CPU utilization and memory usage. When the usage of these resources exceeds a preset threshold (e.g., CPU utilization reaches 90%), the business priority of the current target command is checked. If the target command is of the highest priority (first priority, such as priority ≥ 0.8), such as commands involving financial transactions or system security, even if system resources are strained, this command should be executed first to ensure the continuity and stability of core business operations. Therefore, the circuit breaker policy will specify that these commands continue to execute without triggering the circuit breaker. For commands with slightly lower priority (second priority, such as 0.3 < priority < 0.8), such as data synchronization or log processing, the execution of these commands can be appropriately delayed when system resources are under high load to reduce system burden and avoid resource overload. In this case, the circuit breaker policy will place the target command in a circular input / output FIFO delayed execution queue, waiting for the system resource status to return to normal or for lower priority commands to complete before execution. This protects system resources while ensuring that non-core but important services are processed at the appropriate time. For commands with the lowest priority (third priority, such as priority ≤ 0.3), such as cache cleanup or log archiving, execution is considered unnecessary when system resources are already overloaded, and may even further exacerbate resource pressure. In this situation, the circuit breaker policy will directly reject the execution of these low-priority commands to free up more resources for high-priority commands, ensuring that core business operations are not affected, and also facilitating the system's rapid recovery from overload.

[0049] Through the circuit breaker strategy described above, the method in this embodiment can intelligently adjust the command execution strategy based on the specific business priority of the command and the current resource usage of the system. This tiered circuit breaker mechanism not only improves the resource management and scheduling capabilities of the development system but also enhances the protection of core business logic. Furthermore, by delaying or rejecting the execution of non-core commands, it effectively avoids the risks of resource overload and system crashes, thereby improving the robustness of the entire development system and the user experience. This method is particularly suitable for complex distributed system environments with dynamically changing resources and diverse business requirements.

[0050] In an optional embodiment, when the system resource status exceeds a preset occupancy threshold and the task priority is the second priority, after determining the circuit breaker processing strategy for the target command based on the task priority and the system resource status, the method further includes: when the system resource status is lower than the preset occupancy threshold, executing the commands in the delayed execution queue in the order they were added to the delayed execution queue, wherein, during the sequential execution of the commands in the delayed execution queue, the system resource status is kept continuously lower than the preset occupancy threshold.

[0051] Optionally, when resource usage exceeds a preset threshold (e.g., excessive CPU or memory usage), and the current command's task priority is marked as second priority (non-core but important commands), such as data synchronization or report generation, a circuit breaker strategy is executed. These commands are temporarily placed in a delayed execution queue to protect the operation of core services and prevent system overload. If system resource status falls below the preset threshold, the circuit breaker recovery process begins. Commands in the delayed execution queue are executed sequentially according to the order they were added. In other words, once system resource status returns to normal, i.e., resource usage falls below the preset threshold, execution of second-priority commands that were delayed during high load begins. The order of execution recovery follows a first-come, first-served principle, ensuring fairness and business continuity by adhering to the order in which commands were initially added to the delayed execution queue. To prevent system overload during command recovery, resource status can be monitored in real time to ensure that system resource usage does not exceed the preset threshold again when executing commands in the delayed command queue. Measures such as limiting the number of commands executed per unit time, dynamically adjusting the execution rate of the delay queue, and pausing or slowing down command execution when resource usage approaches a threshold can be implemented to keep system resource status consistently below the preset usage threshold.

[0052] This embodiment of the method performs circuit breaking on non-core but important second-priority commands during periods of high load, effectively preventing system avalanche and protecting the stable operation of core services. After the load eases, the execution of delayed commands is resumed in an orderly manner, avoiding resource idleness and ensuring a smooth system transition and recovery, preventing a sudden surge in resource usage again. This closed-loop resource management and circuit breaker recovery strategy not only improves system robustness and responsiveness but also promotes efficient resource utilization, ensuring that various services are appropriately processed and executed in a dynamically changing environment, thereby improving overall service quality and user experience.

[0053] In an optional embodiment, when the system resource status exceeds a preset occupancy threshold and the task priority is the second priority, after determining the circuit breaker handling strategy for the target command based on the task priority and the system resource status, the method further includes: when the system resource status is below the preset occupancy threshold, resuming the execution of a predetermined proportion of commands in the delayed execution queue at predetermined intervals according to the order in which they were added to the delayed execution queue; and resuming the execution of the remaining commands in the delayed execution queue when the execution success rate of a predetermined proportion of commands for a predetermined number of consecutive times is greater than a preset proportion.

[0054] Optionally, when resource usage exceeds a preset threshold (e.g., excessive CPU or memory usage), and the current command's task priority is marked as second priority (non-core but important commands), such as data synchronization or report generation, a circuit breaker strategy is executed. These commands are temporarily placed in a delayed execution queue to protect the operation of core services and avoid system overload. When system resource status returns to normal, i.e., resource usage falls below the preset threshold, the circuit breaker recovery process begins. This can be done by batch recovery, resuming execution of a certain percentage (e.g., 10%) of commands from the delayed execution queue at preset time intervals (e.g., every 5 seconds). This method ensures that command execution does not cause new impacts on the development system as resources gradually recover, contributing to smooth system resource utilization and stable system recovery. During the gradual recovery of delayed commands, the success rate of these commands is continuously monitored. If more than a preset percentage (e.g., 90%) of the commands successfully execute in several consecutive (e.g., 5) recovery attempts, this indicates that the system status has stabilized and is sufficient to support the execution of more commands. At this point, the system can consider that the resources have been fully restored and is no longer limited to the batch recovery strategy. Instead, it can safely resume the execution of all remaining commands in the delayed execution queue to accelerate the full recovery of business operations.

[0055] The progressive recovery execution scheme proposed in this embodiment combines real-time monitoring of resource occupancy status with a feedback mechanism for command execution success rate. This not only avoids the risk of system overload caused by releasing a large number of commands at once during resource recovery, but also ensures smooth and efficient business recovery. It can maximize the protection of core business operations while fully utilizing resource gaps to orderly restore the execution of non-core but important services, thereby improving the overall stability and response speed of the development system.

[0056] Through the above steps S102 to S108, the goal of dynamically analyzing historical execution time to adaptively predict timeout thresholds and dynamically deciding on circuit breaker strategies by combining business priorities and real-time system operation information can be achieved. This achieves the technical effects of reducing command execution failure rate, ensuring core business continuity and improving overall system stability, and solves the technical problems of timeout misjudgment and resource overload in command execution in open systems in related technologies.

[0057] Currently, using shell scripts in Java programs is a practical integration strategy. Its core purpose is to leverage the power of the operating system's native command-line tools and reuse existing script assets to supplement Java's shortcomings or complexity in handling certain system-level tasks. It is very common in scenarios such as deployment, operation and maintenance, system administration, and rapid processing of system resources. For batch processing tasks that require sequential execution of a series of system commands, manipulation of large numbers of files, starting / stopping services, etc., writing a shell script is usually much simpler and faster than implementing equivalent logic in Java. However, developers need to weigh challenges such as error handling, performance, and maintainability. Capturing and handling errors (standard error stream, non-zero exit codes) in Java for shell script execution requires careful design. Each script execution starts a new shell process; prolonged process occupancy can waste system performance, and debugging logic involving both Java and shell parts can be more difficult. It is necessary to ensure that the shell script's own log output can be captured or recorded in appropriate locations by Java, allowing developers to quickly locate and resolve problems when they arise.

[0058] In distributed systems, the execution time of shell commands is dynamically affected by factors such as network conditions, load, and data volume. Fixed timeout mechanisms in related technologies (such as setting it to 30 seconds) have serious flaws. Under low load, a command may complete within 10 seconds, but under high load or with large data volumes, it may take 60 seconds, and a 30-second timeout can lead to the command being mistakenly terminated. Furthermore, in high-concurrency scenarios, system resources (CPU, memory, I / O) may be quickly exhausted, causing all commands to fail. Circuit breaking mechanisms in related technologies (such as Hystrix) treat all requests equally, failing to distinguish between core and non-core business logic, potentially leading to the disruption of critical business processes.

[0059] A circuit breaker method has been proposed in related technologies. This method uses a filter to limit the rate of a service request in the system to the target service, and obtains the load data of the target server in real time (such as CPU, memory, response time, etc.). When the target service reaches a user-defined threshold or a threshold set by the device, the circuit breaker is triggered. At the same time, the second service affected by the first service is probed. If it exceeds the threshold, it is downgraded and rate-limited. The second service is continuously probed. When it returns to normal, the downgrade is canceled. However, the threshold judgment mechanism of this method is rigid. Fixed thresholds cannot adapt to the dynamic nature of command execution. Some fixed timeout thresholds (such as 30 seconds) cannot adapt to the dynamic nature of command execution. In sparse request scenarios, a single slow request can trigger the circuit breaker. There is no historical adaptive capability. The threshold cannot be dynamically adjusted according to historical execution. During high-traffic periods, the circuit breaker is easily triggered by sudden traffic. During low-traffic periods, it is overly conservative.

[0060] To address the aforementioned problems, and in conjunction with the above embodiments and optional embodiments, the present invention proposes an optional implementation method. Figure 2 This is a flowchart of an optional circuit breaker method according to an embodiment of the present invention, such as... Figure 2 As shown, when an open system needs to execute shell commands, it first obtains standardized commands through a normalization engine. Using these standardized commands as the primary key, it queries the database to retrieve all historical execution time queues. The retrieved values ​​are then placed into a circular FIFO queue, and the mean of the time series is calculated. ) and standard deviation ( Based on the principle of normal distribution, the timeout period is calculated as follows: Then, the command is executed. If the execution time exceeds the timeout period, circuit breaker processing is triggered, invoking a tiered circuit breaker mechanism. Based on the priority level and resource monitoring, a decision is made regarding whether to process the command through circuit breaker, downgrade processing, or leave it unprocessed. If downgrade processing is chosen, the command is paused and placed in a cache queue. Once resource monitoring detects normal operation, the downgraded command is resumed. The specific implementation process of this method is as follows:

[0061] S1, Dynamic Timeout Prediction Figure 3 This is an optional dynamic timeout prediction flowchart according to an embodiment of the present invention, such as... Figure 3 As shown, it specifically includes:

[0062] S11, Fingerprint Generation, standardizes the input shell commands, ignoring variable arguments (such as file paths, timestamps, etc.). (Example: The command `grep "error" / nas / log / pod_20250701.log` is normalized to `grep "error" / nas / log / pod_`.) .log`).

[0063] S12, Historical data storage, maintains a fixed-size circular queue (e.g., capacity 100) for each command type, and uses a sliding window to calculate the actual execution time of the last 100 executions. Data structures such as Map are used. <String, CircularFifoQueue <long>>, where the key is the command type and the value is the historical execution time queue.

[0064] S13, Dynamic Timeout Calculation (Statistical Calculation): Based on the central limit principle in mathematics, when the number of independent random variables is sufficiently large, regardless of the original variable distribution, the distribution of their sum approximately follows a normal distribution. Since the execution time of a command is the sum of a large number of independent random variables, the execution time of a given command follows a normal distribution. In practical applications, the standardized command is used as the primary key to retrieve historical execution time series from the database. The mean of the time series is calculated (…). ) and standard deviation ( In a normal distribution, approximately 99.73% of the data will fall within the range of the mean plus or minus 3 standard deviations, so the timeout threshold is set as follows: K is a configurable parameter, which is set to 3 by default. When there are too many timeouts and the skewness is greater than 1, it will be adaptively adjusted to 4.

[0065] S14, Command Execution with Timeout: When executing a command, the calculated dynamic timeout value is used as the timeout threshold for this execution. If the command is not completed within the timeout period, the tiered circuit breaker decision is invoked, and the command is marked as timed out.

[0066] S15, Feedback Loop: Regardless of whether the command succeeds or fails, the actual execution time (if no timeout) or timeout time (if timeout) of this execution will be updated to the database so that the threshold can be calculated in the next sliding window retrieval.

[0067] S2, Tiered Circuit Breaker Decision Figure 4 This is an optional tiered circuit breaker decision-making flowchart according to an embodiment of the present invention, such as... Figure 4 As shown, it specifically includes:

[0068] S21, Resource Monitoring, collects key system resource indicators (i.e., system resource status) in real time, which may include, but is not limited to, CPU utilization (%), memory utilization (%), slow request rate (%), etc. Among them, the slow request rate refers to the proportion of requests whose response time exceeds a preset threshold (i.e., "slow") when the system or service processes requests within a certain time window.

[0069] S22, Circuit Breaker Policy Configuration: Configure the business priority (0.1-1.0) for each type of command, with higher values ​​indicating higher priority (e.g., payment service = 1.0, log cleanup = 0.3). The corresponding relationships of the circuit breaker system resource rule base are shown in Table 1 below:

[0070] Table 1

[0071]

[0072] S23, Circuit Breaker Decision Making Execution, specifically includes: triggering the circuit breaker strategy when resource metrics exceed thresholds.

[0073] Execute immediately: Core commands (priority ≥ 0.8) continue execution.

[0074] Delayed execution: Non-core commands (0.3 < priority < 0.8) are added to the delay queue and wait for resources to be released.

[0075] Execution denied: Low-priority commands (priority ≤ 0.3) are rejected outright.

[0076] Set the second threshold to a fixed (larger) value. When the execution time of a core command exceeds the second threshold, the command will be directly circuit-broken.

[0077] S24, Circuit Breaker Recovery: Once resource metrics return to normal, the gradual recovery command performs the following operations:

[0078] S241 initially restores 10% of the traffic, and subsequently releases 10% of the traffic every five seconds, while monitoring resource metrics in real time.

[0079] S242, after the success rate remains above 90%, restores 100% traffic.

[0080] It should be noted that this embodiment proposes a dynamic timeout prediction model based on historical execution data when calling shell commands in an open system. Its core idea is to adaptively predict the timeout threshold for the next execution by statistically analyzing historical execution times, and proposes a tiered circuit breaker and degradation strategy. Based on the calculated timeout threshold combined with the system resource status and the business priority of the command, the circuit breaker strategy and degradation action are dynamically determined. Ultimately, this solves the technical problems in related technologies, such as high failure rate of core commands and system avalanche when resources are overloaded, caused by fixed timeouts in the circuit breaker processing method.

[0081] It should be noted that the method in this embodiment uses a combination of dynamic timeout prediction and tiered circuit breaker degradation techniques to adaptively adjust the timeout threshold and detect system load for resource overload protection. One advantage is mathematical precision. Command execution time is affected by multiple factors (CPU contention / IO blocking / network jitter), and its distribution conforms to the central limit theorem; historical data converges to a normal distribution. Fixed timeout thresholds cannot cover volatility (such as long-tail data). Therefore, based on statistical analysis of real-time updated historical data, according to the normal distribution... The principle is to adaptively adjust the timeout threshold, theoretically achieving 99.73% coverage, ultimately reducing the false timeout rate and resolving the resource waste and false positive issues of fixed timeout mechanisms. A second advantage is system-level stability. Traditional circuit breaker strategies indiscriminately reject requests when the system is overloaded, leading to revenue loss from core businesses. However, financial businesses have inherent priorities (payment > query > log). Therefore, this embodiment combines system resource status and business priorities to implement a refined circuit breaker strategy, ensuring high availability for core businesses and degrading non-core businesses to release resources. The delay queue provides peak load clipping capabilities, reducing CPU load and memory fragmentation during peak periods. Finally, automatic recovery from circuit breaker states enhances the system's self-healing capabilities.

[0082] This embodiment also provides a fuse-breaking device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the terms "module" and "device" can refer to a combination of software and / or hardware that performs a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0083] According to an embodiment of the present invention, an apparatus embodiment for implementing the above-described fuse-breaking method is also provided. Figure 5 This is a schematic diagram of a fuse-breaking device according to an embodiment of the present invention, as shown below. Figure 5 As shown, the aforementioned circuit breaker processing device includes: a historical execution duration acquisition module 500, a timeout threshold determination module 502, an information acquisition module 504, and a strategy determination module 506, wherein:

[0084] The historical execution duration acquisition module 500 is used to acquire the historical execution duration of multiple commands in the development system within a historical time period. Among them, the multiple commands are commands of the same type as the target command, and the historical time period is a time period with a predetermined duration before the current time.

[0085] The timeout threshold determination module 502 is connected to the historical execution duration acquisition module 500 and is used to determine the target timeout threshold based on the historical execution duration of each of the multiple commands.

[0086] The information acquisition module 504 is connected to the timeout threshold determination module 502 and is used to acquire the task priority and system resource status corresponding to the target command when the execution time of the target command exceeds the target timeout threshold.

[0087] The strategy determination module 506, connected to the information acquisition module 504, is used to determine the circuit breaker processing strategy for the target command based on task priority and system resource status.

[0088] It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0089] It should be noted that the aforementioned historical execution duration acquisition module 500, timeout threshold determination module 502, information acquisition module 504, and strategy determination module 506 correspond to steps S102 to S108 in the embodiments. The instances and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules, as part of the device, can run on a computer terminal.

[0090] It should be noted that the optional or preferred implementation methods of this embodiment can be found in the relevant descriptions in the embodiments, and will not be repeated here.

[0091] The aforementioned circuit breaker processing device may also include a processor and a memory. The aforementioned historical execution duration acquisition module 500, timeout threshold determination module 502, information acquisition module 504, strategy determination module 506, etc., are all stored in the memory as program modules, and the processor executes the aforementioned program modules stored in the memory to realize the corresponding functions.

[0092] The processor contains a core that retrieves the corresponding program modules from memory. One or more cores may be configured. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory includes at least one memory chip.

[0093] According to an embodiment of this application, an embodiment of a non-volatile storage medium is also provided. Optionally, in this embodiment, the non-volatile storage medium includes a stored program, wherein, when the program is running, it controls the device where the non-volatile storage medium is located to execute any of the aforementioned circuit breaker methods.

[0094] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals, and the non-volatile storage medium includes stored programs.

[0095] Optionally, a program that controls the device containing the non-volatile storage medium to execute any of the above-mentioned fuse-breaking method steps during program execution.

[0096] According to an embodiment of this application, an embodiment of a processor is also provided. Optionally, in this embodiment, the processor is used to run a program, wherein the program executes any of the circuit breaker methods described above.

[0097] According to an embodiment of this application, an embodiment of a computer program product is also provided, which, when executed on a data processing device, is adapted to execute a program that initializes any of the above-described circuit breaker processing method steps.

[0098] This invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of any of the above-described circuit breaker processing methods.

[0099] The order of the above embodiments of the present invention is merely for description and does not represent the superiority or inferiority of the embodiments.

[0100] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0101] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of modules described above can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between modules, and may be electrical or other forms.

[0102] The modules described above as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0103] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0104] If the aforementioned integrated modules are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable non-volatile storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a non-volatile storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned non-volatile storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0105] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / long>

Claims

1. A method of fusing processing, characterized by, The method comprises: obtaining historical execution time lengths of a plurality of commands corresponding to a target command in a historical period, wherein the plurality of commands are commands of the same type as the target command, and the historical period is a period of a predetermined length before the current time; determining a target timeout threshold based on the historical execution time lengths of the plurality of commands; in the case where the execution time length of the target command exceeds the target timeout threshold, obtaining a task priority corresponding to the target command and a system resource state; determining a fuse processing strategy for the target command based on the task priority and the system resource state.

2. The method of claim 1, wherein, The method comprises: normalizing the target command to obtain a normalized command; determining a command type corresponding to the normalized command; determining the plurality of commands and the historical execution time lengths of the plurality of commands based on the command type.

3. The method of claim 1, wherein, The method comprises: determining the average value and the standard deviation of the historical execution time lengths of the plurality of commands; Based on the average value and the standard deviation, the timeout threshold is determined by: wherein timeout represents the target timeout threshold, represents the average value, represents the standard deviation, is a normal distribution multiplier factor.

4. The method of claim 3, wherein, before determining the target timeout threshold based on the historical execution time lengths of the plurality of commands, the method further comprises: determining a timeout command proportion in the plurality of commands based on the historical execution time lengths of the plurality of commands and the corresponding timeout thresholds, wherein the timeout command proportion represents the proportion of the number of commands in the plurality of commands whose historical execution time lengths exceed the corresponding timeout thresholds to the total number of the plurality of commands; determining the normal distribution multiple factor based on the timeout command proportion and the task priority.

5. The method according to any one of claims 1 to 4, characterized in that, The method comprises: in the case where the system resource state exceeds a preset occupancy threshold and the task priority is a first priority, determining that the fuse processing strategy is to continue executing the target command; or in the case where the system resource state exceeds the preset occupancy threshold and the task priority is a second priority, determining that the fuse processing strategy is to add the target command to a delayed execution queue; or in the case where the system resource state exceeds the preset occupancy threshold and the task priority is a third priority, determining that the fuse processing strategy is to refuse to execute the target command.

6. The method of claim 5, wherein, in the case where the system resource state exceeds the preset occupancy threshold and the task priority is the second priority, after determining the fuse processing strategy for the target command based on the task priority and the system resource state, the method further comprises: in the case where the system resource state is lower than the preset occupancy threshold, executing the commands in the delayed execution queue in order according to the order in which the commands are added to the delayed execution queue, wherein the system resource state is kept lower than the preset occupancy threshold during the execution of the commands in the delayed execution queue.

7. The method of claim 5, wherein, In a case where the system resource state exceeds the preset occupation threshold and the task priority is the second priority, after the determination of the fuse processing strategy of the target command based on the task priority and the system resource state, the method further includes: In a case where the system resource state is lower than the preset occupation threshold, the commands in the delay execution queue are executed in the order of being added to the delay execution queue, and every predetermined time length, a predetermined proportion of the commands in the delay execution queue are executed; In a case where the execution success rate of the predetermined proportion of the commands is greater than a preset proportion for a continuous predetermined number of times, the remaining commands in the delay execution queue are executed.

8. A fusing processing apparatus characterized by comprising: Comprise: a historical execution time length acquisition module configured to acquire historical execution time lengths of a plurality of commands corresponding to each of the plurality of commands in a historical period, wherein the plurality of commands are commands of the same type as a target command, and the historical period is a period of a predetermined length before a current time; a timeout threshold determination module configured to determine a target timeout threshold based on the historical execution time lengths of the plurality of commands corresponding to each of the plurality of commands; an information acquisition module configured to acquire a task priority corresponding to the target command and a system resource state in a case where an execution time length of the target command exceeds the target timeout threshold; a strategy determination module configured to determine a fuse processing strategy of the target command based on the task priority and the system resource state.

9. A non-volatile storage medium, comprising: The non-volatile storage medium stores a plurality of instructions, and the instructions are adapted to be loaded and executed by the processor to implement the fuse processing method of any one of claims 1 to 7.

10. An electronic device, comprising: Comprise one or more processors and a memory, the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the fuse processing method of any one of claims 1 to 7.

Images