Message queue plug-in optimization method and device for scientific education

Abstract

The invention discloses a message queue plug-in optimization method and device for scientific education. The method comprises the following steps that: a message queue plug-in captures an exception, and determines an exception type of the captured exception; and based on the exception type, the message queue plug-in determines whether to trigger an alarm. The method and the device solve the technical problem that an alarm is generated due to the fact that a business party needs to retry to throw an exception and a plug-in defaults that the exception is regarded as an error.

Description

Technical Field

[0001] The present invention relates to the field of scientific education, and in particular to a message queue plug-in optimization method and device for scientific education. Background Art

[0002] In modern distributed systems, Message Queue (MQ) is an important asynchronous communication mechanism, widely used in various business systems to decouple the relationship between producers and consumers and improve the throughput and reliability of the system. Through the message queue, the producer pushes the message to the queue, and the consumer obtains and processes the message from the queue. The message queue uses a reliable message delivery mechanism to ensure that the message is not lost and can flow through the system. It is widely used in distributed systems, microservice architectures, and big data processing systems.

[0003] However, in actual applications, business parties often encounter some exceptions when consuming messages. For example, when data errors, network problems, or system failures occur during the consumption process, consumers may throw exceptions. In some business scenarios, consumers need to retry when processing messages. This retry mechanism usually causes exceptions to be thrown and passed to the message queue plug-in. If the message queue plug-in treats all exceptions as errors by default and triggers alarms, it may cause too many alarm messages, thereby affecting the operating efficiency of the system, causing false alarms, and increasing the complexity of system maintenance.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiment of the present invention provides a message queue plug-in optimization method and device for scientific education, so as to at least solve the technical problem that an alarm is generated because an exception is thrown when the business party needs to retry, and the plug-in defaults to treating this exception as an error.

[0006] According to one aspect of an embodiment of the present invention, a message queue plug-in optimization method for scientific education is provided, including: the message queue plug-in captures an exception and determines the exception type of the captured exception; based on the exception type, the message queue plug-in determines whether to trigger an alarm.

[0007] According to another aspect of an embodiment of the present invention, a message queue plug-in optimization device for scientific education is also provided, including: a capture module, configured for the message queue plug-in to capture an exception and determine the type of the captured exception; a marking module, configured not to mark the captured exception as an error when the type of the captured exception is a non-error exception class, otherwise to mark the captured exception as an error.

[0008] In an embodiment of the present invention, the message queue plug-in captures the exception and determines the exception type of the captured exception; based on the exception type, the message queue plug-in determines whether to trigger an alarm, thereby solving the technical problem that an alarm is generated because an exception is thrown when the business party needs to retry, but the plug-in defaults to treating this exception as an error. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0010] Figure 1 is a flow chart of a message queue plug-in optimization method for scientific education according to an embodiment of the present invention;

[0011] Figure 2 is a flowchart of another message queue plug-in optimization method for scientific education according to an embodiment of the present invention;

[0012] Figure 3 is a flow chart of a message queue plug-in optimization method according to an embodiment of the present invention;

[0013] Figure 4 is a flowchart of another message queue plug-in optimization method according to an embodiment of the present invention;

[0014] Figure 5 is a flow chart of a method for optimizing a message queue plug-in by using an adaptive learning algorithm according to an embodiment of the present invention;

[0015] Figure 6 is a schematic diagram of an optimized structure of a message queue plug-in for scientific education according to an embodiment of the present invention;

[0016] Figure 7 A schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0017] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings 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 ordinary technicians in this field without creative work 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 and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0019] According to an embodiment of the present invention, a method embodiment of a message queue plug-in optimization method for scientific education is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0020] Figure 1 is a message queue plug-in optimization method for scientific education according to an embodiment of the present invention, such as Figure 1 As shown, the method comprises the following steps:

[0021] Step S102: the message queue plug-in captures an exception and determines the exception type of the captured exception.

[0022] An exception type specification is added to the configuration of the message queue plug-in, wherein the exception type specification is used to define a non-error exception class, and the non-error exception class is used to indicate that an exception of this type does not need to trigger an alarm.

[0023] When the business party consumes the message, if a retry is required, the non-error exception is thrown; otherwise, the error exception is thrown.

[0024] Step S104: Based on the exception type, the message queue plug-in determines whether to trigger an alarm.

