Asynchronous call control method and related device

Abstract

The invention discloses an asynchronous call control method and a related device, and relates to the field of asynchronous processing. When the first processing system outputs the asynchronous call instruction, the asynchronous call instruction is directly intercepted, and at the moment, the second processing system executing the asynchronous call instruction does not execute the asynchronous call task due to the fact that the asynchronous call instruction is not received. Under the condition that it is determined that the first processing system generates the target data needed by the asynchronous calling instruction, the asynchronous calling instruction and the target data needed by the asynchronous calling instruction are packaged into an asynchronous calling task, the asynchronous calling task is sent to a second processing system, and the second processing system executes the asynchronous calling task. When the second processing system executes the asynchronous calling task, the target data required by the asynchronous calling task is generated, so that the second processing system can be ensured to normally execute the asynchronous calling task by using the target data, and the problem that the asynchronous calling task cannot be normally executed due to the absence of the target data is avoided.

Description

Technical Field

[0001] The present application relates to the field of asynchronous processing, and more specifically, to an asynchronous call control method and related devices. Background Art

[0002] A local transaction is a transaction executed in a single database system, usually involving operations on a single data source, and does not require coordination by a global transaction manager. The main feature of a local transaction is that it only operates within a service or application and does not involve cross-service operations.

[0003] In order to improve the performance of local transaction processing, the database system can be allowed to asynchronously call other systems to perform some tasks when executing local transactions. Take system A as the database system that executes local transactions. During the execution of local transactions by system A, it will asynchronously call systems B, C, and D to process some tasks. During the process of processing tasks by systems B, C, and D, system B may need some data from system A. If system A has not generated the data, system B will not be able to process the task normally, reducing the reliability of asynchronous task processing. Summary of the invention

[0004] In view of this, the present application provides an asynchronous call control method and related devices to improve the reliability of asynchronous task processing.

[0005] In order to solve the above technical problems, this application adopts the following technical solutions:

[0006] An asynchronous call control method, comprising:

[0007] Intercepting the asynchronous call instruction output by the first processing system;

[0008] In a case where it is determined that the first processing system generates the target data required by the asynchronous call instruction, encapsulating the asynchronous call instruction and the target data required by the asynchronous call instruction into an asynchronous call task;

[0009] Adding the asynchronous call task and the target data required by the asynchronous call instruction to an asynchronous task table, and setting the execution state of the asynchronous call task in the asynchronous task table to a first state;

[0010] Sending the asynchronous call task to a second processing system so that the second processing system executes the asynchronous call task;

[0011] Based on the progress of the second processing system in executing the asynchronous call task, the execution status of the asynchronous call task in the asynchronous task table is adjusted.

[0012] Optionally, intercepting the asynchronous call instruction output by the first processing system to obtain the asynchronous call task includes:

[0013] Set the interception content in the interception operation to be asynchronous;

[0014] Acquiring output data of the first processing system;

[0015] If the output data is an asynchronous call instruction related to an asynchronous call, an interception operation is performed on the asynchronous call instruction.

[0016] Optionally, sending the asynchronous call task to the second processing system includes:

[0017] Performing a monitoring operation on the asynchronous task table, so as to convert the asynchronous call task into a target message when an insertion event of adding the asynchronous call task to the asynchronous task table is detected;

[0018] The target message is stored in a message queue, so that the second processing system obtains the asynchronous call task by monitoring the message queue.

[0019] Optionally, sending the asynchronous call task to the second processing system includes:

[0020] After detecting that the first processing system outputs the asynchronous call task to the thread pool, the asynchronous call task is sent to the second processing system using threads in the thread pool.

[0021] Optionally, adjusting the execution state of the asynchronous call task in the asynchronous task table based on the progress of the asynchronous call task executed by the second processing system includes:

[0022] During the process of the second processing system executing the asynchronous call task, setting the execution state of the asynchronous call task in the asynchronous task table to running;

[0023] In the case where the second processing system executes the asynchronous call task abnormally, setting the execution state of the asynchronous call task in the asynchronous task table to abnormal;

[0024] When the second processing system abnormally executes the asynchronous call task for a specified number of times, setting the execution state of the asynchronous call task in the asynchronous task table to failure;

[0025] When the second processing system successfully executes the asynchronous call task, the execution status of the asynchronous call task in the asynchronous task table is set to success.

[0026] Optionally, after adjusting the execution state of the asynchronous call task in the asynchronous task table based on the progress of the asynchronous call task executed by the second processing system, the method further includes:

[0027] Periodically obtain asynchronous call tasks with abnormal execution status, and use the obtained asynchronous call tasks as target asynchronous call tasks;

[0028] The target asynchronous call task is sent to the second processing system again so that the second processing system executes the target asynchronous call task until the second processing system successfully executes the target asynchronous call task, or stops when the number of abnormal executions of the target asynchronous call task is greater than a preset threshold.

[0029] An asynchronous call control device, comprising:

[0030] An interception module, used for intercepting the asynchronous call instruction output by the first processing system;

[0031] a task encapsulation module, configured to encapsulate the asynchronous call instruction and the target data required by the asynchronous call instruction into an asynchronous call task when it is determined that the first processing system generates the target data required by the asynchronous call instruction;

[0032] A data adding module, used for adding the asynchronous call task and the target data required by the asynchronous call instruction to an asynchronous task table, and setting the execution state of the asynchronous call task in the asynchronous task table to a first state;

[0033] A task sending module, used for sending the asynchronous call task to the second processing system, so that the second processing system executes the asynchronous call task;

[0034] The state adjustment module is used to adjust the execution state of the asynchronous call task in the asynchronous task table based on the progress of the asynchronous call task executed by the second processing system.

[0035] Optionally, the interception module includes:

[0036] The content setting submodule is used to set the interception content in the interception operation to be asynchronous;

[0037] A data acquisition submodule, used to acquire output data of the first processing system;

[0038] The interception submodule is used to intercept the asynchronous call instruction if the output data is an asynchronous call instruction related to the asynchronous call.

[0039] An electronic device comprises at least one processor and a memory connected to the processor, wherein:

[0040] The memory is used to store computer programs;

[0041] The processor is used to execute the computer program so that the electronic device can implement the above-mentioned asynchronous call control method.

[0042] A computer storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement the above-mentioned asynchronous call control method.

