Non-intrusive asynchronous processing method based on transaction event monitoring

Abstract

The invention provides a non-intrusive asynchronous processing method based on transaction event monitoring. An asynchronous event is triggered through a transaction event monitor after a database transaction is submitted, it is ensured that asynchronous operation strictly follows a transaction life cycle, and the risk of data inconsistency caused by dislocation of a thread pool task and a transaction time sequence in a traditional scheme is fundamentally avoided; by intercepting a business method carrying asynchronous execution annotations and automatically extracting parameters to generate an asynchronous request event, physical isolation of business logic and an asynchronous mechanism is realized, and architecture pollution is eliminated; and further dynamically routing to an instant execution or persistent execution module according to the policy type annotated and declared, so as to provide elastic execution capability for different service scenes. Therefore, on the premise of guaranteeing transaction atomicity, a zero-intrusive and extensible asynchronous processing framework is constructed, and the reliability and maintainability of the system are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of microservices, and particularly relates to a non-invasive asynchronous processing method based on transaction event listening. BACKGROUND

[0002] In the microservice architecture, the continuous expansion of business functions needs to rely on the asynchronous improvement of system throughput. However, the existing asynchronous scheme has serious limitations. On the one hand, there is transaction fragmentation. The thread pool event and the database transaction cannot be coordinated, which leads to the asynchronous operation being executed before the transaction is committed. On the other hand, there may be architecture pollution. For example, non-business logic such as retry, queue management, and the like invades the core code, increasing the coupling degree of the module. Thirdly, after the event fails, there is a lack of automatic recovery capability. Usually, manual compensation is needed to achieve data consistency.

[0003] Therefore, in view of the deficiencies in transaction consistency, system architecture, and data reliability, a non-invasive asynchronous processing method based on transaction event listening is needed to solve the corresponding problems. SUMMARY

[0004] The purpose of the present application is to at least solve one of the above technical defects, especially the technical defects of the deficiencies in transaction consistency, system architecture, and data reliability in the microservice architecture in the prior art.

[0005] In a first aspect, the present application provides a non-invasive asynchronous processing method based on transaction event listening, which comprises:

[0006] After the database transaction is committed, an asynchronous event is triggered by a transaction event listener;

[0007] Intercepting a business method carrying an asynchronous execution annotation, extracting method parameters and generating an asynchronous request event;

[0008] According to the strategy type declared in the asynchronous execution annotation, a routing operation is performed for immediate execution or on-demand execution.

[0009] As an optional implementation, the method further comprises:

[0010] Event link tracking and state monitoring are performed through a data persistence structure;

[0011] The data persistence structure comprises:

[0012] The method signature, the strategy type, and the queue name are stored through an asynchronous scenario table;

[0013] The request parameters, the execution state, and the retry count are recorded through an asynchronous request table;

[0014] The exception stack is stored through an asynchronous log table associated with the event.

[0015] As an optional implementation, the method further comprises:

[0016] Repairing the event of execution failure according to a three-level fault-tolerant process;

[0017] The three-level fault-tolerant process comprises:

[0018] The first level of fault tolerance is to mark the execution state of the corresponding event as failed in the asynchronous request table after immediate execution failure;

[0019] The second level of fault tolerance is to scan the records in the asynchronous request table whose execution state is failed and retry count is not over limit through the timing event engine, and perform retry, and when the retry count is over limit, trigger the third level of fault tolerance mechanism;

[0020] The third level of fault tolerance is to perform retry execution, parameter modification and error log query through the preset management and control platform.

[0021] As an optional implementation, the implementation of the transaction event listener comprises:

[0022] The transaction event listener is configured to respond to events in the transaction completion phase;

[0023] The callback operation is registered through the transaction synchronizer, and the asynchronous event is blocked until the transaction operation is completed.

[0024] As an optional implementation, the intercepted business method carrying the asynchronous execution annotation comprises:

[0025] In the component initialization phase, the asynchronous execution annotation is scanned, the proxy object is generated and cached;

[0026] The business method carrying the asynchronous execution annotation is intercepted through aspect logic, and the asynchronous event carrying the parameters and the policy type is published.

[0027] As an optional implementation, the routing operation is performed according to the policy type declared in the asynchronous execution annotation, and immediate execution or on-demand execution is performed, comprising:

[0028] When the immediate policy is declared in the asynchronous execution annotation, the request is routed to the immediate execution module to directly call the target method;

[0029] When the persistence policy is declared in the asynchronous execution annotation, the request data is sent to the message queue, and stored to the asynchronous request table and marked as initial execution state failed.

[0030] In a second aspect, the application provides a non-invasive asynchronous processing device based on transaction event listening, comprising:

[0031] The processing module is configured to trigger an asynchronous event through a transaction event listener after a database transaction is committed.

[0032] The processing module is further configured to intercept a business method carrying an asynchronous execution annotation, extract method parameters, and generate an asynchronous request event.

[0033] The processing module is further configured to perform a routing operation according to a strategy type declared in the asynchronous execution annotation, and perform instant execution or on-demand execution.

[0034] As an optional implementation, the apparatus further comprises a data module configured to:

[0035] Event link tracking and state monitoring are performed through a data persistence structure.

[0036] The data persistence structure comprises:

[0037] Method signatures, strategy types, and queue names are stored through an asynchronous scenario table.

[0038] Request parameters, execution states, and retry counts are recorded through an asynchronous request table.

[0039] Exception stacks are stored through an asynchronous log table in association with event conditions.

[0040] In a third aspect, the present application provides a computer device, comprising one or more processors, and a memory, wherein the memory stores computer readable instructions, and the computer readable instructions are executed by the one or more processors to perform the steps of the method according to the first aspect.

[0041] In a fourth aspect, the present application provides a storage medium, wherein the storage medium stores computer readable instructions, and the computer readable instructions are executed by one or more processors to cause the one or more processors to perform the steps of the method according to the first aspect.

[0042] As can be seen from the above technical solutions, the embodiments of the present application have the following advantages:

[0043] Based on any of the above embodiments, the application strictly binds the asynchronous task triggering to the database transaction submission through the transaction event listening mechanism, eliminates the risk of dirty read caused by asynchronous operation preceding transaction completion from the root, and guarantees the strong consistency of business data; based on the annotation interception and dynamic proxy technology, the physical isolation of asynchronous logic and business code is realized, and the architecture pollution problem of non-core functions such as retry and queue management invading business modules in traditional solutions is solved; further, through the cooperation of the three-level closed-loop fault-tolerant system (immediate execution, timed retry, and manual bottom-up) and the data persistence structure (scenario table, request table, and log table), a self-healing asynchronous framework with task full-link traceability and state visualization is constructed. The design enables the system to maintain the purity of business logic while having the dual protection capability of automatic recovery and manual intervention of task failure, significantly improves the operation and maintenance efficiency, and finally realizes the high-reliability, zero-invasion, and observable asynchronous processing paradigm, providing a standardized solution for atomic asynchronous coordination of microservice architecture. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0045] Figure 1 The flowchart of the non-invasive asynchronous processing method based on transaction event listening provided by an embodiment of the present application is shown in the figure.

[0046] Figure 2 The data entity design schematic diagram of the non-invasive asynchronous processing method based on transaction event listening provided by an embodiment of the present application is shown in the figure.

[0047] Figure 3 The flowchart of saving the database first and then processing the asynchronous message in the non-invasive asynchronous processing method based on transaction event listening provided by an embodiment of the present application is shown in the figure.

[0048] Figure 4 The flowchart of saving the database first and then processing the asynchronous message in the non-invasive asynchronous processing method based on transaction event listening provided by an embodiment of the present application is shown in the figure.

[0049] Figure 5 The flowchart of saving the database first and then processing the asynchronous message in the non-invasive asynchronous processing method based on transaction event listening provided by an embodiment of the present application is shown in the figure.

[0050] Figure 6 The overall flowchart of the non-invasive asynchronous processing method based on transaction event listening provided by an embodiment of the present application is shown in the figure.

[0051] Figure 7 The internal structure diagram of the computer device provided by the embodiment of the application is shown. DETAILED DESCRIPTION

[0052] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by a person of ordinary skill in the art without creative work are within the protection scope of the application.