[0025] When the type of the captured exception is a non-error exception class, the message queue plug-in does not mark the captured exception as an error and does not trigger an alarm; when the type of the captured exception is an error exception class, the message queue plug-in marks the captured exception as an error and triggers an alarm.

[0026] The embodiment of the present invention also provides another message queue plug-in optimization method for scientific education. In this embodiment, Skywalking is taken as an example. Skywalking is an open source APM (application performance monitoring) system for monitoring distributed systems under a microservice architecture. MQ (Message Queue) is a message queue for asynchronously transmitting messages in a distributed system. A plug-in is a module in the Skywalking system for extending functions.

[0027] The existing Skywalking MQ plug-in will throw an exception when processing message queue consumption if the business party needs to retry. The plug-in treats this exception as an error by default, resulting in an alarm. Developers need to troubleshoot these alarms, which affects development efficiency. This processing method is the default behavior of the current Skywalking MQ plug-in. The shortcoming of this processing method is that it does not distinguish between exceptions that the business party needs to retry and real error exceptions. This causes each retry to trigger an alarm, increasing the developer's troubleshooting workload and reducing work efficiency.

[0028] In order to solve the above problems, the present invention proposes a message queue plug-in optimization method for scientific education, such as Figure 2 As shown, the following steps are included:

[0029] Step S202, determining whether the business party's consumption message is executed successfully.

[0030] If the execution is not successful, step S204 is executed to determine whether the business party needs to retry to consume the message, otherwise, the message processing continues.

[0031] Step S204, determine whether a retry is required.

[0032] First, define a specific retry exception class. Create a new exception class CustomRetryException, which is thrown by the business side when a retry is required.

[0033] Next, determine whether a retry is required. If a retry is required, execute step S206 and throw a CustomRetryException exception. Otherwise, execute step S207 and throw an error exception.

[0034] In other embodiments, AOP (Aspect Oriented Programming) technology may also be used to intercept exceptions in business codes and decide whether to issue an alarm based on the exception type.

[0035] Step S206, throwing a CustomRetryException.

[0036] Step S208, the skywalking MQ plug-in captures an exception.

[0037] Step S210, determine whether it is a CustomRetryException.

[0038] The user specifies in the plug-in configuration which exception types do not trigger an alarm. In this way, when the business party consumes the message, if a retry is required, a CustomRetryException is thrown. After the plug-in captures the exception, it makes a judgment. If it is not a CustomRetryException, it is marked as an error and an alarm is triggered. If it is a CustomRetryException, no alarm is triggered.

[0039] Specifically, an exception judgment logic is added to the Skywalking MQ plug-in. The plug-in determines whether to trigger an alarm by judging the exception type, thereby avoiding false alarms caused by retries. When the captured exception is CustomRetryException, step S212 is executed, otherwise, step S213 is executed.

[0040] Step S212: No alarm is triggered.

[0041] When CustomRetryException is caught, it is not marked as an error, no alarm is triggered, and message consumption continues.

[0042] Step S213, triggering an alarm.

[0043] Mark it as an error and trigger an alarm for alarm processing.

[0044] This application defines a specific retry exception class CustomRetryException, which is used to identify scenarios where the business party needs to retry during the message consumption process. Next, the exception judgment logic is added to the Skywalking MQ plug-in, so that the plug-in can make correct processing according to the captured exception type. In order to enhance the flexibility of the plug-in, a new function for specifying exception types is added to the plug-in configuration, allowing developers to customize settings according to specific needs. Through the above-mentioned improved solution, false alarms caused by retries are avoided, and the troubleshooting workload of developers is significantly reduced. Secondly, development efficiency has been improved because developers no longer need to frequently deal with irrelevant false alarms and can focus on more important issues. Finally, these optimizations enhance the flexibility and usability of the Skywalking MQ plug-in, making it more adaptable to different business scenarios and needs.

[0045] The embodiment of the present application also provides another message queue plug-in optimization method, which mainly includes the steps of exception capture and classification, exception type judgment, intelligent triggering of alarm strategy, retry mechanism design, logging and adaptive optimization.

[0046] Specifically, Figure 3 As shown, including:

[0047] Step S302, capturing the exception in the message queue.