[0043] The present application provides an asynchronous call control method and related devices. In the present application, when the first processing system outputs an asynchronous call instruction, the asynchronous call instruction is directly intercepted. At this time, the second processing system that executes the asynchronous call instruction will not execute the asynchronous call task because it has not received the asynchronous call instruction. In the case of determining that the first processing system generates the target data required for the asynchronous call instruction, the asynchronous call instruction and the target data required for the asynchronous call instruction are encapsulated as an asynchronous call task, and the asynchronous call task is sent to the second processing system so that the second processing system executes the asynchronous call task. Since the target data required for the asynchronous call task has been generated when the second processing system executes the asynchronous call task, it can be ensured that the second processing system uses the target data to normally execute the asynchronous call task, thereby avoiding the problem that the asynchronous call task cannot be executed normally due to the non-existence of the target data when executing the asynchronous call task. In addition, in the present application, the asynchronous call task and the target data required by the asynchronous call instruction are added to the asynchronous task table, the execution status of the asynchronous call task in the asynchronous task table is set to the first state, and based on the progress of the second processing system executing the asynchronous call task, the execution status of the asynchronous call task in the asynchronous task table is adjusted. The execution progress of the asynchronous call task can be monitored in real time, so that corresponding maintenance operations can be performed in time when the asynchronous call task is executed abnormally. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0045] Figure 1 A flowchart of an asynchronous call control method provided in an embodiment of the present application;

[0046] Figure 2 A flowchart of an asynchronous call task provided in an embodiment of the present application;

[0047] Figure 3 A subscription diagram of an asynchronous call control method provided in an embodiment of the present application;

[0048] Figure 4 A schematic diagram of an asynchronous call control method provided in an embodiment of the present application;

[0049] Figure 5 A schematic diagram of an error retry of an asynchronous call control method provided by an embodiment of the present application;

[0050] Figure 6 A schematic diagram of the structure of an asynchronous call control device provided in an embodiment of the present application;

[0051] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0053] In order for those skilled in the art to understand the present invention more clearly, the professional terms in the present invention are now explained.

[0054] Transaction generally refers to something to be done or done. In computer terms, it refers to a program execution unit that accesses and possibly updates various data items in a database. Transactions are usually caused by the execution of user programs written in high-level database manipulation languages ​​or programming languages ​​(such as SQL (Structured Query Language), C++ or Java), and are defined by statements (or function calls) such as begin transaction and end transaction. A transaction consists of all operations performed between the start and end of a transaction.

[0055] A local transaction is a transaction executed in a single database system, usually involving operations on a single data source, and does not require coordination by a global transaction manager. The main feature of a local transaction is that it only operates within a service or application and does not involve cross-service operations.

[0056] Asynchronous execution mode means that the order in which statements are executed is not necessarily the same as the order in which they are started. Asynchronous execution mode allows applications to break free from the constraints of a single task, improving flexibility and application execution efficiency.

[0057] Spring framework (JAVA language framework technology) is an open source J2EE (JAVA 2 Platform Enterprise Edition, enterprise-level application development) application framework. It is a lightweight container that manages the life cycle of beans (the basic components of Spring applications). Spring solves many common problems encountered by developers in J2EE development, and provides powerful functions such as IOC (Inversion of Control, dependency injection), AOP (Aspect Oriented Programming, aspect-oriented programming) and Web MVC (Web Model View Controller, three-tier architecture). Spring can be used alone to build applications, or it can be used in combination with many Web frameworks such as Struts (Web application framework), Webwork (Web application framework), Tapestry (Web application framework), and can be combined with desktop application AP (Application Programming, application) such as Swing. Therefore, Spring can be used not only in J2EE applications, but also in desktop applications and small applications. The Spring framework is mainly composed of seven parts, namely Spring Core (core module), Spring AOP, Spring ORM (Object Relational Mapping), Spring DAO, Spring Context, Spring Web and Spring Web MVC.

[0058] Spring Boot (a Spring-based rapid development framework) is designed to simplify the initial setup and development of new Spring applications. The framework uses a specific way to configure, so that developers no longer need to define boilerplate configurations. In this way, Spring Boot is committed to becoming a leader in the booming field of rapid application development.

[0059] In order to improve the performance of local transaction processing, you can allow the database system to asynchronously call other systems to perform some tasks when executing local transactions. When making asynchronous calls, you can achieve asynchrony by replicating the Fork thread or directly using Spring's @Async annotation. However, it should be noted that when using Spring's JDBC (Java Database Connectivity) transaction, once a new thread is forked, it will be out of the scope of the original transaction, making the transaction of the new thread no longer belong to the same transaction as the original transaction, and losing the reliability and consistency of the JDBC transaction.

[0060] Reliability means that after the asynchronous task is created and the local transaction is successfully submitted, the asynchronous task will be executed, regardless of whether there are abnormal situations or unexpected factors such as service restart, and at least once (At-Least-Once) semantics can always be guaranteed. Consistency means that the internal business logic of the asynchronous method is consistent with the transaction context when the asynchronous method is called. When the local transaction is committed, the asynchronous task is executed. When the local transaction is rolled back, the asynchronous task will not be executed.

[0061] In addition, you can also use in-process event notifications: tool event Guava Event and observer mode event Spring Event to implement asynchronous calls. Both essentially implement the publish-subscribe model and can be used to implement asynchronous calls. Guava Event provides synchronous and asynchronous event publishing, and its implementation is based on queues and thread pools. SpringEvent configures Spring Async to support asynchronous operations, and also provides @TransactionEventListener (transaction event listener) to publish events at different stages of the current transaction. However, the underlying layer is still essentially a forked thread. Once a new thread is forked, it will be out of the scope of the original transaction, so that the transaction of the new thread no longer belongs to the same transaction as the original transaction, so it will lose the transaction characteristics, so that the transaction of the new thread no longer belongs to the same transaction as the original transaction, and the success and failure of the transaction cannot be guaranteed.

[0062] The Outbox Pattern is a common technical paradigm based on the Guaranteed Delivery mode in microservice scenarios, which aims to achieve reliable message delivery. It is mainly used to solve the reliability and consistency problems of the interaction between applications and external applications. Therefore, in this embodiment, the Outbox Pattern can be used for asynchronous calls.