[0053] In the microservice architecture, the continuous expansion of business functions needs to rely on the asynchronous improvement of system throughput. However, the existing asynchronous scheme has serious limitations: transaction fragmentation, thread pool tasks and database transactions cannot be coordinated, resulting in asynchronous operations being executed before transaction submission; architecture pollution, retry, queue management and other non-business logic invade the core code, increasing the coupling degree of modules; operation and maintenance black hole, after task failure, there is a lack of automatic recovery capability, and manual compensation is needed to achieve data consistency.

[0054] The application binds asynchronous tasks and transaction life cycles through a transaction event listening mechanism (@TransactionalEventListener), combines a policy-based asynchronous routing, a multi-level fault tolerance engine and a visual management and control platform, and constructs a high-reliability asynchronous processing framework. The application realizes the atomic triggering of asynchronous operations after transaction submission; the application realizes business zero-invasion through annotation driving (@AsyncExec); the application provides a closed-loop bottoming-out capability (message persistence + timing compensation + manual intervention) to guarantee data recoverability.

[0055] Therefore, the application takes transaction event listening as an anchor point, and solves the industry-level problems of asynchronous tasks in transaction consistency, system expansibility and data reliability through non-invasive architecture and closed-loop fault tolerance design.

[0056] In summary, the technical concept of the present application is that the present application strictly binds the asynchronous task triggering to the database transaction completion through the transaction event listener mechanism, eliminates the risk of dirty read caused by asynchronous operation preceding transaction completion from the root, and guarantees the strong consistency of business data; based on the annotation interception and dynamic proxy technology, the physical isolation of asynchronous logic and business code is realized, and the architecture pollution problem of non-core function intrusion into business module in the traditional scheme such as retry, queue management and the like is solved; further, through the cooperation of three-level closed-loop fault-tolerant system (immediate execution, timed retry, manual bottom-up) and data persistence structure (scene table, request table, log table), a self-healing asynchronous framework with task full-link traceability and state visualization is constructed. The design makes the system maintain the purity of business logic while having the dual protection capability of automatic recovery and manual intervention of task failure, significantly improves the operation and maintenance efficiency, and finally realizes the asynchronous processing paradigm of high reliability, zero invasion and observability, provides a standardized solution of atomic asynchronous cooperation for micro-service architecture.

[0057] The method provided by the present application will be described in detail below according to the corresponding embodiments in some practical application scenarios.

[0058] Figure 1 The flowchart of the non-invasive asynchronous processing method based on transaction event listening provided by an embodiment of the present application is shown in FIG. 1, and the present application provides a non-invasive asynchronous processing method based on transaction event listening, which comprises the following steps. Figure 1

[0059] S101, triggering an asynchronous event through a transaction event listener ( @TransactionalEventListener (phase = TransactionPhase.AFTER_COMPLETION) ) after a database transaction is completed;

[0060] S102, intercepting a business method carrying an asynchronous execution annotation ( @AsyncExec), extracting method parameters and generating an asynchronous request event ( AsyncEvent) ;

[0061] S103, performing routing operation according to the policy type ( AsyncExecEnum) declared in the asynchronous execution annotation, and performing immediate execution or on-demand execution.

[0062] ​The embodiment triggers an asynchronous event after a database transaction is committed through a transaction event listener, ensures that an asynchronous operation strictly follows a transaction life cycle, and avoids a data inconsistency risk caused by a thread pool task and a transaction time sequence misalignment in a traditional solution from the root; generates an asynchronous request event by intercepting a business method carrying an asynchronous execution annotation and automatically extracting parameters, realizes physical isolation of a business logic and an asynchronous mechanism, and eliminates architecture pollution; and further dynamically routes to an instant execution or persistent execution module according to a policy type declared by the annotation, and provides elastic execution capability for different business scenarios. Therefore, on the premise of ensuring transaction atomicity, a zero-intrusion and extensible asynchronous processing framework is constructed, and system reliability and maintainability are significantly improved.

[0063] As an optional embodiment, the method further includes:

[0064] Event link tracking and state monitoring are performed through the data persistence structure;

[0065] Please refer to Figure 2 , Figure 2 A data entity design schematic diagram of a transaction event listener-based non-intrusive asynchronous processing method provided for an embodiment of the application is provided, wherein the data persistence structure includes:

[0066] A method signature (method_sign), a policy type (async_type), and a queue name (queue_name) are stored through an asynchronous scene table (async_scene);

