A cluster service process exception handling method, device and medium thereof

Abstract

The present application discloses a cluster service process exception handling method, device and medium thereof, which relate to the field of computer technology and are used for fault monitoring and exception handling of service threads. In view of the problem that the current method of only issuing alarms for exceptions and relying on manual responses easily causes system jamming and blocking, a cluster service process exception handling method is provided. By obtaining resource consumption information, business pressure information and request response time of the service process, it is determined whether the current service process has a fault, and the fault level information is determined according to the severity of the fault, so that corresponding restriction measures can be taken according to the fault level, so that when a service process fails, the fault problem can be handled in time, avoiding the response lag caused by waiting for manual response, which leads to request jamming and blocking, and even affects the implementation of other functions of the cluster and the overall performance.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a cluster service process exception handling method, device, and medium thereof. Background Art

[0002] With the rapid development of cloud computing and big data technology in modern society, the means of production data accumulated in production and life has also grown exponentially, and massive storage technology has become an increasingly indispensable part of the field of Internet technology.

[0003] Currently, distributed storage systems, due to the need to monitor and manage massive amounts of data, typically only issue fault alerts for critical information or failures. However, this current approach requires manual response. If operations personnel fail to respond promptly, certain functions of the distributed storage system may remain faulty for extended periods, potentially causing requests to become stuck or blocked, and even impacting other cluster functions and overall performance, causing immeasurable losses to users.

[0004] Therefore, technicians in this field are in urgent need of a cluster service process exception handling method to solve the problem that the current method of only issuing alarms for exceptions and relying on manual responses can easily cause system freezes and blockages. Summary of the Invention

[0005] The purpose of this application is to provide a cluster service process exception handling method, device and medium thereof to solve the problem that the current method of only issuing alarms for exceptions and relying on manual response can easily cause system jamming and blocking.

[0006] To solve the above technical problems, the present application provides a cluster service process exception handling method, including:

[0007] Obtain resource consumption information, business pressure information, and request response time of the service process;

[0008] Determine whether a service process has failed based on resource consumption information, business pressure information, and request response time. If a failure occurs, determine the fault level.

[0009] Restriction operations are performed on the service process according to the fault level information; the restriction operations include: limiting the input flow of the service process, stopping the operation of the faulty functional module, and stopping the operation of the service process.

[0010] Preferably, determining the fault level information based on resource consumption information, business pressure information, and request response time includes:

[0011] When any of the resource consumption information, business pressure information, and request response time exceeds the corresponding preset threshold, the corresponding functional module is determined to be faulty, and the module type of the faulty functional module is obtained;

[0012] Determine the fault level information based on the module type.

[0013] Preferably, the module types are divided into four importance levels: first importance, second importance, third importance, and fourth importance, and the importance of the module types is increased in sequence. The fault level information is determined based on the resource consumption information, the business pressure information, and the request response time, including:

[0014] When the module type of the functional module corresponds to the first importance, the fault level information is the first fault level;

[0015] When the module type of the functional module corresponds to the second importance, the fault level information is the second fault level;

[0016] When the module type of the functional module corresponds to the third importance, the fault level information is the third fault level;

[0017] When the module type of the functional module corresponds to the fourth importance, the fault level information is the fourth fault level;

[0018] Among them, the fault degrees represented by the first fault level, the second fault level, the third fault level and the fourth fault level increase in sequence.

[0019] Preferably, determining the fault level information based on resource consumption information, business pressure information, and request response time includes:

[0020] When any of the resource consumption information, business pressure information, and request response time exceeds the corresponding first preset threshold and does not exceed the second preset threshold, the fault level information is the first fault level;

[0021] When any of the resource consumption information, business pressure information, and request response time exceeds the corresponding second preset threshold and does not exceed the third preset threshold, the fault level information is the second fault level;

[0022] When any of the resource consumption information, business pressure information, and request response time exceeds the corresponding third preset threshold and does not exceed the fourth preset threshold, the fault level information is the third fault level;

[0023] When any one of the resource consumption information, business pressure information, and request response time exceeds the corresponding fourth preset threshold, the fault level information is the fourth fault level;

[0024] Among them, the fault degrees represented by the first fault level, the second fault level, the third fault level and the fourth fault level increase in sequence.

[0025] Preferably, performing a restriction operation on the service process according to the fault level information includes:

[0026] When the fault level information is the first fault level, an alarm message is returned;