[0063] When using the Outbox Pattern for asynchronous calls, the database system that executes local transactions is system A. During the execution of local transactions, system A will asynchronously call systems B, C, and D to process some tasks. Data inconsistency problems may occur during the asynchronous call. A typical example is the timeliness problem of local transactions and asynchronous calls. The data of the current transaction is often queried during the asynchronous call, but the current transaction may not be submitted, so there will be problems such as the query data not existing. For example, during the process of processing tasks by systems B, C, and D, system B may need some data from system A. If system A has not generated the data, system B will not be able to process the task normally, reducing the reliability of asynchronous task processing. More specifically, in a scenario, system A inserts personnel data, and then asynchronously notifies business system B that the data has changed. System B calls the interface of system A to query the personnel data, but the personnel data cannot be queried. The root cause is the problem of the order of inserting data and asynchronous notification. The transaction of inserting personnel data may not be submitted yet. At this time, the asynchronous notification system B query cannot find the data.

[0064] Therefore, in the embodiment of the present application, the processing logic of the Outbox Pattern is improved to avoid the problem that the asynchronous call cannot be executed normally due to lack of data during the asynchronous call.

[0065] Specifically, in order to solve the problem that the asynchronous call cannot be executed normally due to lack of data, in an embodiment of the present application, when the first processing system outputs the asynchronous call instruction, the asynchronous call instruction is directly intercepted. At this time, the second processing system that executes the asynchronous call instruction will not execute the asynchronous call task because it has not received the asynchronous call instruction. In the case of determining that the first processing system generates the target data required for the asynchronous call instruction, the asynchronous call instruction and the target data required for the asynchronous call instruction are encapsulated as an asynchronous call task, and the asynchronous call task is sent to the second processing system so that the second processing system executes the asynchronous call task. Since the target data required for the asynchronous call task has been generated when the second processing system executes the asynchronous call task, it can ensure that the second processing system uses the target data to execute the asynchronous call task normally, thereby avoiding the problem that the asynchronous call task cannot be executed normally due to the non-existence of the target data when executing the asynchronous call task. In addition, in the present application, the asynchronous call task and the target data required by the asynchronous call instruction are added to the asynchronous task table, the execution status of the asynchronous call task in the asynchronous task table is set to the first state, and based on the progress of the second processing system executing the asynchronous call task, the execution status of the asynchronous call task in the asynchronous task table is adjusted. The execution progress of the asynchronous call task can be monitored in real time, so that corresponding maintenance operations can be performed in time when the asynchronous call task is executed abnormally.

[0066] Based on the above content, an embodiment of the present application provides an asynchronous call control method, and the execution subject can be a database system that executes local transactions, such as the device where the above-mentioned A system is located. In addition, it can also be a processor for performing asynchronous calls set between the A, B, C, and D systems.

[0067] Reference Figure 1 , an asynchronous call control method may include:

[0068] S11. Intercept the asynchronous call instruction output by the first processing system.

[0069] In this embodiment, the essence of asynchrony is a fire-and-forget mode, which is commonly used in two scenarios in programming:

[0070] Improve the response speed of requests and reduce unnecessary synchronous waiting time. By executing certain operations asynchronously, you can avoid long blocking waits during request processing, thereby improving the system's throughput and response performance.

[0071] Realize logical decoupling and decouple pure real-time logic from non-linear non-real-time logic. In event-driven scenarios, asynchronous mechanisms are often widely used. By processing events asynchronously, real-time logic can be separated from non-real-time logic, improving the maintainability and scalability of the system.

[0072] The use of asynchronous programming patterns can bring many benefits, such as improving system performance, improving user experience, and enhancing system stability and scalability.

[0073] When performing asynchronous processing, it can be implemented through asynchronous call instructions between systems. In the embodiment of the present application, the first processing system can be a database system that executes local transactions, such as the above-mentioned system A. In the process of executing local transactions, system A will asynchronously call systems B, C, and D to process some tasks to improve the processing efficiency of local transactions.

[0074] For example, system A calls system B to perform a first task, system A calls system C to perform a second task, and system A calls system D to perform a third task.

[0075] In actual scenarios, system A can send asynchronous call instructions to B, C, and D. When B, C, and D perform corresponding tasks, they need some data from system A. If system A has not generated these data, B, C, and D will not be able to perform tasks normally.

[0076] To this end, in an embodiment of the present application, if system A sends an asynchronous call instruction to B, C, and D, the asynchronous call instruction will be intercepted, and B, C, and D will not receive the asynchronous call instruction. After the target data required for the subsequent asynchronous call task is generated, the target data will be sent to B, C, and D together with the step call instruction.

[0077] In one implementation, spring transactions are controlled based on the AOP dynamic proxy mechanism, and Spring AOP can be used to implement interception operations through proxy calls.

[0078] At this time, the asynchronous call instruction output by the first processing system is intercepted to obtain an asynchronous call task, including:

[0079] 1) Set the interception content in the interception operation to asynchronous.

[0080] When intercepting, you can use the method that marks the custom annotation as asynchronous to intercept. The custom annotation can be @AsyncExec. The @AsyncExec annotation is used to mark the method that needs to be executed asynchronously. Only the method marked with this annotation will be intercepted.

[0081] The @AsyncExec annotation defines several properties:

[0082] 1. Task name;

[0083] 2. Task description;

[0084] 3. Mark whether the task is executed asynchronously or synchronously. The default is asynchronous execution.

[0085] 4. Thread pool (only required when marked as asynchronous execution);

[0086] After configuring @AsyncExec, the aspect class AsyncExec, such as AsyncExecAspect, can intercept methods annotated with @AsyncExec. The main functions of AsyncExecAspect are as follows:

[0087] 1. Build an asynchronous execution entity;

[0088] 2. Insert an asynchronous task record into the asynchronous task table in the current transaction;

[0089] 3. Get the thread pool for asynchronous execution;

[0090] 4. If there is a transaction currently, register the hook after the transaction is submitted and execute the business operation asynchronously;

[0091] 5. If there is no transaction currently, the business operation is performed asynchronously.

[0092] 2) Obtaining output data of the first processing system.

[0093] In this embodiment, the output interface of the first processing system may be monitored, and when the first processing system outputs data, the output data may be acquired.

[0094] 3) If the output data is an asynchronous call instruction related to an asynchronous call, an interception operation is performed on the asynchronous call instruction.

[0095] Specifically, when using Spring AOP to intercept data, if the output data is an asynchronous call instruction related to the asynchronous call, that is, the instruction is intercepted, then B, C, and D will not receive the asynchronous call instruction.

