Asynchronous processing monitoring method and system and storage medium
By identifying the business method of asynchronous notifications in distributed software development and calculating the probability of retry success when its call fails, the task process impact problem caused by asynchronous notifications is solved, and the system reliability and developer task control capabilities are improved.
Patent Information
- Application Number
- CN202411213369.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-30
- Publication Date
- 2025-02-25
AI Technical Summary
In distributed software development, asynchronous notification causes the asynchronous request for other services to fail after the main process is processed successfully, affecting the overall task process, and it is difficult for developers to accurately grasp the task progress.
By traversing all business methods, identify methods that require asynchronous notifications and cache detailed information when they are called. Monitor the operation result of the method. If it fails, calculate the probability of retry success. If the probability is greater than the threshold, try again until it is successful.
It effectively reduces the failure of business methods, improves the reliability and flexibility of the system, and enables developers to better control and grasp the overall task progress.
Smart Images

Figure CN119512853A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of software development, and in particular to an asynchronous processing monitoring method, system and storage medium. Background Art
[0002] In most distributed software development scenarios, when the main process affects other related businesses, asynchronous notifications are often used to call between businesses. This ensures that when the main process succeeds, the main process performance will not be degraded due to blocking of other related businesses. However, such a design can also lead to some problems. For example, after the main process is successfully processed, other services are asynchronously requested, but other services fail to process. This will affect the progress of the overall task and make it difficult for developers to grasp the overall task progress. Summary of the invention
[0003] To achieve the above purpose and other related purposes, the present invention discloses an asynchronous processing monitoring method, comprising: Traverse all business methods and obtain the business methods that require asynchronous notification; When a business method that requires asynchronous notification is called, the detailed information corresponding to the business method is cached; Monitor the running results of the above business methods and record the running results in the cache; If the operation result is failure, call the business method again until the call succeeds.
[0004] Furthermore, the traversal of all business methods to obtain the business methods that require asynchronous notification includes: After the Spring container initializes the Bean, it traverses all methods and identifies the methods annotated with @Async; The complexity of each method annotated with @Async is analyzed, where the complexity is: C=log(1+α*P^2)+β*sqrt(L)+γ*exp(D / 10) Where: C is the complexity score, P is the number of method parameters, L is the number of method body lines, D is the number of dependent external services, α, β, γ are adjustable weight coefficients; Dynamically generate optimized aspect code based on complexity scores.
[0005] Furthermore, when a business method requiring asynchronous notification is called, caching detailed information corresponding to the business method includes: The detailed information includes class name, method name, and input parameters.
[0006] Furthermore, if the operation result is a failure, the business method is called again until the call is successful, including: Calculate the probability of successful retry of the business method, including: P=1-exp(-λ*n)*(1-q^(m / m_max)) Where: P is the probability of successful retry, λ is the learning rate, n is the number of retries, q is the impact factor of system load on success, m is the current load level, and m_max is the maximum load level; If the retry success probability is greater than the preset success probability threshold, a retry is performed, the retry process is continuously monitored, the learning rate λ is updated, and the above steps are repeated.
[0007] Further, the updating learning rate λ includes: When the retry succeeds, the learning rate is updated to λ=0.9λ; When the retry fails, the learning rate is updated to λ=1.1λ.
[0008] Furthermore, the dynamically generating optimized section code according to the complexity score includes: Preset complexity score ranges and use different aspect codes to process business methods in different complexity ranges.
[0009] In another aspect, the present invention provides an asynchronous processing monitoring system, comprising: The acquisition module is used to traverse all business methods and obtain the business methods that require asynchronous notification; A processing module, used for caching detailed information corresponding to a business method requiring asynchronous notification when the business method is called; The monitoring module is used to monitor the running results of the above business methods and record the running results in the cache; if the running result is failure, the business method is called again until the call is successful.
[0010] On the other hand, the present invention provides a computer-readable storage medium having a computer program stored thereon, which implements the above-mentioned method when executed by a processor.
[0011] By adopting the above technical solution, all business methods are first traversed to screen business methods that require asynchronous notification, and then the running results of the above business methods are monitored. When it is detected that the execution of a business method fails, the probability of successful retry of the business method is first calculated. If the probability of successful retry is greater than the preset success probability threshold, the business method is re-called for execution, and the retry process of the business method is continuously monitored. This method can retry failed business methods with high retry success rates, reduce the occurrence of business method failures, and dynamically update the retry success rate based on the results of each retry, and perform dynamic judgments, which further improves the flexibility of the system and is beneficial for developers to control and grasp the overall task. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. The accompanying drawings are used to better understand the present solution and do not constitute a limitation of the present disclosure. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, among which:
[0013] Figure 1 The present invention is a flowchart of an asynchronous processing monitoring method. DETAILED DESCRIPTION
[0014] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.
[0015] Reference Figure 1 , an embodiment of the present invention provides an asynchronous processing monitoring method, comprising the following steps: S1: Traverse all business methods and obtain the business methods that require asynchronous notification; Specifically, the following steps are included: S11: After the Spring container initializes the Bean, it traverses all methods and identifies the methods annotated with @Async; S12: Perform complexity analysis on each method annotated with @Async, where the complexity is: C=log(1+α*P^2)+β*sqrt(L)+γ*exp(D / 10) Wherein: C is the complexity score, P is the number of method parameters, L is the number of method body lines, D is the number of external services that the business method depends on, α, β, γ are adjustable weight coefficients, which are set by technical personnel in this field according to actual needs and will not be repeated here.
[0016] S13: Dynamically generate optimized aspect code based on complexity scores.
[0017] Specifically, a complexity score interval is preset, and different aspect codes are used to process business methods in different complexity intervals.
[0018] As mentioned above, the complexity score interval is set by the technicians in this field, and the aspect codes corresponding to different score intervals are written by the technicians in this field according to the actual situation and project requirements, which will not be repeated here.
[0019] By adopting the above technical means, we first traverse all business methods, calculate the complexity of those with @Async, and adopt different aspect codes in different complexity ranges. For high-complexity methods, we adopt more fine-grained monitoring and more conservative asynchronous strategies to reduce the probability of errors and improve overall reliability.
[0020] S2: When a business method that requires asynchronous notification is called, the detailed information corresponding to the business method is cached.
[0021] Specifically, the detailed information includes class name, method name, and input parameters.
[0022] S3: Monitor the running result of the above business method and record the running result in the cache. If the running result is failure, call the business method again.
[0023] Specifically, they include: S31: Calculate the probability of successful retry of the business method, including: P=1-exp(-λ*n)*(1-q^(m / m_max)) Where: P is the probability of successful retry, λ is the learning rate, n is the number of retries, q is the impact factor of system load on success, m is the current load level, and m_max is the maximum load level; S32: If the retry success probability is greater than the preset success probability threshold, a retry is performed, the retry process is continuously monitored, the learning rate λ is updated, and the above steps are repeatedly performed.
[0024] As mentioned above, the success probability threshold is set by those skilled in the art according to actual conditions and will not be described in detail here.
[0025] The updating learning rate λ includes: When the retry succeeds, the learning rate is updated to λ=0.9λ; When the retry fails, the learning rate is updated to λ=1.1λ.
[0026] In the above, the initial value of λ is set to 0.5, and the influencing factor is set by those skilled in the art according to actual conditions. The load level and the maximum load level can be obtained through the system, which will not be described in detail here.
[0027] As described above, by monitoring the business methods that use asynchronous notifications, when it is detected that the business method execution fails, the probability of successful retry of the business method is first calculated. If the probability of successful retry is greater than the preset success probability threshold, the business method is re-called for execution, and the retry process of the business method is continuously monitored. This method can retry failed business methods with a high retry success rate, reduce the occurrence of business method failures, and dynamically update the retry success rate based on the result of each retry, perform dynamic judgment, and further improve the flexibility of the system.
[0028] An embodiment of the present invention provides an asynchronous processing monitoring method, which first traverses all business methods, screens business methods that require asynchronous notification, and then monitors the running results of the above business methods. When it is detected that the execution of a business method fails, the probability of a successful retry of the business method is first calculated. If the probability of a successful retry is greater than a preset success probability threshold, the business method is re-called for execution, and the retry process of the business method is continuously monitored. This method can retry failed business methods with a high retry success rate, reduce the occurrence of business method failures, and dynamically update the retry success rate based on the result of each retry, and perform dynamic judgment, which further improves the flexibility of the system and is beneficial for developers to control and grasp the overall task.
[0029] An embodiment of the present invention further provides an asynchronous processing monitoring system, comprising: The acquisition module is used to traverse all business methods and obtain the business methods that require asynchronous notification; A processing module, used for caching detailed information corresponding to a business method requiring asynchronous notification when the business method is called; The monitoring module is used to monitor the running results of the above business methods and record the running results in the cache; if the running result is failure, the business method is called again until the call is successful.
[0030] An embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored, wherein the program implements the above-described method when executed by a processor.
[0031] Those skilled in the art will appreciate that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as those generally understood by those skilled in the art in the art to which the present invention belongs. It should also be understood that terms such as those defined in general dictionaries should be understood to have meanings consistent with the meanings in the context of the prior art, and will not be interpreted with idealized or overly formal meanings unless specifically defined.
[0032] For the method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should know that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.
[0033] It can be known from the description of the above implementation modes that those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present application can be essentially or partly contributed to the prior art in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute the methods described in the various implementation modes of the present application or certain parts of the implementation modes.
[0034] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.
Claims
1. An asynchronous processing monitoring method, characterized in that: include: Traverse all business methods and obtain the business methods that require asynchronous notification; When a business method that requires asynchronous notification is called, the detailed information corresponding to the business method is cached; Monitor the running results of the above business methods and record the running results in the cache; If the operation result is failure, call the business method again.
2. The method according to claim 1, characterized in that: The business methods that need to be notified asynchronously by traversing all business methods include: After the Spring container completes initialization of the Bean, it traverses all methods and identifies the methods annotated with @Async; The complexity of each method annotated with @Async is analyzed, where the complexity is: C=log(1+α*P^2)+β*sqrt(L)+γ*exp(D / 10) Where: C is the complexity score, P is the number of method parameters, L is the number of method body lines, D is the number of dependent external services, α, β, γ are adjustable weight coefficients; Dynamically generate optimized aspect code based on complexity scores.
3. The method according to claim 1, characterized in that: When a business method requiring asynchronous notification is called, caching detailed information corresponding to the business method includes: The detailed information includes class name, method name, and input parameters.
4. The method according to claim 1, characterized in that: If the operation result is failure, calling the business method again includes: Calculate the probability of successful retry of the business method, including: P=1-exp(-λ*n)*(1-q^(m / m_max)) Where: P is the probability of successful retry, λ is the learning rate, n is the number of retries, q is the impact factor of system load on success, m is the current load level, and m_max is the maximum load level; If the retry success probability is greater than the preset success probability threshold, a retry is performed, the retry process is continuously monitored, the learning rate λ is updated, and the above steps are repeated.
5. The method according to claim 4, characterized in that The updating learning rate λ includes: When the retry succeeds, the learning rate is updated to λ=0.9λ; When the retry fails, the learning rate is updated to λ=1.1λ.
6. The method according to claim 2, characterized in that The dynamically generated optimized section code according to the complexity score includes: Preset complexity score ranges and use different aspect codes to process business methods in different complexity ranges.
7. An asynchronous processing monitoring system, characterized in that: include: The acquisition module is used to traverse all business methods and obtain the business methods that require asynchronous notification; A processing module, used for caching detailed information corresponding to a business method requiring asynchronous notification when the business method is called; A monitoring module is used to monitor the operation results of the above business methods and record the operation results in the cache; If the operation result is failure, call the business method again until the call succeeds.
8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method described in any one of claims 1 to 6 is implemented.