[0027] When the fault level information is the second fault level, limiting the input flow of the service process;

[0028] When the fault level information is the third fault level, the service process is stopped from running the function module of the fault;

[0029] When the fault level information is the fourth fault level, the service process is stopped.

[0030] Preferably, the method further includes: when the fault level information changes, canceling the corresponding restriction operation.

[0031] Preferably, there are multiple fault level information;

[0032] Correspondingly, when the fault level information changes, the corresponding restriction operations are canceled including:

[0033] When the fault level information changes, only the restriction operation corresponding to the current fault level information is canceled.

[0034] To solve the above technical problems, the present application further provides a cluster service process exception handling device, comprising:

[0035] The acquisition module is used to obtain resource consumption information, business pressure information and request response time of the service process;

[0036] The fault judgment module is used to judge whether the service process has a fault based on resource consumption information, business pressure information and request response time, and determine the fault level information if a fault occurs;

[0037] The fault handling module is used to perform restriction operations on the service process according to the fault level information; the restriction operations include: limiting the input flow of the service process, stopping the operation of the faulty functional module, and stopping the operation of the service process.

[0038] Preferably, it also includes:

[0039] The fault recovery module is used to cancel the corresponding restriction operation when the fault level information changes.

[0040] To solve the above technical problems, the present application further provides a cluster service process exception handling device, comprising:

[0041] memory for storing computer programs;

[0042] The processor is configured to implement the steps of the above-mentioned cluster service process exception handling method when executing a computer program.

[0043] To solve the above technical problems, the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned cluster service process exception handling method are implemented.

[0044] The present application provides a cluster service process exception handling method, which determines whether the current service process has a fault by obtaining resource consumption information, business pressure information and request response time of each module in the service process, and determines the fault level information according to the severity of the fault, so as to take corresponding restriction measures according to the fault level. The restriction measures include limiting the input flow of the service process, stopping the operation of the faulty functional module and stopping the operation of the service process, etc., which are adapted to the different levels of faults that may occur in the service process. Therefore, when a service process fails, the corresponding restriction operation can be executed according to the fault level information to handle the fault problem in time, avoiding the response delay caused by waiting for manual response, which may lead to request stuck and blocked, and even affect the implementation of other functions of the cluster and the overall performance, thereby avoiding immeasurable losses to users.

[0045] The cluster service process exception handling device and computer-readable storage medium provided in this application correspond to the above method and have the same effects as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0047] Figure 1 A flow chart of a cluster service process exception handling method provided by the present invention;

[0048] Figure 2 A structural diagram of a cluster service process exception handling device provided by the present invention;

[0049] Figure 3 This is a structural diagram of another cluster service process exception handling device provided by the present invention. DETAILED DESCRIPTION

[0050] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0051] The core of this application is to provide a cluster service process exception handling method, device and medium thereof.

[0052] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0053] Current distributed storage systems monitor the working status of service processes and issue alerts when a service process anomaly occurs. When a service process anomaly is detected, an alert is sent to operations and maintenance personnel, allowing them to identify the service process's fault status and implement targeted solutions to restore the process to normal operation. However, since these repairs are performed manually, they inevitably experience delays due to human factors. If operations and maintenance personnel fail to respond to the failure and take appropriate measures in a timely manner, certain service functions in the distributed storage system may remain in a faulty state for an extended period of time, further causing request jams and blocking, and even impacting other cluster functions and overall performance, causing immeasurable losses to users.

[0054] To solve the above problems, Figure 1 As shown, the present application provides a cluster service process exception handling method, including:

[0055] S11: Obtain resource consumption information, business pressure information, and request response time of each service process.

[0056] It's easy to understand that a service process doesn't necessarily implement just one function; it may consist of multiple functional modules that jointly implement the supported functions. The operating status of each functional module determines the operating status of the service process. Failures in some functional modules may render some of the functions provided by the service process unavailable, while failures in other functional modules may render the entire service process unavailable. The operating status of the service process can be determined by determining whether each functional module within the service process is abnormal.

[0057] When a functional module provides functionality, it consumes certain resources. These resources can be storage space, threads, and so on, though this application does not impose any restrictions on this. The amount of resources consumed by a functional module reflects its operating status to a certain extent. When a functional module is operating normally, its resource consumption remains within a stable range. Exceeding this range indicates that the functional module may be malfunctioning. The resource consumption information described above is data reflecting the current resource consumption of the functional module. This can be implemented using existing monitoring threads and other methods, and this embodiment will not elaborate on this in detail.