[0096] The asynchronous call instruction may be an instruction for calling a certain system to execute a certain task. For example, the asynchronous call instruction may be for system A to call system B to execute a first task.

[0097] S12: When it is determined that the first processing system generates target data required by the asynchronous call instruction, encapsulate the asynchronous call instruction and the target data required by the asynchronous call instruction into an asynchronous call task.

[0098] Among them, the target data required by the asynchronous call instruction needs to be pre-configured, such as the task corresponding to a certain asynchronous call instruction requires data a, b, and c.

[0099] In this embodiment, the data of the first processing system can be monitored. Specifically, the target data required to generate the asynchronous call instruction can correspond to a transaction. By registering a transaction hook, it is possible to monitor whether the transaction is submitted. If it is submitted, it means that the first processing system generates the target data required for the asynchronous call instruction. If it is not submitted and an exception occurs, the exception can be eliminated by rolling back.

[0100] If it is found that the first processing system generates the target data required by the asynchronous call instruction, a data encapsulation operation is performed. When performing the encapsulation operation, TransactionAsyncAspect can be used to encapsulate the asynchronous call instruction intercepted based on @AsyncExec and the target data required by the asynchronous call instruction into an asynchronous execution entity, and the asynchronous execution entity can be an Invocation entity class.

[0101] The input parameters in the asynchronous call task include the asynchronous call instruction, the target data required by the asynchronous call instruction, etc.

[0102] S13: Add the asynchronous call task and the target data required by the asynchronous call instruction to an asynchronous task table, and set the execution state of the asynchronous call task in the asynchronous task table to the first state.

[0103] In this embodiment, in order to effectively track the life cycle of asynchronous call tasks, Spring AOP and database can be used to perform state management on asynchronous call tasks. To this end, an asynchronous task table is pre-configured in the database of local transactions, and the asynchronous task table is used to record the task data, task execution status, etc. of the asynchronous call tasks.

[0104] The code to create an asynchronous task table can be as follows:

[0105] SQLCREATE TABLE `async_task` (

[0106] `id` BIGINT ( 20 ) NOT NULL AUTO_INCREMENT COMMENT 'Primary key Id',

[0107] `task_name` VARCHAR ( 200 ) NOT NULL COMMENT 'Task name',

[0108] `task_desc` VARCHAR ( 500 ) NOT NULL DEFAULT '' COMMENT 'Task description',

[0109] `trance_point_code` VARCHAR ( 500 ) NOT NULL DEFAULT '' COMMENT 'Task code: trance point code',

[0110] `sign` VARCHAR ( 50 ) NOT NULL DEFAULT '' COMMENT 'Method signature',

[0111] `class_name` VARCHAR ( 500 ) NOT NULL DEFAULT '' COMMENT 'Full path class name',

[0112] `method_name` VARCHAR ( 500 ) NOT NULL COMMENT 'Method name',

[0113] `args` json NOT NULL COMMENT 'parameters',

[0114] `status` TINYINT ( 4 ) NOT NULL COMMENT 'Task status: 0-READY, 1-RUNNING, 2-EXCEPTION, 3-FAIL, 4-SUCCESS',

[0115] `retry_count` TINYINT ( 4 ) NOT NULL DEFAULT '0' COMMENT 'Number of retries',

[0116] `remark` VARCHAR ( 500 ) NOT NULL DEFAULT '' COMMENT 'Task Remarks',

[0117] `create_time` datetime NOT NULL COMMENT 'Creation time',

[0118] `update_time` datetime NOT NULL COMMENT 'Update time',

[0119] PRIMARY KEY ( `id` )

[0120] ) ENGINE = INNODB DEFAULT CHARSET = utf8mb4 COMMENT = 'Asynchronous task table';

[0121] CREATE TABLE `async_log` (

[0122] `id` BIGINT ( 20 ) NOT NULL AUTO_INCREMENT COMMENT 'Primary key Id',

[0123] `async_task_id` BIGINT ( 20 ) NOT NULL COMMENT 'Asynchronous task primary key ID',

[0124] `error_data` LONGTEXT NOT NULL COMMENT 'Execution error message',

[0125] `create_time` datetime NOT NULL COMMENT 'Creation time',

[0126] PRIMARY KEY ( `id` ),

[0127] KEY `idx_async_task_id` ( `async_task_id` ) USING BTREE COMMENT 'Asynchronous task table primary key Id'

[0128] ) ENGINE = INNODB DEFAULT CHARSET = utf8mb4 COMMENT = 'Asynchronous task log table'.

[0129] In one implementation, the asynchronous task table may be set as a read-only table, in which case only task records are allowed to be inserted into the table, and modification operations on the table are not allowed.