[0067] Request parameters (param_json), an execution status (exec_status), and a retry count (exec_count) are recorded through an asynchronous request table (async_req);

[0068] Exception stack (error_data) is stored through an asynchronous log table (async_log) in association with event conditions (async_id).

[0069] Other fields are further included in the data persistence structure, and can be deployed as needed.

[0070] The embodiment stores metadata such as a method signature and a policy type through an asynchronous scene table, establishes an asynchronous task standardized description system; in combination with an asynchronous request table recording full-link execution status and a retry count, realizes visual management of a task life cycle; further in combination with an asynchronous log table associated with exception stack information, forms a closed-loop diagnosis link. The data persistence structure provides a unified data base for event tracking and state monitoring, solves a black-box problem of an asynchronous link in a traditional solution, and greatly reduces the complexity of fault positioning and analysis.

[0071] As an optional implementation, the method further comprises:

[0072] Repairing the event of execution failure according to a three-level fault-tolerant process;

[0073] The three-level fault-tolerant process comprises:

[0074] First-level fault tolerance: after immediate execution failure, marking the execution state of the corresponding event in the asynchronous request table (async_req) as failure (exec_status=1);

[0075] Second-level fault tolerance: through a timing event engine (XXL-JOB), scanning records in the asynchronous request table (async_req) with the execution state as failure (exec_status=1) and the retry count not exceeding the limit (exec_count<maxRetry), retrying, and triggering the third-level fault-tolerant mechanism when the retry count exceeds the limit;

[0076] Third-level fault tolerance: retrying execution, modifying parameters, and querying error logs through a preset management and control platform.

[0077] The embodiment designs a three-level progressive fault-tolerant mechanism: the first level marks the state after immediate execution failure, realizing quick failure response; the second level automatically retries the failure task that does not exceed the limit through a timing engine, guaranteeing self-repair of regular exceptions; and the third level transfers the task to the management and control platform after retrying exceeding the limit, supporting manual intervention and parameter adjustment. The mechanism builds a closed-loop fault-tolerant system with automatic repair as the main part and manual backup as the auxiliary part, solves the operation and maintenance problem of manual script compensation after task failure in traditional solutions, and significantly improves the system resilience and data final consistency guarantee capability.

[0078] Please refer to Figure 3 , Figure 3 The flowchart of the method provided by an embodiment of the application shows that, after transaction submission, the request is stored in the async_req table (marked as exec_status=1) first, then the asynchronous message is sent to the message queue (Kafka), and the state is updated to exec_status=2 (success) after successful processing.

[0079] As an optional implementation, the implementation of the transaction event listener comprises:

[0080] The transaction event listener is configured to respond to the event in the transaction completion phase (phase=TransactionPhase.AFTER_COMPLETION);

[0081] Register callback operation through TransactionSynchronizationManager, block asynchronous event until transaction operation is completed.

[0082] Specifically, the transaction event listener trigger mechanism is to use Spring@TransactionEventListener annotation, configure phase=TransactionPhase.AFTER_COMPLETION, strictly bind the database transaction life cycle, and configure fallbackExecution=true to ensure that no transaction context can still be executed.

[0083] In terms of transaction synchronization control, register callback hooks through Spring TransactionSynchronizationManager, add blocking points before transaction submission, block asynchronous tasks until transaction submission is completed, and avoid dirty reading.

[0084] @TransactionalEventListener: mark the method as a transaction event listener;

[0085] phase=TransactionPhase.AFTER_COMPLETION: limit to trigger only after transaction completion;

[0086] fallbackExecution=true: fallback execution mechanism in non-transaction environment;

[0087] Thus, the time sequence binding relationship between database transaction and asynchronous task is established.

[0088] The transaction event listener in this embodiment responds to events in the transaction completion phase, strictly binds the asynchronous triggering time to the end of the transaction life cycle, and further registers callback operations through the transaction synchronizer to force asynchronous events to wait until the transaction operation is completed before execution. This double time sequence control mechanism completely eliminates the risk of asynchronous task reading intermediate state data when the transaction is not submitted, and fundamentally solves the dirty read problem caused by transaction fragmentation in traditional solutions.