[0058] Similarly, the above-mentioned business pressure information is information reflecting the current pressure situation of the functional module, and may include data such as the amount of request traffic sent to the functional module. The business pressure of a normally functioning functional module will also be maintained within a stable range.

[0059] The request response time mentioned above is the time required for the request to be sent to the functional module and then for the functional module to respond to the request. It can reflect the response capability of the functional module to a certain extent. When an abnormality occurs in the functional module, its response capability may be significantly weakened. Therefore, the fault status can be roughly judged by the request response time of the functional module.

[0060] S12: Determine whether a service process fails based on resource consumption information, business pressure information, and request response time. If a failure occurs, determine the failure level information.

[0061] As can be seen above, resource consumption information, business pressure information, and request response time reflect the working status of each functional module in the service process from three perspectives. This information can then be used to determine whether the service process has experienced an anomaly and the severity of the anomaly. In practical applications, operations and maintenance personnel can customize the fault level of service process anomalies to reflect the varying severity of the service process failure, facilitating the subsequent implementation of different control measures.

[0062] S13: Execute restriction operations on the service process according to the fault level information.

[0063] The restriction operations include: limiting the input flow of the service process, stopping the operation of the faulty functional module, and stopping the operation of the service process.

[0064] The restriction operations mentioned in this application include, but are not limited to: limiting the input flow of the service process, stopping the operation of the faulty functional module, and stopping the operation of the service process. It is easy to understand that the restriction operations do not necessarily include all three of the above, but can include any of the above three, depending on the fault level classification customized by the operation and maintenance personnel.

[0065] In addition, the above-mentioned restriction operations target respectively increasing levels of fault severity: limiting the input traffic of the service process indicates that the current service process can still provide functional implementation, but if the request traffic is still too high, it may cause more serious faults; stopping the operation of the faulty functional module indicates that there is a functional module fault and the corresponding function cannot be provided, affecting the implementation of some functions of the service process; stopping the operation of the service process means that the key functional modules in the service process are disabled or all modules are disabled, all functions cannot be implemented, and services cannot be continued, indicating that the service process is at the most serious level of fault.

[0066] In one possible application scenario, the operation and maintenance personnel customize three fault levels, representing increasing fault severity. Limiting the input traffic of the service process corresponds to the lowest fault level, stopping the operation of the faulty functional module corresponds to a moderate fault level, and stopping the service process corresponds to the highest fault level.

[0067] The present application provides a cluster service process exception handling method, which determines the fault level of the current service process by obtaining resource consumption information, business pressure information and request response time of each functional module of the service process, and takes restrictive operations including limiting the input flow of the service process, stopping the operation of the faulty functional module and stopping the operation of the service process, so as to respond in time when a fault occurs and process the service thread, avoiding the traditional method of waiting for manual response, which may cause the overall cluster request to be blocked and timed out or even paralyzed due to delays, thereby ensuring the security and stability of cluster operation.

[0068] Furthermore, regarding how to determine the fault level of the current service process based on resource consumption information, business pressure information, and request response time, this embodiment provides a preferred specific implementation scheme, including:

[0069] S121: When any one of the resource consumption information, the service pressure information, and the request response time exceeds a corresponding preset threshold, a corresponding functional module failure is determined, and a module type of the failed functional module is obtained.

[0070] From the above, it can be seen that when the functional modules in the service process are in normal working state, whether it is resource consumption information, business pressure information or request response time, they will be maintained within a stable range. Taking into account the situation where no request is input to the service process, it is preferred to judge whether each functional module is faulty based on whether it exceeds the corresponding preset threshold.

[0071] S122: Determine the fault level information according to the module type.

[0072] It is easy to understand that the importance of the multiple functional modules included in the service process is not the same. There are some key functional modules. When these functional modules are damaged, they will affect the normal operation of the entire service process and even cause the entire service process to stop running.

[0073] Therefore, further, this embodiment also provides a preferred implementation scheme, where the module type corresponds to four importance levels: first importance, second importance, third importance, and fourth importance, and the importance of the module type increases in sequence. The above step S122 is specifically as follows:

[0074] When the module type of the functional module corresponds to the first importance, the fault level information is the first fault level;

[0075] When the module type of the functional module corresponds to the second importance, the fault level information is the second fault level;