[0130] After encapsulating the asynchronous call task, within the current transaction, AsyncExecAspect persists the asynchronous call task (specifically, the asynchronous task description information (such as target class, method name, parameters, etc.) and the target data required by the asynchronous call instruction to the asynchronous task table of the database.

[0131] In addition, an asynchronous task state machine is set for the asynchronous call task in the asynchronous task table. In the asynchronous task state machine, the life cycle of the asynchronous task has five states: READY, RUNNING, EXCEPTION, FAIL, and SUCCESS. Among them, READY is the first state, which can be identified by the number 0. RUNNING is the second state, which can be identified by the number 1. EXCEPTION is the second state, which can be identified by the number 2. FAIL is the third state, which can be identified by the number 3. SUCCESS is the fourth state, which can be identified by the number 4.

[0132] When a new asynchronous call task is generated and inserted into the asynchronous task table, the state of the asynchronous call task is set to READY.

[0133] During the execution of the asynchronous call task, the state of the asynchronous call task is set to RUNNING.

[0134] If an exception occurs during the execution of an asynchronous call task, the task status can be changed to EXCEPTION. These abnormal call tasks can be obtained from the database at a regular interval and reprocessed separately to ensure that the abnormal call tasks can be completed smoothly.

[0135] When the number of asynchronous call task execution exceptions reaches a preset threshold, it means that the asynchronous call task has been executed abnormally multiple times, and its status is set to FAIL to mark the failure status of the task. The failed task will not be retried.

[0136] When the asynchronous call task is executed successfully, its status is set to SUCCESS, indicating that the task has been successfully completed.

[0137] In this embodiment, the two states of FAIL and SUCCESS can be used to determine whether the asynchronous call task is ultimately executed successfully or failed.

[0138] In actual application, after the asynchronous call task and the target data required by the asynchronous call instruction are added to the asynchronous task table, the execution state of the asynchronous call task in the asynchronous task table is set to the first state, namely, the above-mentioned READY.

[0139] S14. Send the asynchronous call task to the second processing system, so that the second processing system executes the asynchronous call task.

[0140] The second processing system refers to a system called by the first processing system, such as B, C, and D mentioned above.

[0141] In this embodiment, since the target data required for the asynchronous call instruction has been generated, the second processing system can now use the target data to normally execute the asynchronous call instruction, so the asynchronous call task can be sent to the second processing system so that the second processing system executes the asynchronous call task.

[0142] The process of the second processing system executing the asynchronous call task can be obtained by configuring the first processing system and the second processing system.

[0143] S15. Adjust the execution status of the asynchronous call task in the asynchronous task table based on the progress of the second processing system executing the asynchronous call task.

[0144] In this embodiment, when the second processing system executes an asynchronous call task, the asynchronous call task may handle an exception, may handle it successfully, or may handle it unsuccessfully. Therefore, the progress of the asynchronous call task executed by the second processing system can be monitored to adjust the execution status of the asynchronous call task in the asynchronous task table in real time.

[0145] In this embodiment, when the first processing system outputs an asynchronous call instruction, the asynchronous call instruction is directly intercepted. At this time, the second processing system that executes the asynchronous call instruction will not execute the asynchronous call task because it has not received the asynchronous call instruction. In the case of determining that the first processing system generates the target data required for the asynchronous call instruction, the asynchronous call instruction and the target data required for the asynchronous call instruction are encapsulated as an asynchronous call task, and the asynchronous call task is sent to the second processing system so that the second processing system executes the asynchronous call task. Since the target data required for the asynchronous call task has been generated when the second processing system executes the asynchronous call task, it can be ensured that the second processing system uses the target data to normally execute the asynchronous call task, avoiding the problem that the asynchronous call task cannot be normally executed due to the non-existence of the target data when executing the asynchronous call task. In addition, in this application, the asynchronous call task and the target data required for the asynchronous call instruction are added to the asynchronous task table, the execution state of the asynchronous call task in the asynchronous task table is set to the first state, and the execution state of the asynchronous call task in the asynchronous task table is adjusted based on the progress of the second processing system executing the asynchronous call task, so that the execution progress of the asynchronous call task can be monitored in real time, so that when the asynchronous call task is abnormally executed, the corresponding maintenance operation can be performed in time.

[0146] In addition, in the present application, the same transaction is implemented through asynchronous calls of multiple systems, which can improve the transaction processing efficiency and avoid the generation of large transactions compared to the synchronous execution of one system.

[0147] In another implementation of the present application, the asynchronous call task is sent to the second processing system. There are two implementation methods, which are now introduced separately.

[0148] In one implementation, the asynchronous call task can be sent to the second processing system via a message queue. Figure 2 , which may include the following steps:

[0149] S21. Perform a monitoring operation on the asynchronous task table to convert the asynchronous call task into a target message when an insertion event of adding the asynchronous call task to the asynchronous task table is detected.

[0150] In this embodiment, the message middleware can be used to monitor the binary file binlog of the asynchronous task table. Therefore, when the asynchronous call task and the target data required by the asynchronous call instruction are added to the asynchronous task table, the message middleware can monitor the insert event, and at this time it can be determined that there is a new asynchronous call task.

[0151] After monitoring the insertion event, the asynchronous call task is converted into a target message, which can be a message queue message. During the specific conversion, the conversion operation can be performed according to the corresponding conversion method. In one implementation method:

[0152] Message middleware is used to ensure that messages produced by producers can be consumed by consumers. Message middleware is used to achieve decoupling between systems and conversion operations between target messages and message queue messages.

[0153] S22: Store the target message in a message queue, so that the second processing system obtains the asynchronous call task by monitoring the message queue.

[0154] In this embodiment, taking the first processing system as the main body for executing the asynchronous call control method in this application as an example, the first processing system is the producer of the message, and the second processing system is the consumer of the message. The first processing system stores the message in the message queue, and the second processing system is configured with a listener listener, which is used to listen to the messages in the message queue. When there is a new message in the message queue, the listener can consume the new message and transmit it to the second processing system. The second processing system reads the message, obtains the asynchronous call task, and then extracts the asynchronous call instructions in the task and the target data required for the asynchronous call instructions.

[0155] In this embodiment, the transmission of asynchronous call tasks is realized by using message middleware, which enables the second processing system to consume messages in the message queue in a timely manner. However, due to the need to rely on message middleware, the implementation complexity is increased and the operating cost is increased. In addition, the long call chain length from binlog to message queue increases a lot of uncertainty.

[0156] To this end, in another implementation of the present application, a thread pool may be used to send the asynchronous call task to the second processing system.

[0157] In this embodiment, after detecting that the first processing system outputs the asynchronous call task to the thread pool, the asynchronous call task is sent to the second processing system using the threads in the thread pool.

[0158] Specifically, in the current transaction, after the asynchronous call task is generated, the task will be immediately provided to the thread pool. In the thread pool, there are many threads, and each thread can be executed in parallel. The business system can customize and flexibly configure the core parameters of the thread pool. The code for customizing and flexibly configuring the core parameters of the thread pool is:

[0159] YAML# Custom thread pool configuration custom: thread-pool: core-size: 10 max-size: 20 queue-capacity: 10000 thread-name-prefix: custom-executor-

[0160] After having the core parameters of the thread pool, you need to use the thread pool configuration class to take effect. The implementation code is:

[0161] Java / ** * * @author ruicongma * @description Custom thread pool configuration class * @date 2023 / 10 / 25 2:00 * / @Configuration@EnableConfigurationProperties(CustomThreadPoolProperties.class) public class CustomThreadPoolConfig { @Bean(name = "customThreadPool") public ThreadPoolTaskExecutor customThreadPoolTaskExecutor(CustomThreadPoolProperties properties) { ThreadPoolTaskExecutor executor =new ThreadPoolTaskExecutor(); executor.setCorePoolSize(properties.getCoreSize()); executor.setMaxPoolSize(properties.getMaxSize()); executor.setQueueCapacity(properties.getQueueCapacity());executor.setThreadNamePrefix(properties.getThreadNamePrefix());executor.initialize(); return executor;}}.

[0162] In this embodiment, by configuring the thread pool accordingly, flexible control of the thread pool can be achieved.

[0163] AsyncExecAspect can obtain the thread pool for asynchronous execution. After receiving the asynchronous call task, the thread in the thread pool will send the asynchronous call task to the corresponding processing system. For example, an asynchronous call task 1 needs to be executed by B and C. Therefore, one thread in the thread pool sends the asynchronous call task 1 to B, and another thread in the thread pool sends the asynchronous call task 1 to C.

[0164] In this embodiment, after the asynchronous call task is generated, it will be immediately submitted to the thread pool for execution, instead of obtaining the asynchronous call task from the database. This method ensures that the task can be executed in time and maintains consistency with the transaction.

[0165] In this embodiment, message middleware is no longer used, which reduces the dependent middleware, reduces the algorithm complexity, and reduces the cost of maintaining the message middleware. Since the asynchronous call task is directly sent to the thread pool and transmitted to the corresponding system by the thread pool, there is no need to perform data conversion operations, which also reduces the length of the data call chain and avoids errors in the data conversion process.

[0166] In another implementation of the present application, adjusting the execution state of the asynchronous call task in the asynchronous task table based on the progress of the asynchronous call task executed by the second processing system includes:

[0167] During the process of the second processing system executing the asynchronous call task, the execution state of the asynchronous call task in the asynchronous task table is set to running.

[0168] In the case where the second processing system executes the asynchronous call task abnormally, the execution state of the asynchronous call task in the asynchronous task table is set to abnormal, and the number of abnormalities is recorded.

[0169] When the second processing system abnormally executes the asynchronous call task for a specified number of times, the execution state of the asynchronous call task in the asynchronous task table is set to failure.

[0170] When the second processing system successfully executes the asynchronous call task, the execution status of the asynchronous call task in the asynchronous task table is set to success.

[0171] In this embodiment, the execution status of the asynchronous call task can be obtained through information interaction with the second processing system. In addition, the second processing system can actively report the execution status of the asynchronous call task, so as to perform corresponding status settings.

[0172] In another implementation of the present application, in the case of abnormal execution of the asynchronous call task, the abnormal call task can be re-issued to improve the success rate of the execution of the asynchronous call task. Specifically, after adjusting the execution status of the asynchronous call task in the asynchronous task table based on the progress of the execution of the asynchronous call task by the second processing system, it also includes:

[0173] Periodically obtain asynchronous call tasks with abnormal execution status, use the obtained asynchronous call tasks as target asynchronous call tasks, and send the target asynchronous call tasks to the second processing system again so that the second processing system executes the target asynchronous call tasks until the second processing system successfully executes the target asynchronous call tasks, or stops when the number of abnormal executions of the target asynchronous call tasks exceeds a preset threshold.

[0174] Specifically, abnormal asynchronous call tasks in the asynchronous task table can be scanned out through a scheduled task and re-executed to ensure successful execution of the asynchronous call tasks and ensure task consistency.

[0175] In actual scenarios, set the rollback exception to Exception, and then scan the asynchronous task table configured in the database at fixed intervals. During the scan, only the asynchronous call tasks with abnormal execution status in the asynchronous task table are scanned. These tasks can be used as target asynchronous call tasks.

[0176] Since the asynchronous call task and the target data required by the asynchronous call instruction are added to the asynchronous task table when the asynchronous call task is stored in the asynchronous task table, the asynchronous call task can be obtained from the asynchronous task table and sent to the second processing system again through the backflow of the above-mentioned message queue or thread pool. The second processing system executes the target asynchronous call task. At this time, the execution status of the task in the asynchronous task table is set to running.

[0177] If the target asynchronous call task is successfully executed, the execution status of the asynchronous call task in the asynchronous task table is set to success.

[0178] If the target asynchronous call task still executes abnormally, the execution status of the task is set to abnormal in the asynchronous task table, and the number of abnormalities recorded is updated. When waiting for the next cycle to scan the asynchronous task table configured in the database, the abnormal asynchronous call task will still be scanned out, and the above process will be executed again until the task is successfully executed or the number of abnormal executions of the target asynchronous call task is greater than the preset threshold.

[0179] If the number of abnormal executions of the target asynchronous call task is greater than the preset threshold, its status will be set to failure in the asynchronous task table. Subsequent manual intervention will be made to analyze the cause of the failure and perform corresponding maintenance operations.

[0180] In one embodiment, the scheduled task is used to query the tasks in the asynchronous task table with the execution status of EXCEPTION. For the EXCEPTION task, it is necessary to determine whether the execution times of the task exceed the maximum limit (such as 3 times). If not, execute the business logic again and update the execution times, or wait for the next scheduled task to be triggered. The specific operation depends on the business requirements. If the maximum limit is exceeded, it means that the task has been executed at least three times without success, and manual intervention is triggered.

[0181] In this embodiment, a retry guarantee mechanism is set up. By periodically scanning the asynchronous task table, the task of handling exceptions can be checked in time, and the abnormal task can be tried again. Even when abnormal situations or uncertain factors such as service restart occur, the normal execution of the task can still be guaranteed, thereby ensuring that the task is processed in time, realizing reliable asynchronous calls, meeting business needs during the execution of asynchronous tasks, and avoiding transaction failures.

[0182] In another implementation of the present application, a Spring boot starter component can be developed to implement the above asynchronous call control method. The Maven (a tool for automated build, dependency management, and project information management) dependency of this component is:

[0183] XML <dependency> <groupid> com.sohu< / groupid> <artifactid> transaction-async-starter-spring-boot< / artifactid> <version> 0.0.1-SNAPSHOT< / version> < / dependency> .

[0184] Through asynchronous calls, the decoupling of business logic is realized, and the pure real-time logic is decoupled from the nonlinear non-real-time logic. The business system can ensure the consistency of Spring local transactions and asynchronous execution by introducing this component. If the component issues tasks through the thread pool, it can improve the response speed of the interface, reduce unnecessary synchronization waiting time, and enhance the stability and scalability of the system. In addition, the components in this embodiment can be reused, so that they can be applied to various systems.

[0185] In this embodiment, the business system can ensure the consistency of Spring local transactions and asynchronous execution by introducing spring boot starter component dependency, thereby achieving reuse effect.

[0186] In order to enable those skilled in the art to more clearly understand the present invention, an example is now given. Assume that there are two systems, business system A and business system B. Business system A: When processing business data (local transaction data of business system A), in order to improve performance, asynchronously notifies business system B in the local transaction method that data has arrived. After receiving the notification from business system A, business system B immediately queries the data of business system A.

[0187] In this process, in order to ensure that business system B can find the transaction data of business system A, business system A needs to submit the local transaction before notifying business system B. In addition, in order to ensure that the asynchronous call to business system B is reliable, it is necessary to create asynchronous task description information (such as target class, method name, parameters, etc.) and insert it into the asynchronous task table. The insertion of the asynchronous task table and the local transaction data must be in the same transaction. Further, through the hook monitoring, the transaction registration hook can monitor whether the transaction is submitted. After submission, the corresponding asynchronous call task is obtained and transmitted to the corresponding system for execution. This can ensure that the system executes the asynchronous call task and the current execution transaction belongs to the same transaction, that is, to ensure that the transaction data is reliable, and the life cycle of the asynchronous task can be traced through the asynchronous task table.

[0188] In order to enable those skilled in the art to understand the present invention more clearly. Figure 3-Figure 5 The specific implementation of this application is explained.

[0189] In one scenario, business systems are divided into A, B, C and other business systems. Business system A is used to execute local transactions, and B, C and other business systems can be called asynchronously by A.

[0190] Phase 1:

[0191] For business systems B, C and other business systems, they need to subscribe to business system A. Taking business system B as an example, the subscription process is introduced below. The specific subscription process is as follows:

[0192] Business system B subscribes to the data of business system A, and business system A stores the information of business system B, which can be an interface callback address, etc., and returns a message that the information of business system B is successfully stored.

[0193] The subscription process of business system C is similar to that of other business systems.

[0194] Phase 2:

[0195] When new data arrives, business system A intercepts the method annotated with @AsyncExec through the transaction asynchronous aspect AOP, and then creates an asynchronous execution task entity (target class, method name, parameters, etc.). The asynchronous execution task entity can be an asynchronous call task, and inserts the asynchronous call task into the asynchronous task table. Among them, the asynchronous task table is inserted in the current transaction, which can ensure the atomicity of the transaction (either succeed together or fail together).

[0196] The hook hook after registering the transaction submission will be called back to trigger the hook method when the transaction is submitted (i.e., the target data required by the asynchronous call instruction is obtained). In the hook method, the business systems (B, C, and other business systems) that subscribe to business system A are asynchronously called, and they are notified of the incoming data through the interface callback address. The asynchronous call uses a custom thread pool to send the data of the asynchronous call task, which ensures that the transaction data of business system A is separated from the asynchronous call business system, and the atomicity of the transaction data and the asynchronous task data). After successfully notifying B, C, and other business systems, business systems B, C, and other business systems will query the latest data of business system A. If the notification fails, the asynchronous task execution entity marks the task status as EXCEPTION, and waits for the scheduled task scan to ensure that the failed asynchronous task enters the compensation mechanism.