[0089] As an optional embodiment, the intercepted business method carrying the asynchronous execution annotation (@AsyncExec) includes:

[0090] In the component initialization phase, scan the asynchronous execution annotation, generate a proxy object and cache it;

[0091] Scan specific annotations in the initialization phase, dynamically generate proxy objects, and reduce runtime overhead by caching proxy objects.

[0092] Intercept the business method carrying the asynchronous execution annotation through the aspect logic (AsyncAspect), and publish the asynchronous event (AsyncEvent) carrying the parameters and the policy type (AsyncExecEnum).

[0093] Declare the surrounding notification aspect, execute the original business method through pjp.proceed(), create the asynchronous event object carrying the parameters through publisher.publishEvent, intercept the method call marked by the annotation, so as to realize the separation of business logic and asynchronous processing logic.

[0094] The embodiment scans and caches the proxy object of the asynchronous execution annotation in the component initialization stage, realizes the preloading of the routing logic, intercepts the annotated method through the aspect, and publishes the parameter event, so as to decouple the asynchronous triggering logic and the business code. The dynamic proxy mechanism enables the business method to obtain the asynchronous capability only by declaring the annotation, without modifying the core logic or coupling the retry / queue management code, in line with the open-closed principle, and significantly reduces the code maintenance cost of functional expansion.

[0095] Please refer to Figure 4 , Figure 4 The flowchart of the transaction event listening-based non-invasive asynchronous processing method provided by an embodiment of the present application shows that the target method is executed immediately after the transaction is submitted (the asynchronous execution annotation is @AsyncExec (type=AsyncExecEnum.IMMEDIATE)), if the execution fails, the exception stack is recorded to the async_log table, the state of the async_req table is updated to exec_status=1, and the timing retry process is triggered.

[0096] Please refer to Figure 5 , Figure 5 The flowchart of the transaction event listening-based non-invasive asynchronous processing method provided by an embodiment of the present application shows that the asynchronous message processing fails first and then the database is saved. First, the asynchronous message is sent after the transaction is submitted, if the message sending fails, it is directly stored to the async_req table and marked as exec_status=1 (failure), and the timing retry mechanism (XXL-JOB) scans the failure record.

[0097] Therefore, as an optional embodiment, the routing operation is performed according to the policy type (AsyncExecEnum) declared in the asynchronous execution annotation, and immediate execution or on-demand execution is performed, which includes:

[0098] When the immediate policy (AsyncExecEnum.IMMEDIATE) is declared in the asynchronous execution annotation, the request is routed to the immediate execution module to directly call the target method.

[0099] When the persistence strategy (AsyncExecEnum.SAVE_ASYNC) is declared in the asynchronous execution annotation, the request data (AsyncReq) is sent to the message queue (Kafka retry_queue), stored in the asynchronous request table (async_req), and marked as an initial state of failure (exec_status=1).

[0100] In a specific implementation, the strategy execution interface specification is defined through AsyncStrategy, the specific retry queue strategy is implemented through SaveAsyncRetryStrategy, and the task is sent to the message middleware through kafkaTemplate.send(), thereby providing an extensible asynchronous processing strategy framework.

[0101] The embodiment implements differentiated routing according to the strategy type: for the instant strategy, the target method is directly called synchronously, and the intermediate link is reduced to improve the processing timeliness of high-priority tasks; for the persistence strategy, the request data is sent to the message queue and initially marked as a failure state, and the task persistence and sequential consumption are guaranteed through the message middleware. The strategy routing design takes into account the real-time and reliability requirements, and solves the limitation that the single execution mode in the traditional scheme cannot adapt to multiple business scenarios.

[0102] Please refer to Figure 6 , Figure 6 The general flowchart of the non-invasive asynchronous processing method based on transaction event listening provided by an embodiment of the present application is shown. After the transaction is submitted, the listener (@TransactionalEventListener) is triggered, then the @AsyncExec annotation is parsed, the strategy routing (instant execution / persistence queue) is triggered, the failed tasks enter the three-level fault tolerance (instant marking-timed retry-manual platform intervention), and the full-link data (async_req+async_log) is displayed through the management platform.