[0048] During the consumption process of the message queue, the message queue plug-in monitors the exceptions on the consumer side in real time through the integrated exception capture mechanism. The plug-in usually captures all exceptions thrown when consuming messages through hook functions, callback interfaces or AOP (Aspect Oriented Programming) technology. The plug-in immediately records the detailed information of the exception, including the exception type, stack information, message content, timestamp, and environmental data when the exception occurred.

[0049] In order to improve the sensitivity and accuracy of exception capture, the plug-in adopts a multi-level exception capture mechanism. First, the captured exceptions will be divided into system exceptions (such as SystemException) and application layer exceptions (such as CustomRetryException). Each type of exception will be handled differently according to its severity.

[0050] Exception types can be divided into: 1) System exceptions: such as database connection exceptions, disk failures, etc., usually represent serious system errors. 2) Business exceptions: such as data format errors, business logic errors, etc., usually represent application layer failures. 3) Retryable exceptions: such as CustomRetryException, indicating that the consumer business logic wants to retry.

[0051] In addition to basic exception information, the plug-in also enhances the ability to capture exception information and records the context information when the exception occurs, including the current consumer status, message metadata (such as message ID, timestamp, consumer information), etc. This information can help analyze the cause of the exception later and quickly locate the source of the problem when similar problems occur.

[0052] Step S304: abnormality type determination and classification.

[0053] After the message queue plug-in captures an exception, the plug-in will first classify it based on the type of exception. In addition to the common SystemException and CustomRetryException, the exception type classification will be further refined.

[0054] Specifically, the plug-in is classified according to the following rules: 1) Network exceptions (NetworkException): such as network connection loss, timeout, etc. Due to its certain uncertainty, the plug-in will mark such exceptions as retryable, allowing the business party to retry. 2) Database exceptions (DatabaseException): Such as database connection failure, query timeout, etc., this type of exception may need to be processed immediately, but it does not mean that the system has crashed. The plug-in will decide whether to trigger an alarm based on the specific type and severity of the exception. 3) Configuration exceptions (ConfigurationException): Such as configuration file errors, missing environment variables, etc., usually do not require immediate alarms, but developers need to fix them as soon as possible. Each exception type has a corresponding error code and detailed description, which can help the system more accurately determine the nature of the exception and the subsequent processing method.

[0055] Step S306, abnormality severity assessment.

[0056] After classification, the plug-in further evaluates the severity of the anomaly. Through comprehensive analysis of historical data, anomaly frequency, anomaly duration and other factors, the plug-in automatically determines whether the anomaly is severe enough to trigger an alarm.

[0057] The evaluation mechanism includes: 1) Exception frequency: If the same exception occurs frequently in a short period of time, the plug-in will increase the severity assessment level of the exception, and even if it may be a retryable exception, an alarm will be considered. Exception duration: If the duration of the exception exceeds the set threshold (for example, an exception occurs more than 5 times within 1 hour), the system will automatically mark it as a "high priority" exception and trigger an alarm. 2) Business importance of the message: For business-critical messages, if an exception occurs, even a retryable exception, an alarm can be triggered.

[0058] Step S308: Alarm strategy and trigger mechanism.

[0059] After determining the type and severity of the anomaly, the plug-in decides whether to trigger an alarm based on the preset alarm strategy. The alarm strategy can be adjusted dynamically to cope with changes in different business scenarios.

[0060] For system exceptions (SystemException), an alarm will be triggered immediately and detailed alarm information will be generated, including the exception type, stack information, affected message ID, etc.

[0061] For FrequentException, if a certain type of exception occurs with an abnormally high frequency, the system will automatically consider it as a potential system failure and generate an emergency alarm to notify relevant personnel.

[0062] For retryable exceptions (CustomRetryException), if it is a retryable exception, the plug-in will not trigger an alarm, but will record the exception and execute the retry logic. The number of retries and intervals can be customized according to business needs.

[0063] In some other embodiments, for exceptions that can be retried, the plug-in also provides a flexible retry mechanism. For example, the number of retries is limited. The system allows a maximum number of retries for each message to avoid wasting system resources due to unlimited retries. If the number of retries exceeds the limit, it is considered a system failure and an alarm is triggered. The retry interval is limited. Depending on the type of exception and the system load, the retry interval can be adjusted dynamically. For example, a network exception can be retried multiple times in a short period of time, while a database exception may require a longer time interval. An exponential backoff strategy can also be used. For exceptions that occur frequently, an exponential backoff strategy is used, and the interval between each retry will increase to avoid excessive use of system resources.