[0197] Phase 3:

[0198] The scheduled task scans the asynchronous task status of EXCEPTION and the tasks with less than 3 retries, and compensates the asynchronous task for the failed execution notification. If the notification is successful, the asynchronous task status is marked as SUCCESS. If the notification fails, the compensation count is increased by 1, and the next scheduled task scan is waited. If the compensation notification fails after 3 times, the alarm mechanism is triggered for manual intervention.

[0199] Based on the above-mentioned embodiment of the asynchronous call control method, another embodiment of the present application provides an asynchronous call control device, referring to Figure 6 , which may include:

[0200] The interception module 11 is used to intercept the asynchronous call instruction output by the first processing system;

[0201] A task encapsulation module 12 is used to encapsulate the asynchronous call instruction and the target data required by the asynchronous call instruction into an asynchronous call task when it is determined that the first processing system generates the target data required by the asynchronous call instruction;

[0202] A data adding module 13, used for adding the asynchronous call task and the target data required by the asynchronous call instruction to the asynchronous task table, and setting the execution state of the asynchronous call task in the asynchronous task table to the first state;

[0203] A task sending module 14, used for sending the asynchronous call task to the second processing system, so that the second processing system executes the asynchronous call task;

[0204] The state adjustment module 15 is used to adjust the execution state of the asynchronous call task in the asynchronous task table based on the progress of the asynchronous call task executed by the second processing system.