[0103] The application establishes a transaction-task link through a @TransactionalEventListener in an event listening layer in an asynchronous aspect step, and realizes business zero-invasion through an @Around aspect in a routing agent layer. In an asynchronous strategy step, the application supports multiple processing channels through an AsyncStrategy interface of a strategy execution layer. In an asynchronous compensation step, a fault-tolerant persistence layer is designed to realize a closed-loop fault-tolerant system through an asynchronous task table + timing scheduling + manual platform. Meanwhile, the application designs a data isolation layer to realize event link tracking and state monitoring through an independent data persistence structure. In any execution step, if an abnormal condition occurs, such as locking or a user identity not meeting a preset condition, an alarm mechanism can be triggered at any time. The application provides a transaction event listening + closed-loop fault-tolerant dual-engine architecture to realize a transaction-safe asynchronous triggering mechanism, atomic coordination of asynchronous tasks and transactions (solving a timing problem), a non-invasive architecture design, physical decoupling of business logic and an asynchronous mechanism (solving an invasive problem), a three-level closed-loop fault-tolerant system, seamless connection of automatic bottom-up and manual intervention (achieving data consistency), and breakthroughs in reliability, maintainability, and observability.

[0104] The application embodiment further provides a non-invasive asynchronous processing device based on transaction event listening.

[0105] The processing module is configured to trigger an asynchronous event through a transaction event listener after a database transaction is committed.

[0106] The processing module is further configured to intercept a business method carrying an asynchronous execution annotation, extract method parameters, and generate an asynchronous request event.

[0107] The processing module is further configured to perform routing operation according to a policy type declared in the asynchronous execution annotation, and perform immediate execution or on-demand execution.

[0108] The transaction event listener triggers an asynchronous event after a database transaction is committed, ensures that asynchronous operations strictly follow a transaction life cycle, and avoids data inconsistency risks caused by thread pool tasks and transaction timing misalignment in a traditional solution from the root; the business method carrying the asynchronous execution annotation is intercepted, parameters are automatically extracted, and an asynchronous request event is generated, physical isolation of business logic and an asynchronous mechanism is realized, and architecture pollution is eliminated; further, the policy type declared in the annotation is dynamically routed to an immediate execution or persistent execution module to provide elastic execution capability for different business scenarios. Thus, a zero-invasive and extensible asynchronous processing framework is constructed under the premise of ensuring transaction atomicity, and system reliability and maintainability are significantly improved.

[0109] As an optional implementation, the device further includes a data module configured to:

[0110] Event link tracking and state monitoring through data persistence structure;

[0111] The data persistence structure comprises:

[0112] Method signature, policy type and queue name are stored through asynchronous scenario table;

[0113] Request parameters, execution state and retry count are recorded through asynchronous request table;

[0114] Exception stack is stored through asynchronous log table in association with event situation.

[0115] The embodiment stores metadata such as method signature and policy type through asynchronous scenario table, establishes a standardized description system of asynchronous tasks, records full-link execution state and retry count through asynchronous request table, realizes visual management of task life cycle, and further forms a closed-loop diagnosis link through asynchronous log table in association with exception stack information. The data persistence structure provides a unified data base for event tracking and state monitoring, solves the problem of black box of asynchronous link in the traditional scheme, and greatly reduces the complexity of fault positioning and analysis.

[0116] As an optional embodiment, the processing module is further configured to:

[0117] Repairing the event of execution failure according to a three-level fault-tolerant process;

[0118] The three-level fault-tolerant process comprises:

[0119] First-level fault tolerance: after immediate execution failure, marking the execution state of the corresponding event as failed in the asynchronous request table;

[0120] Second-level fault tolerance: scanning the records of the asynchronous request table in which the execution state is failed and the retry count is not over limit through a timing event engine, retrying, and triggering a third-level fault-tolerant mechanism when the retry count is over limit;

[0121] Third-level fault tolerance: retrying execution, modifying parameters and querying error logs through a preset management and control platform.

[0122] The embodiment designs a three-level progressive fault-tolerant mechanism: the first level marks the state after immediate execution failure, realizes fast failure response; the second level automatically retries the failure tasks that are not over limit through a timing engine, guarantees self-repair of regular exceptions; and the third level transfers the tasks to the management and control platform after retrying over limit, supports manual intervention and parameter adjustment. The mechanism builds a closed-loop fault-tolerant system of "automatic repair as the main and manual backup as the auxiliary", solves the operation and maintenance problem of manual script compensation after task failure in the traditional scheme, and significantly improves the system resilience and data final consistency guarantee capability.