[0076] When the module type of the functional module corresponds to the third importance, the fault level information is the third fault level;

[0077] When the module type of the functional module corresponds to the fourth importance, the fault level information is the fourth fault level;

[0078] Among them, the fault degrees represented by the first fault level, the second fault level, the third fault level and the fourth fault level increase in sequence.

[0079] Generally speaking, in practical applications, in order to more intuitively and clearly indicate the degree of fault corresponding to the above different fault levels, minor, general, severe and fatal can be used to replace the above four fault levels.

[0080] The preferred solution provided by this embodiment enables determination of the fault level of a service process. The fault level determination method adopted by this embodiment fully considers the different roles and importance of different functional modules in a service process, thereby determining the fault level of the service process. This makes the fault level determination process more reasonable, facilitates more accurate and targeted restriction operations to be taken on the service process in the future, and better ensures the security of cluster operation.

[0081] In addition, considering that some service modules may not include multiple functional modules, or that the functional modules are completely equal and have no importance, this embodiment also provides another implementation scheme for determining the fault level of the current service process based on resource consumption information, business pressure information, and request response time, including:

[0082] When any of the resource consumption information, business pressure information, and request response time exceeds the corresponding first preset threshold and does not exceed the second preset threshold, the fault level information is the first fault level;

[0083] When any of the resource consumption information, business pressure information, and request response time exceeds the corresponding second preset threshold and does not exceed the third preset threshold, the fault level information is the second fault level;

[0084] When any of the resource consumption information, business pressure information, and request response time exceeds the corresponding third preset threshold and does not exceed the fourth preset threshold, the fault level information is the third fault level;

[0085] When any one of the resource consumption information, business pressure information, and request response time exceeds the corresponding fourth preset threshold, the fault level information is the fourth fault level;

[0086] Among them, the fault degrees represented by the first fault level, the second fault level, the third fault level and the fourth fault level increase in sequence.

[0087] As can be seen from the above embodiments, when a service process is operating normally, there is typically a stable range for resource consumption information, business pressure information, and request response time. When this range is exceeded, the service process is likely to fail. The above method uses preset thresholds for determination. However, the extent to which the threshold is exceeded reflects, to some extent, the degree of failure of the module. Therefore, this embodiment sets a first preset threshold, a second preset threshold, a third preset threshold, and a fourth preset threshold for each of the resource consumption information, business pressure information, and request response time information. As the first, second, third, and fourth preset thresholds increase in sequence, the degree of failure of the module also increases in sequence.

[0088] In one possible implementation, operations personnel set a threshold to determine whether a service process has experienced a failure. When this threshold is exceeded, the process is considered at the fourth fault level, equivalent to the fourth preset threshold. Accordingly, the first, second, and third preset thresholds are proportional to this threshold. For example, the first, second, and third preset thresholds are 30%, 50%, and 80%, respectively.

[0089] It is easy to know that this embodiment provides a method for determining the fault level for each functional module in the service process. Therefore, when the service process includes multiple functional modules, the fault level information is also multiple; the multiple fault level information of the functional modules can be subsequently combined into the fault level information of one service process; or all of them can be retained and used together as the fault level information of the service process. This embodiment does not impose any restrictions on this.

[0090] This embodiment sets multiple thresholds to determine the degree of failure of each functional module of the service process in stages, so as to determine the failure level of each functional module, and then determine the failure level of the service process. This makes up for the shortcomings of the failure level determination method provided by the above embodiment in application scenarios where the service process only includes one functional module or there is no difference in importance between the functional modules, enhances the applicability of a cluster service process exception handling method of the present application, and further ensures the security and stability of cluster operation.

[0091] As can be seen from the above embodiment, the fault level can be divided into four fault levels based on resource consumption information, business pressure information, and request response time. Accordingly, this embodiment provides a possible implementation scheme for the restriction operations taken for different fault levels. Step S13 is specifically as follows:

[0092] S131: When the fault level information is the first fault level, an alarm message is returned.

[0093] When the fault level information is the first fault level, it is generally believed that the current service process can still work normally, but there is a risk of failure. If it continues to be unprocessed or used incorrectly, it may lead to more serious failures. At this time, an alarm message is returned to inform the operation and maintenance personnel, and no restriction operations are performed.

[0094] S132: When the fault level information is the second fault level, restricting the input flow of the service process is executed on the service process.