[0205] In one implementation, the interception module includes:

[0206] The content setting submodule is used to set the interception content in the interception operation to be asynchronous;

[0207] A data acquisition submodule, used to acquire output data of the first processing system;

[0208] The interception submodule is used to intercept the asynchronous call instruction if the output data is an asynchronous call instruction related to the asynchronous call.

[0209] In one implementation, the task sending module 14 includes:

[0210] a conversion submodule, configured to perform a monitoring operation on the asynchronous task table, so as to convert the asynchronous call task into a target message when an insertion event of adding the asynchronous call task to the asynchronous task table is detected;

[0211] The storage submodule is used to store the target message in a message queue so that the second processing system can obtain the asynchronous call task by monitoring the message queue.

[0212] In one implementation, the task sending module 14 includes:

[0213] The sending submodule is used to send the asynchronous call task to the second processing system using the threads in the thread pool after detecting that the first processing system outputs the asynchronous call task to the thread pool.

[0214] In one implementation, the state adjustment module 15 includes:

[0215] A first setting submodule, configured to set the execution state of the asynchronous call task in the asynchronous task table to running during the process of the second processing system executing the asynchronous call task;

[0216] A second setting submodule is used to set the execution state of the asynchronous call task in the asynchronous task table to abnormal when the second processing system executes the asynchronous call task abnormally;

[0217] A third setting submodule is used to set the execution state of the asynchronous call task in the asynchronous task table to failure when the second processing system abnormally executes the asynchronous call task for a specified number of times;

[0218] The fourth setting submodule is used to set the execution status of the asynchronous call task in the asynchronous task table to success when the second processing system successfully executes the asynchronous call task.

[0219] In one implementation, the method further includes:

[0220] A scanning module is used to periodically obtain asynchronous call tasks with abnormal execution status, and use the obtained asynchronous call tasks as target asynchronous call tasks;

[0221] The task sending module 14 is also used to send the target asynchronous call task to the second processing system again so that the second processing system executes the target asynchronous call task until the second processing system successfully executes the target asynchronous call task, or stops when the number of abnormal executions of the target asynchronous call task is greater than a preset threshold.