[0123] As an optional implementation, the specific manner in which the processing module implements the transaction event listener includes:

[0124] The transaction event listener is configured to respond to an event in a transaction completion phase.

[0125] A callback operation is registered through a transaction synchronizer, and an asynchronous event is blocked until a transaction operation is completed.

[0126] The transaction event listener is configured to respond to an event in a transaction completion phase in the embodiment, and the asynchronous triggering timing is strictly bound to the end of a transaction life cycle. Further, a callback operation is registered through a transaction synchronizer, and an asynchronous event is forced to wait until a transaction operation is completed. The double timing control mechanism completely eliminates the risk of reading intermediate state data by an asynchronous task before a transaction is committed, and fundamentally solves the dirty read problem caused by transaction fragmentation in the traditional solution.

[0127] As an optional implementation, the specific manner in which the processing module intercepts a business method carrying an asynchronous execution annotation includes:

[0128] In a component initialization phase, an asynchronous execution annotation is scanned, a proxy object is generated and cached;

[0129] A business method carrying an asynchronous execution annotation is intercepted through aspect logic, and an asynchronous event carrying parameters and a strategy type is published.

[0130] In the embodiment, an asynchronous execution annotation is scanned and cached in a component initialization phase, and a proxy object is generated, so that the preloading of routing logic is realized. The asynchronous triggering logic is decoupled from business code by intercepting an annotated method through an aspect and publishing a parameterized event. The dynamic proxy mechanism enables a business method to obtain asynchronous capability only by declaring an annotation, without modifying core logic or coupling retry / queue management code, in compliance with the open-closed principle, and significantly reduces the code maintenance cost of functional expansion.

[0131] As an optional implementation, the specific manner in which the processing module performs routing operation according to the strategy type declared in the asynchronous execution annotation includes:

[0132] When an instant strategy is declared in the asynchronous execution annotation, a request is routed to an instant execution module to directly call a target method.

[0133] When a persistence strategy is declared in the asynchronous execution annotation, request data is sent to a message queue, and stored in an asynchronous request table and marked as failed in initial execution state.

[0134] The embodiment implements differentiated routing according to the policy type: for instant policies, a direct synchronous call target method is used to reduce intermediate links to improve the processing timeliness of high-priority tasks; for persistent policies, request data is sent to a message queue and initially marked as a failure state, and a message middleware is used to ensure task persistence and sequential consumption. The policy-based routing design takes into account the real-time and reliability requirements, and solves the limitations of the single execution mode in the traditional solution that cannot adapt to multiple business scenarios.

[0135] It should be noted that the division of each module of the above device is only a logical functional division, and all or part of it can be integrated into a physical entity, or physically separated. And these modules can all be implemented in the form of software called by the processing element; all can be implemented in the form of hardware; some modules can be implemented in the form of software called by the processing element, and some modules can be implemented in the form of hardware. For example, the processing module can be a separately established processing element, or it can be integrated into a chip of the above device, and in addition, it can also be stored in the form of program code in the memory of the above device, and the function of the above determination module is called and executed by a processing element of the above device. The implementation of other modules is similar. In addition, all or part of these modules can be integrated together, or can be independently implemented. The processing element here can be an integrated circuit with signal processing capability. In the implementation process, each step of the above method or each module can be completed by the integrated logic circuit of the hardware in the processor element or the instruction in the form of software.

[0136] Schematically, as Figure 7 shown, Figure 7 An internal structure schematic diagram of a computer device provided by an embodiment of the present application is shown in FIG. 3. The computer device 300 can be provided as a server. Referring to Figure 7 , the computer device 300 includes a processing component 302, which further includes one or more processors, and a memory resource represented by a memory 301, for storing instructions executable by the processing component 302, such as an application program. The application program stored in the memory 301 can include one or more than one module each corresponding to a set of instructions. In addition, the processing component 302 is configured to execute the instructions to perform the method of any of the above embodiments.