[0095] When the fault level information is level 2, it is generally assumed that the service process can still perform its corresponding functions, but its service capability has been reduced. In this case, throttling is performed on the service process to limit the number of requests entering the service process. A prompt message is returned to some requests to inform the requester that the service thread is in a faulty state.

[0096] S133: When the fault level information is the third fault level, stopping the operation of the faulty functional module of the service process.

[0097] When the fault level information is the third fault level, it is generally believed that the service process has a serious fault, some functions cannot be implemented, and there may be a stuck or blocked phenomenon. At this time, the faulty functional module in the service thread is stopped.

[0098] S134: When the fault level information is the fourth fault level, stopping the service process.

[0099] When the fault level information is the fourth fault level, it is generally believed that the service process has a very serious fault. Continuing to run it is likely to cause the entire service process to be stuck or blocked, and all functions of the service process cannot be implemented. In this case, the entire service process is stopped.

[0100] This embodiment provides a preferred solution that, based on the above embodiments, adopts different restriction measures for each different fault level, so that when a service thread fails, it can be responded to and processed promptly and accurately, avoiding the cluster's overall request blocking timeout or even paralysis due to untimely response or incorrect processing, thereby ensuring the safe and stable operation of the cluster.

[0101] In addition, after the service thread is diagnosed for faults according to the preferred solution provided in the above embodiment and corresponding restriction measures are taken according to the fault level, such as Figure 1 As shown, this embodiment also provides a preferred implementation scheme, wherein the above method further comprises:

[0102] S14: When the fault level information changes, the corresponding restriction operation is canceled.

[0103] For example, if a service thread has fault level information of level 3, then according to the preferred solution of the above embodiment, a restriction operation should be executed to stop the operation of the faulty functional module. However, after the operation and maintenance personnel have eliminated the corresponding fault, the fault level information may be canceled or downgraded. For example, if the fault level is downgraded to level 2, the fault level information has changed, and the restriction operation to stop the operation of the faulty functional module should be canceled. Since the fault level information of level 2 has been added compared to the original fault level, according to the above embodiment, the input flow of the service process should be restricted.

[0104] In addition, it can be seen from the above embodiment that the fault level information of a service thread may not be unique. Accordingly, when there are multiple pieces of fault level information, step S14 of the above embodiment is specifically as follows:

[0105] When the fault level information changes, only the restriction operation corresponding to the current fault level information is canceled.

[0106] To further illustrate the preferred solution provided by this embodiment, an exemplary application scenario is provided below for illustration:

[0107] There is a service thread including multiple modules, wherein module A has a first fault level, module B has a fourth fault level, and module C has a second fault level.

[0108] At this time, according to a cluster service process exception handling method provided in the above embodiment, the service process should return an alarm message (for module A), stop the entire service process (for module B), and limit the service process traffic (for module C).

[0109] After troubleshooting by the maintenance personnel, the faults in modules A and B are eliminated, and no new faults are generated. At this point, the service process's fault level information remains at the second fault level (module C). According to the implementation scheme provided in this embodiment, the operations of returning an alarm (module A) and stopping the entire service process (module B) should be canceled, and only the service process flow restriction (module C) should be executed.

[0110] The preferred solution provided in this embodiment provides a method for recovering a service process after a fault occurs and restriction measures are taken. For the recovered fault level information, the corresponding restriction operation is restored to ensure that the service thread can resume normal operation. At the same time, the recovery of a piece of fault level information will not cause all restriction operations to be lifted, resulting in the fault corresponding to other fault level information being released before it is repaired, thereby causing the entire cluster to be blocked or stuck.

[0111] In the above embodiment, a cluster service process exception handling method is described in detail. This application also provides a corresponding embodiment of a cluster service process exception handling device. It should be noted that this application describes the device embodiment from two perspectives: one is based on the functional module perspective, and the other is based on the hardware perspective.

[0112] Based on the perspective of functional modules, such as Figure 2 As shown, this embodiment provides a cluster service process exception handling device, including:

[0113] Acquisition module 21, used to obtain resource consumption information, business pressure information and request response time of the service process;

[0114] A fault judgment module 22 is used to judge whether a service process has a fault based on resource consumption information, business pressure information and request response time, and to determine the fault level information if a fault has occurred;

[0115] The fault processing module 23 is used to perform restriction operations on the service process according to the fault level information; the restriction operations include: limiting the input flow of the service process, stopping the operation of the faulty functional module and stopping the operation of the service process.