[0064] Step S310: Alarm notification.

[0065] Once an exception triggers an alarm, the plug-in will immediately notify relevant personnel through reason email, SMS, web console, etc. The alarm notification will contain all necessary diagnostic information, such as exception type, detailed description, stack information, message ID, etc., so as to quickly locate the problem and take repair measures.

[0066] The embodiment of the present application also proposes another message queue plug-in optimization method. The difference between this embodiment and the above embodiment is that the embodiment of the present application combines an adaptive learning algorithm to automatically optimize the message queue plug-in. In addition to the steps of the adaptive learning algorithm, the steps in this embodiment are the same as Figure 3 The steps of the corresponding embodiments are the same, so they are not repeated here, and only the adaptive learning algorithm is described.

[0067] like Figure 4 As shown, the method for optimizing the message queue plug-in using the adaptive learning algorithm includes the following steps:

[0068] Step S402, collecting abnormal data.

[0069] First, collect data. The plug-in will continuously collect and store exception information, including but not limited to: exception type, such as NetworkException, DatabaseException, SystemException, etc. Exception frequency, that is, the number of times each type of exception occurs. Retry information, that is, the result of each exception retry, including whether it is successful, the number of retries, the retry interval, etc. Alarm trigger information, that is, the triggering situation of each alarm, including alarm type, alarm time, alarm duration, alarm-associated exception type, etc. The plug-in will store this data in a database or log system to ensure the historical traceability of the data. In the real-time monitoring system, the plug-in will index this information by timestamp to facilitate subsequent analysis and optimization.

[0070] Step S404, analyzing abnormal data.

[0071] The plug-in analyzes the collected data and extracts the key features of the anomaly. First, determine the anomaly classification and occurrence pattern. By statistically analyzing historical anomaly records, the plug-in can identify which anomaly types occur frequently and which anomalies are sporadic. Frequently occurring anomalies may indicate potential problems with the system, while sporadic anomalies may be just accidental events. Second, determine the alarm frequency. Analyze the relationship between anomalies and alarms, see which anomaly types trigger too many alarms, and evaluate whether these alarms are necessary. Next, determine the retry success rate. Track the retry success rate of each anomaly type. For anomaly types with a high retry success rate, the plug-in can gradually lower the priority of the alarm or reduce the alarm frequency. Through these data analyses, the plug-in can gradually identify the patterns of anomalies and alarms, and optimize subsequent exception handling and alarm strategies accordingly.

[0072] Step S406: intelligent learning and adjustment.

[0073] The plug-in uses adaptive learning algorithms (such as reinforcement learning or machine learning models) to perform intelligent optimization based on the collected data. Specifically, Figure 5 As shown, the following steps are included:

[0074] Step S4062, adjust the abnormal classification.

[0075] Through adaptive learning, the plug-in can automatically adjust the anomaly classification criteria during operation. For example, certain types of anomalies may be considered normal in certain system configurations or environments, and the plug-in will learn these rules based on historical data and make corresponding adjustments.

[0076] Step S4064, adjust the alarm priority.

[0077] The plug-in automatically adjusts the priority of the alarm according to the severity and frequency of the exception. For frequent exception types that have little impact on the business, the plug-in will lower its alarm priority, thereby avoiding unnecessary alarms and reducing interference from operation and maintenance personnel.

[0078] In some embodiments, the plug-in can use reinforcement learning algorithms to optimize alarm triggering decisions. Specifically, for example, whenever the plug-in successfully reduces false alarms or improves alarm accuracy based on new abnormal data, the system will give positive rewards; if there are too many false alarms, negative rewards will be given. Through continuous "trial and error" and feedback, the system gradually learns how to optimize the alarm strategy. In addition, the reinforcement learning model can automatically adjust the abnormal classification and alarm triggering strategies based on historical abnormal data. For example, a certain type of abnormality frequently occurs in a low-load environment. The plug-in will adjust the alarm triggering conditions of the abnormality according to this rule to avoid the system triggering alarms when it is not necessary.

[0079] The following example describes the adaptive optimization method. Assume that in the past period of time, the plug-in found that the retry success rate of NetworkException was as high as 95%, which means that most network problems are short-lived and can be solved by retrying. Therefore, the system may automatically identify this exception type as an "ignorable alarm" type, and then perform the following adaptive optimization:

[0080] 1) Adjust the retry strategy.

[0081] Based on the high success rate of NetworkException, the plug-in will automatically adjust the retry strategy for the exception. Specifically, the plug-in can increase the maximum number of retries for the exception or shorten the retry interval to reduce premature alarms due to temporary network problems. For example, when network latency increases, the plug-in may allow more retries. For example, for NetworkException, the plug-in can not only adjust the number and interval of retries, but also dynamically adjust the retry strategy based on real-time information such as network bandwidth and packet loss rate. If the current network environment is very unstable, the system may enable a stricter fallback mechanism or optimize the size of the data packet and the retry logic to reduce the system pressure caused by frequent retries.

[0082] 2) Reduce the alarm priority.

[0083] After the system finds that the retry success rate of NetworkException is high and will not have a significant impact on the business, the plug-in will automatically lower the alarm priority of the exception. For example, the plug-in can set that when a NetworkException occurs, if the retry success rate exceeds 90%, the alarm priority is reduced to "low", and only logs are recorded without triggering a high priority alarm.

[0084] 3) Reduce the frequency of alarms.

[0085] The plug-in automatically optimizes the alarm triggering rules by analyzing the historical frequency of NetworkException. If the frequency of this exception type is higher during low-traffic periods, the system will intelligently reduce the alarm notifications during these periods. You can also set a threshold so that an alarm is triggered only when NetworkException occurs more than a certain number of times in a short period of time.

[0086] 4) Update the alarm rules.

[0087] The system will update the alarm rules based on the optimized data of NetworkException, for example, by adjusting the triggering conditions of the alarm through automatic configuration. For exception types with high success rates, the plug-in may define alarms at the "warning" level instead of the "emergency" level to avoid misjudging frequent but harmless exceptions as system failures.

[0088] Through these adaptive optimization measures, the plug-in can effectively reduce false alarms caused by NetworkException and improve the accuracy of alarms. This not only reduces the interference of operation and maintenance personnel, but also makes the system run more efficiently. In high-frequency, low-impact abnormal situations, the plug-in avoids resource waste and unnecessary system maintenance pressure through flexible alarm adjustments.

[0089] In the above scheme, the plug-in performs adaptive learning based on historical data and abnormal patterns. However, the load, network status and external environment of many systems will change with time and different usage scenarios. Therefore, in some other embodiments, the "real-time environment adaptation" function can also be introduced, which not only relies on historical data, but also considers environmental variables such as real-time system load, network status, database response time, etc., so as to dynamically adjust the abnormal classification and alarm strategy. Specifically, the features of the health check data of each service instance are modeled. By constructing multiple decision surfaces, the data is divided layer by layer. In each division step, a feature and its corresponding segmentation point are randomly selected for data segmentation. Since the abnormal points are isolated earlier in the plane structure, they will be quickly divided into shallower nodes, so the path length of these points will be shorter, thereby obtaining a higher abnormal score. Next, the data in the normal state is further separated from the data in the abnormal state, and the interval between the two types of data is maximized. In the process of optimizing the decision surface, by adjusting the position and normal vector of the decision surface, the classification error is minimized, so that the normal and abnormal states of the service instance can be effectively distinguished in the high-dimensional space, providing an accurate judgment basis for the subsequent state classification. During the training process, the separation distance between the normal state and the abnormal state is maximized. In this way, in the feature space, samples in normal state will be as far away from samples in abnormal state as possible, and vice versa. At the same time, the decision surface is optimized by minimizing the classification error. By adjusting the position and normal vector of the decision surface, these misclassified samples can be reduced, thereby ensuring that more data points are correctly classified. Finally, by solving the optimization problem, the optimal normal vector and intercept are obtained, so that samples in normal and abnormal states can be separated to the greatest extent in the feature space. After that, data analysis is performed based on the classification results. In order to further improve the alarm accuracy of the system, multi-dimensional time series data analysis is introduced. The time series correlation between multiple abnormal service instances is analyzed, the dependencies between different service instances are identified, and the potential connections of service state changes are determined. In addition, based on the interactive relationship between services, the fault chain effect between services is captured, thereby improving the accuracy of fault prediction and anomaly detection. In this way, the plug-in can dynamically evaluate and adjust the importance of anomalies and alarm trigger thresholds based on real-time system status (such as CPU load, network latency, database query response time, etc.) combined with real-time data streams (such as the current state of the message queue, the length of the message processing queue, consumer processing speed, etc.). For example, when the system load is high, the plug-in may lower the alarm priority for certain non-critical exceptions to reduce system pressure; when the system load is low, it may increase the alarm frequency for certain exceptions to enhance the system's response.