[0137] The computer device 300 can further include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 can operate based on an operating system stored in the memory 301, such as Windows Server TM, Mac OS X TM, Unix TM, Linux TM, Free BSD TM, or the like.

[0138] Those skilled in the art can understand that, Figure 7 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. A specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0139] The embodiment of the present application provides a storage medium, the storage medium stores computer readable instructions, and the computer readable instructions are executed by one or more processors to make the one or more processors execute the method provided by any one of the embodiments.

[0140] Finally, it should be noted that in this document, relational terms such as first and second and the like can only be used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the terms "comprises", "comprising", or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or apparatus that includes a list of elements does not only include those elements, but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without more limitations, an element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0141] The embodiments in the specification are described in a progressive manner, and each embodiment focuses on the difference from other embodiments. Each embodiment can be combined as needed, and the same and similar parts refer to each other.

[0142] The foregoing description of the disclosed embodiments enables a person skilled in the art to make or use the application. Modifications of these embodiments will occur to persons of skill in the art, and that the generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the application. Therefore, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A non-intrusive asynchronous processing method based on transaction event monitoring, characterized in that, The method includes: After a database transaction is committed, an asynchronous event is triggered through a transaction event listener; Intercept business methods with asynchronous execution annotations, extract method parameters, and generate asynchronous request events; Based on the strategy type declared in the asynchronous execution annotation, a routing operation is performed to execute either immediately or on demand.

2. The method according to claim 1, characterized in that, The method further includes: Event chain tracing and status monitoring are performed through persistent data structures; The data persistence structure includes: The method signature, strategy type, and queue name are stored in an asynchronous scenario table. The asynchronous request table records request parameters, execution status, and retry count. The exception stack is stored by associating event information with an asynchronous log table.

3. The method according to claim 2, characterized in that, The method further includes: Events that fail to execute are repaired according to a three-level fault tolerance process; The three-level fault-tolerant process includes: Level 1 fault tolerance: If execution fails immediately, mark the corresponding event execution status as failed in the asynchronous request table; Level 2 fault tolerance: Through the timed event engine, scan the records in the asynchronous request table whose execution status is failed and whose retry count has not exceeded the limit, and retry them. When the retry count exceeds the limit, the Level 3 fault tolerance mechanism is triggered. Level 3 fault tolerance: Retry execution, parameter modification, and error log query are performed through a preset management and control platform.

4. The method according to claim 1, characterized in that, The transaction event listener can be implemented in the following ways: Configure a transaction event listener to respond to events during the transaction completion phase; Register callback operations through the transaction synchronizer to block asynchronous events until the transaction operation is completed.

5. The method according to claim 1, characterized in that, The interception of business methods carrying asynchronous execution annotations includes: During the component initialization phase, asynchronous annotations are scanned, proxy objects are generated and cached; Intercept business methods that carry asynchronous execution annotations through aspect logic, and publish asynchronous events carrying parameters and strategy types.

6. The method according to claim 2, characterized in that, The step of performing routing operations based on the strategy type declared in the asynchronous execution annotation, and performing immediate or on-demand execution, includes: When an immediate strategy is declared in the asynchronous execution annotation, the request is routed to the immediate execution module to directly call the target method. When a persistence strategy is declared in the asynchronous execution annotation, the request data is sent to the message queue, stored in the asynchronous request table, and the initial execution status is marked as failed.

7. A non-intrusive asynchronous processing device based on transaction event monitoring, characterized in that, The device includes: The processing module is used to trigger asynchronous events through a transaction event listener after a database transaction is committed. The processing module is also used to intercept business methods carrying asynchronous execution annotations, extract method parameters, and generate asynchronous request events; The processing module is also used to perform routing operations based on the strategy type declared in the asynchronous execution annotation, and to perform immediate execution or on-demand execution.

8. The apparatus according to claim 7, characterized in that, The device further includes a data module for: Event chain tracing and status monitoring are performed through persistent data structures; The data persistence structure includes: The method signature, strategy type, and queue name are stored in an asynchronous scenario table. The asynchronous request table records request parameters, execution status, and retry count. The exception stack is stored by associating event information with an asynchronous log table.

9. A computer device, characterized in that, The method includes one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method as described in any one of claims 1-6.

10. A storage medium, characterized in that, The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method as described in any one of claims 1-6.

Images