[0116] Preferably, it also includes:

[0117] The fault recovery module is used to cancel the corresponding restriction operation when the fault level information changes.

[0118] Since the embodiments of the apparatus part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the apparatus part, and they will not be repeated here.

[0119] The cluster service process exception handling device provided in this embodiment obtains resource consumption information, business pressure information and request response time of each functional module of the service process through an acquisition module, and then judges the fault level of the current service process through a fault judgment module. The fault handling module takes restriction operations including limiting the input flow of the service process, stopping the operation of the faulty functional module and stopping the operation of the service process, so as to achieve timely response and processing of the service thread when a fault occurs, avoiding the traditional method of waiting for manual response, which will cause the overall cluster request to be blocked and timed out or even paralyzed due to delays, thereby ensuring the safety and stability of cluster operation.

[0120] Figure 3 This is a structural diagram of a cluster service process exception handling device provided by another embodiment of the present application, such as Figure 3 As shown, a cluster service process exception handling device includes: a memory 30 for storing computer programs;

[0121] The processor 31 is configured to implement the steps of a cluster service process exception handling method according to the above embodiment when executing a computer program.

[0122] The cluster service process exception handling device provided in this embodiment may include but is not limited to a server, a computer, or a workstation.

[0123] Among them, the processor 31 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 31 can be implemented in at least one hardware form of a digital signal processor (DSP), a field programmable gate array (FPGA), and a programmable logic array (PLA). The processor 31 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 31 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 31 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0124] The memory 30 may include one or more computer-readable storage media, which may be non-transitory. The memory 30 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 30 is at least used to store the following computer program 301, wherein, after the computer program is loaded and executed by the processor 31, it can implement the relevant steps of a cluster service process exception handling method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 30 may also include an operating system 302 and data 303, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 302 may include Windows, Unix, Linux, etc. The data 303 may include but is not limited to a cluster service process exception handling method, etc.

[0125] In some embodiments, a cluster service process exception handling device may further include a display screen 32 , an input / output interface 33 , a communication interface 34 , a power supply 35 , and a communication bus 36 .

[0126] Those skilled in the art will understand that Figure 3 The structure shown in the figure does not constitute a limitation on a cluster service process exception handling device, and may include more or fewer components than shown in the figure.

[0127] An embodiment of the present application provides a cluster service process exception handling device, including a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a cluster service process exception handling method.

[0128] A cluster service process exception handling device provided in this embodiment executes a computer program stored in a memory through a processor to obtain resource consumption information, business pressure information and request response time of each functional module of the service process, and then judges the fault level of the current service process, and takes restriction operations including limiting the input traffic of the service process, stopping the operation of the faulty functional module and stopping the operation of the service process, so as to achieve timely response when a fault occurs and process the service thread, avoiding the traditional method of waiting for manual response, which may cause the overall cluster request to be blocked and timed out or even paralyzed due to delays, thereby ensuring the security and stability of cluster operation.

[0129] Finally, the present application also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiment.

[0130] It is understandable that if the method in the above embodiment is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, 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, which is stored in a storage medium and executes all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0131] The computer-readable storage medium provided in this embodiment can, when the computer program stored therein is executed, obtain resource consumption information, business pressure information and request response time of each functional module of the service process, and then determine the fault level of the current service process. It can also take restrictive actions including limiting the input traffic of the service process, stopping the operation of the faulty functional module, and stopping the operation of the service process, so as to achieve timely response and process the service thread when a fault occurs, avoiding the traditional method of waiting for manual response, which may cause the entire cluster request to be blocked and timed out or even paralyzed due to delays, thereby ensuring the security and stability of cluster operation.

[0132] The above is a detailed introduction to a cluster service process exception handling method, device and medium provided by the present application. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of this application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

[0133] It should also be noted that, in this specification, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus comprising the element.

Claims

1. A cluster service process exception handling method, characterized in that: include: Obtain resource consumption information, business pressure information, and request response time for each functional module of the service process; Determining whether a fault occurs in the service process based on the resource consumption information, the business pressure information, and the request response time, and determining fault level information if a fault occurs; performing a restriction operation on the service process according to the fault level information; The restriction operation includes: limiting the input flow of the service process, stopping the operation of the faulty functional module and stopping the operation of the service process; Among them, the fault level information includes: the fault level with the lowest fault degree, the fault level with a moderate fault degree and the fault level with the highest fault degree; the fault level with the lowest fault degree corresponds to the restriction operation of limiting the input flow of the service process, the fault level with a moderate fault degree corresponds to the restriction operation of stopping the operation of the faulty functional module, and the fault level with the highest fault degree corresponds to the restriction operation of stopping the operation of the service process.