[0222] In the present application, when the first processing system outputs an asynchronous call instruction, the asynchronous call instruction is directly intercepted. At this time, the second processing system that executes the asynchronous call instruction will not execute the asynchronous call task because it has not received the asynchronous call instruction. In the case of determining that the first processing system generates the target data required for the asynchronous call instruction, the asynchronous call instruction and the target data required for the asynchronous call instruction are encapsulated as an asynchronous call task, and the asynchronous call task is sent to the second processing system so that the second processing system executes the asynchronous call task. Since the target data required for the asynchronous call task has been generated when the second processing system executes the asynchronous call task, it can ensure that the second processing system uses the target data to normally execute the asynchronous call task, avoiding the problem that the asynchronous call task cannot be normally executed due to the non-existence of the target data when executing the asynchronous call task. In addition, in the present application, the asynchronous call task and the target data required for the asynchronous call instruction are added to the asynchronous task table, the execution state of the asynchronous call task in the asynchronous task table is set to the first state, and the execution state of the asynchronous call task in the asynchronous task table is adjusted based on the progress of the second processing system executing the asynchronous call task, so that the execution progress of the asynchronous call task can be monitored in real time, so that when the asynchronous call task is abnormal, the corresponding maintenance operation can be performed in time.

[0223] It should be noted that, for the working process of each module and sub-module in this embodiment, please refer to the corresponding description in the above embodiment, which will not be repeated here.

[0224] An embodiment of the present application also provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0225] The memory is used to store computer programs;

[0226] The processor is used to execute the computer program so that the electronic device can implement the above-mentioned asynchronous call control method.

[0227] refer to Figure 7 As shown, it shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiment of the present application. The electronic device in the embodiment of the present application may include but is not limited to fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 7 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0228] like Figure 7 As shown, the electronic device may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 to a random access memory (RAM) 603. When the electronic device is powered on, various programs and data required for the operation of the electronic device are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0229] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a memory card, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although Figure 7 An electronic device having various devices is shown, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0230] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any asynchronous call control method provided in the embodiment of the present application.

[0231] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any asynchronous call control method provided in an embodiment of the present application.

[0232] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An asynchronous call control method, characterized in that: include: Intercepting the asynchronous call instruction output by the first processing system; In a case where it is determined that the first processing system generates the target data required by the asynchronous call instruction, encapsulating the asynchronous call instruction and the target data required by the asynchronous call instruction into an asynchronous call task; Adding the asynchronous call task and the target data required by the asynchronous call instruction to an asynchronous task table, and setting the execution state of the asynchronous call task in the asynchronous task table to a first state; Sending the asynchronous call task to a second processing system so that the second processing system executes the asynchronous call task; Based on the progress of the second processing system in executing the asynchronous call task, the execution status of the asynchronous call task in the asynchronous task table is adjusted.

2. The asynchronous call control method according to claim 1, characterized in that: Intercepting the asynchronous call instruction output by the first processing system to obtain an asynchronous call task includes: Set the interception content in the interception operation to be asynchronous; Acquire output data of the first processing system; If the output data is an asynchronous call instruction related to an asynchronous call, an interception operation is performed on the asynchronous call instruction.

3. The asynchronous call control method according to claim 1, characterized in that: Sending the asynchronous call task to the second processing system includes: Performing a monitoring operation on the asynchronous task table, so as to convert the asynchronous call task into a target message when an insertion event of adding the asynchronous call task to the asynchronous task table is detected; The target message is stored in a message queue, so that the second processing system obtains the asynchronous call task by monitoring the message queue.

4. The asynchronous call control method according to claim 1, characterized in that: Sending the asynchronous call task to the second processing system includes: After detecting that the first processing system outputs the asynchronous call task to the thread pool, the asynchronous call task is sent to the second processing system using threads in the thread pool.

5. The asynchronous call control method according to claim 1, characterized in that: Adjusting the execution state of the asynchronous call task in the asynchronous task table based on the progress of the second processing system executing the asynchronous call task includes: During the process of the second processing system executing the asynchronous call task, setting the execution state of the asynchronous call task in the asynchronous task table to running; In the case where the second processing system executes the asynchronous call task abnormally, setting the execution state of the asynchronous call task in the asynchronous task table to abnormal; When the second processing system abnormally executes the asynchronous call task for a specified number of times, setting the execution state of the asynchronous call task in the asynchronous task table to failure; In the case where the second processing system successfully executes the asynchronous call task, the execution status of the asynchronous call task in the asynchronous task table is set to success.

6. The asynchronous call control method according to claim 1, characterized in that: After adjusting the execution state of the asynchronous call task in the asynchronous task table based on the progress of the asynchronous call task executed by the second processing system, the method further includes: Periodically obtain asynchronous call tasks with abnormal execution status, and use the obtained asynchronous call tasks as target asynchronous call tasks; The target asynchronous call task is sent to the second processing system again so that the second processing system executes the target asynchronous call task until the second processing system successfully executes the target asynchronous call task, or stops when the number of abnormal executions of the target asynchronous call task is greater than a preset threshold.

7. An asynchronous call control device, characterized in that: include: An interception module, used for intercepting the asynchronous call instruction output by the first processing system; a task encapsulation module, configured to encapsulate the asynchronous call instruction and the target data required by the asynchronous call instruction into an asynchronous call task when it is determined that the first processing system generates the target data required by the asynchronous call instruction; A data adding module, used for adding the asynchronous call task and target data required by the asynchronous call instruction to an asynchronous task table, and setting the execution state of the asynchronous call task in the asynchronous task table to a first state; A task sending module, used for sending the asynchronous call task to the second processing system, so that the second processing system executes the asynchronous call task; The state adjustment module is used to adjust the execution state of the asynchronous call task in the asynchronous task table based on the progress of the asynchronous call task executed by the second processing system.

8. The asynchronous call control device according to claim 7, characterized in that: The interception module comprises: The content setting submodule is used to set the interception content in the interception operation to be asynchronous; A data acquisition submodule, used to acquire output data of the first processing system; The interception submodule is used to intercept the asynchronous call instruction if the output data is an asynchronous call instruction related to the asynchronous call.

9. An electronic device, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the electronic device can implement the asynchronous call control method as described in any one of claims 1 to 6.

10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the asynchronous call control method as described in any one of claims 1 to 6.

Images