[0090] In this application, the plug-in will automatically adjust the priority of the alarm according to the severity and frequency of the exception. For exception types with less impact and high retry success rate, the plug-in will lower the alarm priority to avoid false alarms and unnecessary alarms, thereby reducing the burden on operation and maintenance personnel. At the same time, the plug-in will also dynamically adjust the retry strategy to flexibly respond to different abnormal situations according to the real-time system load and network conditions. For example, for network exceptions (NetworkException), if the retry success rate is high, the plug-in will adjust the number of retries and intervals to reduce interference with the system. In addition, the plug-in can also optimize the alarm rules based on historical data and real-time monitoring status to achieve a more intelligent alarm triggering mechanism. This adaptive optimization method not only improves the accuracy of the alarm, but also enhances the stability and scalability of the system, reduces resource waste, and improves the system operation efficiency.

[0091] The present application also provides a message queue plug-in optimization device for scientific education, such as Figure 6 As shown, it includes: a capture module 62, which is configured for the message queue plug-in to capture the exception and determine the type of the captured exception; a marking module 64, which is configured not to mark the captured exception as an error when the type of the captured exception is a non-error exception class, otherwise the captured exception is marked as an error.

[0092] It should be noted that the message queue plug-in optimization device for scientific education provided in the above embodiment is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the message queue plug-in optimization device for scientific education provided in the above embodiment and the message queue plug-in optimization method embodiment for scientific education belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0093] Figure 7 FIG. 1 shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiment of the present disclosure. It should be noted that: Figure 7 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0094] like Figure 7As shown, the electronic device includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage part 1008 into a random access memory (RAM) 1003. In the RAM 1003, various programs and data required for system operation are also stored. The CPU 1001, the ROM 1002, and the RAM 1003 are connected to each other via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0095] The following components are connected to the I / O interface 1005: an input section 1006 including a keyboard, a mouse, etc.; an output section 1007 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, a modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the I / O interface 1005 as needed. A removable medium 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1010 as needed, so that a computer program read therefrom is installed into the storage section 1008 as needed.

[0096] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A message queue plug-in optimization method for scientific education, characterized in that: include: The message queue plug-in captures the exception and determines the exception type of the captured exception; Based on the exception type, the message queue plug-in determines whether to trigger an alarm.

2. The method according to claim 1, characterized in that Based on the exception type, the message queue plug-in determines whether to trigger an alarm, including: When the type of the captured exception is a non-error exception class, the message queue plug-in does not trigger an alarm; In the case where the type of the captured exception is an error exception class, the message queue plug-in triggers an alarm.

3. The method according to claim 2, characterized in that Before the message queue plug-in captures the exception, the method further includes: adding an exception type specification in the configuration of the message queue plug-in, wherein the exception type specification is used to define a non-error exception class, and the non-error exception class is used to indicate that the exception of this type does not need to trigger an alarm.

4. The method according to claim 3, characterized in that Before the message queue captures the abnormal message, the method further includes: when the business party consumes the message, if a retry is required, throwing the non-error exception, otherwise, throwing the error exception.

5. The method according to claim 4, characterized in that Before the message queue plug-in does not trigger an alarm, the method further includes: not marking the captured exception as an error.

6. The method according to claim 4, characterized in that Before the message queue plug-in triggers an alarm, the method further includes: marking the captured exception as an error.

7. A message queue plug-in optimization device for scientific education, characterized in that: include: The capture module is configured to capture the exception when the message queue plug-in is captured, and determine the type of the captured exception; The marking module is configured to not mark the captured exception as an error if the type of the captured exception is a non-error exception class, and to mark the captured exception as an error otherwise.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the method according to any one of claims 1 to 6.

9. A computer device, characterized in that: include: Memory and processor, The memory stores a computer program; The processor is used to execute the computer program stored in the memory, and when the computer program is run, the processor is enabled to execute the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images