2. The cluster service process exception handling method according to claim 1, characterized in that: Determining the fault level information according to the resource consumption information, the business pressure information, and the request response time includes: When any one of the resource consumption information, the business pressure information, and the request response time exceeds a corresponding preset threshold, determining that the corresponding functional module is faulty, and obtaining a module type of the faulty functional module; The fault level information is determined according to the module type.

3. The cluster service process exception handling method according to claim 2, characterized in that: The module type corresponds to four importance levels of first importance, second importance, third importance, and fourth importance, and the importance of the module type increases in sequence. The fault level information is determined based on the resource consumption information, the business pressure information, and the request response time, including: When the module type of the functional module corresponds to the first importance, the fault level information is a first fault level; wherein the first fault level corresponds to a fault level in which the service process is still operating normally but has a fault risk; When the module type of the functional module corresponds to the second importance, the fault level information is a second fault level; wherein the second fault level corresponds to the fault level with the lowest fault severity; When the module type of the functional module corresponds to the third importance, the fault level information is a third fault level; wherein the third fault level corresponds to the fault level of moderate fault severity; When the module type of the functional module corresponds to the fourth importance, the fault level information is a fourth fault level; wherein the fourth fault level corresponds to the fault level with the highest fault severity.

4. The cluster service process exception handling method according to claim 1, characterized in that: Determining the fault level information according to the resource consumption information, the business pressure information, and the request response time includes: When any of the resource consumption information, the service pressure information, and the request response time exceeds a corresponding first preset threshold and does not exceed a second preset threshold, the fault level information is a first fault level; wherein the first fault level corresponds to a fault level in which the service process is still operating normally but has a risk of failure; When any of the resource consumption information, the business pressure information, and the request response time exceeds the corresponding second preset threshold and does not exceed the third preset threshold, the fault level information is a second fault level; wherein the second fault level corresponds to the fault level with the lowest fault severity; When any one of the resource consumption information, the service pressure information, and the request response time exceeds a corresponding third preset threshold and does not exceed a fourth preset threshold, the fault level information is a third fault level; wherein the third fault level corresponds to a fault level of moderate severity; When any one of the resource consumption information, the business pressure information, and the request response time exceeds a corresponding fourth preset threshold, the fault level information is a fourth fault level; wherein the fourth fault level corresponds to the fault level with the highest fault severity.

5. The cluster service process exception handling method according to claim 3 or 4, characterized in that: Performing a restriction operation on the service process according to the fault level information further includes: When the fault level information is the first fault level, an alarm message is returned.

6. The cluster service process exception handling method according to claim 1, characterized in that: Also includes: When the fault level information changes, the corresponding restriction operation is canceled.

7. The cluster service process exception handling method according to claim 6, characterized in that: When the fault level information changes, canceling the corresponding restriction operation includes: When the fault level information changes, only the restriction operation corresponding to the current fault level information is canceled.

8. A cluster service process exception handling device, characterized in that: include: The acquisition module is used to obtain resource consumption information, business pressure information and request response time of each functional module of the service process; a fault judgment module, configured to judge whether a fault occurs in the service process based on the resource consumption information, the business pressure information, and the request response time, and to determine fault level information if a fault occurs; a fault processing module, configured to perform a restriction operation on the service process according to the fault level information; The restriction operation includes: limiting the input flow of the service process, stopping the operation of the faulty functional module and stopping the operation of the service process; Among them, the fault level information includes: the fault level with the lowest fault degree, the fault level with a moderate fault degree and the fault level with the highest fault degree; the fault level with the lowest fault degree corresponds to the restriction operation of limiting the input flow of the service process, the fault level with a moderate fault degree corresponds to the restriction operation of stopping the operation of the faulty functional module, and the fault level with the highest fault degree corresponds to the restriction operation of stopping the operation of the service process.

9. A cluster service process exception handling device, characterized in that: include: memory for storing computer programs; A processor is configured to implement the steps of the cluster service process exception handling method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the cluster service process exception handling method according to any one of claims 1 to 7 are implemented.

Images