An asynchronous invocation control method and related apparatus

Abstract

The application discloses an asynchronous call control method and related device, and relates to the field of asynchronous processing. When a first processing system outputs an asynchronous call instruction, the asynchronous call instruction is directly intercepted, at this time, a second processing system executing the asynchronous call instruction does not execute an asynchronous call task because the second processing system does not receive the asynchronous call instruction. In the case that target data required by the first processing system for generating the asynchronous call instruction is determined, the asynchronous call instruction and the target data required by the asynchronous call instruction are encapsulated as the asynchronous call task, the asynchronous call task is sent to the second processing system, and the second processing system executes the asynchronous call task. Because the target data required by the asynchronous call task is generated when the second processing system executes the asynchronous call task, the second processing system can normally execute the asynchronous call task by using the target data, and the problem that the asynchronous call task cannot be normally executed because the target data does not exist 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 within a single database system, typically involving operations on a single data source and not requiring coordination by a global transaction manager. The key characteristic of a local transaction is that it operates within a single service or application and does not involve cross-service operations.

[0003] To improve local transaction processing performance, you can allow the database system to asynchronously call other systems to perform tasks while executing local transactions. For example, let's assume that database system A is executing the local transaction. While executing the local transaction, system A will asynchronously call systems B, C, and D to perform tasks. While systems B, C, and D are processing tasks, system B may need some data from system A. If system A hasn't generated this data yet, system B will be unable to process the task properly, 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] 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 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 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] obtaining 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 to convert the asynchronous call task into a target message when an insert event for 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 the threads in the thread pool.

[0021] Optionally, adjusting the execution status 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 executing the asynchronous call task by the second processing system, 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 a specified number of times, setting the execution status of the asynchronous call task in the asynchronous task table to failure;

[0025] In the case that 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 status 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 exceeds a preset threshold.

[0029] An asynchronous call control device, comprising:

[0030] An interception module, configured to intercept 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, configured to add the asynchronous call task and 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 a first state;

[0033] A task sending module, configured to send the asynchronous call task to a 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, configured 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 comprising at least one processor and a memory connected to the processor, wherein:

[0040] The memory is configured to store a computer program;

[0041] The processor is configured to execute the computer program to enable the electronic device to implement the asynchronous call control method.

[0042] A computer storage medium, 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 the asynchronous call control method described above.

[0043] The present application provides an asynchronous call control method and related device, in 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 executing the asynchronous call instruction will not execute the asynchronous call task because the asynchronous call instruction is not received. In the case of determining the target data required by the first processing system for generating the asynchronous call instruction, the asynchronous call instruction and the target data required by the asynchronous call instruction are encapsulated as an asynchronous call task, and the asynchronous call task is sent to the second processing system to make the second processing system execute the asynchronous call task. Because the second processing system executes the asynchronous call task, the target data required by the asynchronous call task has been generated, so as to ensure that the second processing system normally executes the asynchronous call task using the target data, and avoid the problem that the asynchronous call task cannot be normally executed due to the nonexistence of the target data when the asynchronous call task is executed. 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 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. The execution progress of the asynchronous call task can be monitored in real time to perform corresponding maintenance operation in time when the asynchronous call task is executed abnormally. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technical solutions, the following will briefly introduce the drawings needed to be used in the embodiment or related technical description. Obviously, the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor on the basis of the provided drawings.

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

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

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

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

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

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

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

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

[0053] In order for those skilled in the art to have a clearer understanding of the present application, the professional terms in the present application are explained.

[0054] Transaction generally refers to things to be done or done. In computer terminology, it refers to a program execution unit that accesses and may update various data items in a database. A transaction is usually caused by the execution of a user program written in a high-level database manipulation language or a programming language (such as SQL (Structured Query Language), C++ or Java), and is delimited by statements (or function calls) such as begin transaction and end transaction. A transaction consists of all operations performed between the begin transaction and the end transaction.

[0055] Local transaction refers to a transaction executed in a single database system, which usually involves operations on a single data source and does not require a global transaction manager for coordination. 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 statements may not complete in the same order in which they began. This allows applications to break free from the constraints of individual tasks, improving flexibility and efficiency.

[0057] The Spring Framework (Java language framework technology) is an open-source J2EE (Java 2 Platform Enterprise Edition) application framework. It is a lightweight container that manages the lifecycle of beans (the basic components of Spring applications). Spring solves many common problems developers encounter in J2EE development, providing powerful features such as Inversion of Control (IoC), Aspect Oriented Programming (AOP), and Web Model View Controller (Web MVC) three-tier architecture. Spring can be used to build applications independently or in combination with numerous web frameworks such as Struts, WebWork, and Tapestry. It can also be combined with desktop application programming frameworks such as Swing. Therefore, Spring is applicable not only to J2EE applications but also to desktop applications and applets. The Spring framework mainly consists of seven parts: 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 approach to configuration, eliminating the need for developers to define boilerplate configurations. In this way, Spring Boot aims to become a leader in the rapidly developing field of rapid application development.

[0059] 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. When making asynchronous calls, you can achieve asynchrony by cloning the Fork thread or directly using the Spring @Async annotation. However, it should be noted that when using Spring's JDBC (Java Database Connectivity) transactions, once a new thread is forked, it will be out of the original transaction scope, so the transaction of the new thread will no longer belong to the same transaction as the original transaction, and the reliability and consistency of the JDBC transaction will be lost.

[0060] Among them, the reliability refers to ensuring that the asynchronous task will be executed after the creation of the asynchronous task and the successful submission of the local transaction, regardless of whether an abnormal situation or service restart occurs, and the At-Least-Once semantic is always guaranteed. Consistency refers to the consistency of the business logic inside the asynchronous method and the transaction context when the asynchronous method is called. When the local transaction is committed, the asynchronous task is executed, and when the local transaction is rolled back, the asynchronous task is not executed.

[0061] In addition, process internal event notifications: tool class events Guava Event and observer mode events Spring Event can also be used to implement asynchronous calls. Both of them essentially implement the publish-subscribe pattern and can be used to implement asynchronous calls. Guava Event provides synchronous and asynchronous event publishing, which is based on queues and thread pools. Spring Event 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 essence is still to fork a thread, and once a new thread is forked, it will be out of the original transaction scope, so the transaction of the new thread will no longer belong to the same transaction as the original transaction, and the transaction characteristics will be lost, so the transaction of the new thread will no longer belong 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 pattern in the microservice scenario, aiming to achieve reliable message delivery. It is mainly used to solve the reliability and consistency problems of interaction between applications and external applications. Therefore, in the present embodiment, the Outbox Pattern can be used for asynchronous calls.

[0063] When using the Outbox Pattern for asynchronous calls, let's assume that the database system executing a local transaction is System A. During this local transaction, System A asynchronously calls Systems B, C, and D to process some tasks. This can lead to data inconsistencies during these asynchronous calls. A typical example is the timing issues between local transactions and asynchronous calls. Often, when querying data for the current transaction during an asynchronous call, the current transaction may not have been committed, resulting in issues such as the queried data not existing. For example, while Systems B, C, and D are processing a task, System B may need some data from System A. If System A has not yet generated this data, System B will be unable to process the task properly, reducing the reliability of asynchronous task processing. More specifically, in one scenario, System A inserts employee data and then asynchronously notifies Business System B of the data change. System B then calls System A's interface to query the employee data, but the data is not found. The root cause is an issue with the order in which the data is inserted and the asynchronous notification is executed. The transaction inserting the employee data may not have been committed, so the asynchronous notification to System B may not 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. When it is determined 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 in executing the asynchronous call task, the execution status of the asynchronous call task in the asynchronous task table is adjusted, so that 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, in which the execution subject can be a database system that executes local transactions, such as the device where the above-mentioned system A 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 application 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 responsiveness.

[0071] This approach decouples logic, separating pure real-time logic from non-linear, non-real-time logic. Asynchronous mechanisms are widely used in event-driven scenarios. By processing events asynchronously, real-time logic can be separated from non-real-time logic, improving system maintainability and scalability.

[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, this can be achieved 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 aforementioned system A. While executing local transactions, system A will asynchronously call systems B, C, and D to handle some tasks to improve the processing efficiency of local transactions.

[0074] For example, system A calls system B to perform the first task, system A calls system C to perform the second task, and system A calls system D to perform the 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 the 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 a method marked as asynchronous with a custom annotation. The custom annotation can be @AsyncExec. The @AsyncExec annotation is used to mark methods that need to be executed asynchronously. Only methods 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 AsyncExec aspect class, 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 asynchronous task records 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 no transaction currently exists, the business operation is executed 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 for data interception, if the output data is an asynchronous call instruction related to an 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] The target data required by the asynchronous call instruction needs to be pre-configured, for example, the task corresponding to a certain asynchronous call instruction requires data a, b, and c.

[0099] In this embodiment, 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 committed. If it is committed, it indicates that the first processing system has generated the target data required for the asynchronous call instruction. If it is not committed and an exception occurs, the exception can be eliminated by rolling back.

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

[0101] The input parameters of 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 the database can be used to perform stateful management of asynchronous call tasks. To this end, an asynchronous task table is pre-configured in the local transaction database 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 can be set as a read-only table. In this 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 the target class, method name, parameters, etc.) and the target data required by the asynchronous call instruction) to the asynchronous task table in the database.

[0131] In addition, an asynchronous task state machine is set for the asynchronous call tasks in the asynchronous task table. In the asynchronous task state machine, the asynchronous task lifecycle has five states: READY, RUNNING, EXCEPTION, FAIL, and SUCCESS. READY is the first state, identified by the number 0. RUNNING is the second state, identified by the number 1. EXCEPTION is the second state, identified by the number 2. FAIL is the third state, identified by the number 3. SUCCESS is the fourth state, 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. Subsequently, these abnormal call tasks can be retrieved from the database at regular intervals 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 no longer be retried.

[0136] When the asynchronous call task is successfully executed, 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, that is, 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 the 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 use the target data to normally execute the asynchronous call instruction. Therefore, 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 in executing the asynchronous call task.

[0144] In this embodiment, when the second processing system executes the 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 can be monitored on the second processing system 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, it directly intercepts the asynchronous call instruction. 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. When it is determined that the first processing system has generated 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 into 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, avoiding the problem that the asynchronous call task cannot be executed normally due to the absence of 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 status of the asynchronous call task in the asynchronous task table is set to the first state, and the execution status 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. This can monitor the execution progress of the asynchronous call task in real time, so that corresponding maintenance operations can be performed in a timely manner when the asynchronous call task is executed abnormally.

[0146] In addition, in this 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 insert 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. The target message can be a message queue message. When converting, 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 serves as the producer of the message, and the second processing system serves as 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, 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 by the asynchronous call instructions.

[0155] In this embodiment, message-based middleware is used to implement asynchronous call task transmission. This middleware enables the second processing system to consume messages from the message queue in a timely manner. However, this reliance on message-based middleware increases implementation complexity and operating costs. Furthermore, the long call chain from the binlog to the message queue introduces significant 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 an asynchronous call task is generated, the task will be immediately provided to the thread pool. The thread pool has many threads, and each thread can execute 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, they need to be configured through the thread pool 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, flexible control of the thread pool can be achieved by configuring the thread pool accordingly.

[0163] AsyncExecAspect can obtain a thread pool for asynchronous execution. After receiving an asynchronous call task, a thread in the thread pool sends the asynchronous call task to the corresponding processing system. For example, if asynchronous call task 1 requires execution by B and C, one thread in the thread pool will send asynchronous call task 1 to B, and another thread in the thread pool will send 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 number of dependent middleware, reduces algorithm complexity, and reduces the cost of maintaining 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 convert the data, 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 status 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 executing the asynchronous call task by the second processing system, the execution state of the asynchronous call task in the asynchronous task table is set to running.

[0168] In the case that 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 a specified number of times, the execution status of the asynchronous call task in the asynchronous task table is set to failure.

[0170] In the case that 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, for the case of asynchronous call task execution exception, the exception call task can be reissued to improve the success rate of asynchronous call task execution. Specifically, after adjusting the execution state of the asynchronous call task in the asynchronous task table based on the progress of executing the asynchronous call task by the second processing system, the method further comprises:

[0173] Timing to acquire the asynchronous call task with an execution state of exception, taking the acquired asynchronous call task as a target asynchronous call task, and sending the target asynchronous call task to the second processing system again to make the second processing system execute the target asynchronous call task until the second processing system successfully executes the target asynchronous call task or stops when the number of exception executions of the target asynchronous call task is greater than a preset threshold.

[0174] Specifically, for the asynchronous call task with exception in the asynchronous task table, the task can be scanned by a timing task and re-executed to ensure the successful execution of the asynchronous call task and the consistency of the task.

[0175] In an actual scenario, the rollback exception is set as Exception, and then the asynchronous task table configured in the database is scanned every fixed time interval. During the scanning, only the asynchronous call task with an execution state of exception in the asynchronous task table is scanned, and these tasks can be taken 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 acquired from the asynchronous task table and sent to the second processing system again through the above-mentioned message queue or thread pool feedback, and the second processing system executes the target asynchronous call task. At this time, the execution state of the task in the asynchronous task table is set to running.

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

[0178] If the target asynchronous call task is still executed abnormally, the execution state of the task in the asynchronous task table is set to exception, and the number of recorded exceptions is updated. When the asynchronous task table configured in the database is scanned next time, the asynchronous call task with exception will still be scanned out. At this time, the above-mentioned process is executed again until the task is successfully executed or the number of exception executions of the target asynchronous call task is greater than a 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. Manual intervention will be required to analyze the cause of the failure and perform corresponding maintenance operations.

[0180] In one embodiment, a scheduled task queries the asynchronous task table for tasks with an EXCEPTION status. For EXCEPTION tasks, the system determines whether the task has been executed more than the maximum limit (e.g., three times). If not, the system executes the business logic again and updates the execution count, or waits for the next scheduled task to be triggered. The specific operation depends on business requirements. If the maximum limit is exceeded, indicating that the task has been executed at least three times without success, manual intervention is triggered.

[0181] In this embodiment, a retry guarantee mechanism is set up. By regularly scanning the asynchronous task table, it is possible to promptly check the task that handles the exception and try to execute the abnormal task again. Even when an abnormal situation 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 this 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, business logic is decoupled, separating pure real-time logic from non-linear, non-real-time logic. By introducing this component, business systems can ensure consistency between Spring local transactions and asynchronous execution. If this component issues tasks through a thread pool, it can improve interface responsiveness, reduce unnecessary synchronization wait time, and enhance system stability and scalability. Furthermore, the components in this embodiment are reusable, allowing them to 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 the spring boot starter component dependency, thereby achieving a reuse effect.

[0186] To help those skilled in the art better understand the present invention, let's take an example. Consider two systems: Business System A and Business System B. When processing business data (local transaction data), Business System A asynchronously notifies Business System B of incoming data within its local transaction method to improve performance. Upon receiving the notification from Business System A, Business System B immediately queries Business System A for the data.

[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 its 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 inserted asynchronous task table and local transaction data must be in the same transaction. Further, through hook monitoring, the transaction hook can be registered to 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 asynchronous call task executed by the system belongs to the same transaction as the currently executed transaction, that is, 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. Figures 3-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] Business systems B, C, and other business systems need to subscribe to business system A. Taking business system B as an example, the subscription process is as follows:

[0192] Business system B subscribes to the data of business system A. 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, the business system A intercepts the method marked with the @AsyncExec annotation through the transaction asynchronous aspect AOP, and then creates an asynchronous execution task entity (target class, method name, parameter, etc.). The asynchronous execution task entity can be an asynchronous calling task, and the asynchronous calling task is inserted into the asynchronous task table. The insertion of the asynchronous task table is performed in the current transaction, which can guarantee the atomicity of the transaction (success or failure).

[0196] Hook after the transaction is submitted. When the transaction is submitted (i.e., the target data required for asynchronous calling is obtained), the hook method is triggered. In the hook method, the business systems B, C, and other business systems that subscribe to the business system A are asynchronously called. They are notified of the arrival of data through the interface callback address. The asynchronous calling uses a custom thread pool to send data for asynchronous calling tasks, which ensures that the transaction data of the business system A is separate from the asynchronous calling business system, and ensures the atomicity of the transaction data and the asynchronous task data. After successfully notifying the business systems B, C, and other business systems, the business systems B, C, and other business systems query the latest data of the business system A. If the notification fails, the asynchronous task execution entity marks the task state as EXCEPTION, and waits for the timing task to scan to ensure that the failed asynchronous task enters the compensation mechanism.

[0197] Third stage:

[0198] The timing task scans the tasks with the asynchronous task state EXCEPTION and the retry count less than 3, compensates for the failed notification of the asynchronous task, and marks the asynchronous task state as SUCCESS if the notification is successful in the future. If the notification fails, the compensation count is increased by 1, and the next timing task is waited for. If the compensation notification fails 3 times, the alarm mechanism is triggered for manual intervention.

[0199] On the basis of the embodiment of the asynchronous calling control method, another embodiment of the present application provides an asynchronous calling control device, which refers to Figure 6 may include:

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

[0201] The task packaging module 12 is configured to, in a case where it is determined that the target data required for the asynchronous calling instruction generated by the first processing system is obtained, package the asynchronous calling instruction and the target data required for the asynchronous calling instruction into an asynchronous calling task;

[0202] The data adding module 13 is configured to add target data required by the asynchronous call task and the asynchronous call instruction into the asynchronous task table, and set an execution state of the asynchronous call task in the asynchronous task table as a first state.

[0203] The task sending module 14 is configured to send the asynchronous call task to the second processing system, so that the second processing system executes the asynchronous call task.

[0204] The state adjusting module 15 is configured to adjust the execution state of the asynchronous call task in the asynchronous task table based on a progress of executing the asynchronous call task by the second processing system.

[0205] In an implementation manner, the intercepting module comprises:

[0206] The content setting sub-module is configured to set the intercepted content in the intercepting operation as asynchronous.

[0207] The data obtaining sub-module is configured to obtain output data of the first processing system.

[0208] The intercepting sub-module is configured to perform an intercepting operation on the asynchronous call instruction if the output data is the asynchronous call instruction related to asynchronous call.

[0209] In an implementation manner, the task sending module 14 comprises:

[0210] The converting sub-module is configured to perform a listening operation on the asynchronous task table, so as to convert the asynchronous call task into a target message if an insertion event of adding the asynchronous call task into the asynchronous task table is detected.

[0211] The storing sub-module is configured to store the target message into a message queue, so that the second processing system obtains the asynchronous call task by listening to the message queue.

[0212] In an implementation manner, the task sending module 14 comprises:

[0213] The sending sub-module is configured to send the asynchronous call task to the second processing system by using a thread in the thread pool after detecting that the first processing system outputs the asynchronous call task to the thread pool.

[0214] In an implementation manner, the state adjusting module 15 comprises:

[0215] The first setting sub-module is configured to set the execution state of the asynchronous call task in the asynchronous task table as running in a process of executing the asynchronous call task by the second processing system.

[0216] A second setting submodule is configured 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, configured to set the execution status of the asynchronous call task in the asynchronous task table to failure when the second processing system abnormally executes the asynchronous call task a specified number of times;

[0218] The fourth setting submodule is configured 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] The 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. When it is determined that the first processing system has generated 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 into 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, avoiding the problem that the asynchronous call task cannot be executed normally due to the absence 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 status of the asynchronous call task in the asynchronous task table is set to the first state, and the execution status 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. This can monitor the execution progress of the asynchronous call task in real time, so that corresponding maintenance operations can be performed in a timely manner when the asynchronous call task executes abnormally.

[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 further 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 , which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present application. The electronic device in the embodiments 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 limit 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 based on programs stored in a read-only memory (ROM) 602 or programs loaded from a storage device 608 into a random access memory (RAM) 603. When the electronic device is powered on, the RAM 603 also stores various programs and data required for the operation of the electronic device. The processing device 601, ROM 602, and RAM 603 are interconnected 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 touchpad, 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. Figure 7 The electronic device is shown with various devices, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead.

[0230] The embodiment of the present application further provides a computer program product comprising computer readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the asynchronous call control methods provided by the embodiments of the present application.

[0231] The embodiment of the present application further provides a computer readable storage medium, which 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 any of the asynchronous call control methods provided by the embodiments of the present application.

[0232] The above description of disclosed embodiments enables a person 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 can 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 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 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; executing the asynchronous call task includes executing an asynchronous call instruction using the target data; 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; obtaining 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 to convert the asynchronous call task into a target message when an insert event for 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 the threads in the thread pool.

5. The asynchronous call control method according to claim 1, characterized in that: Adjusting the execution status of the asynchronous call task in the asynchronous task table based on the progress of the second processing system in executing the asynchronous call task includes: During the process of executing the asynchronous call task by the second processing system, 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 a specified number of times, setting the execution status of the asynchronous call task in the asynchronous task table to failure; In the case that 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 status 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 exceeds a preset threshold.

7. An asynchronous call control device, characterized in that: include: An interception module, configured to intercept 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, configured to add the asynchronous call task and 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 a first state; A task sending module, configured to send the asynchronous call task to a second processing system so that the second processing system executes the asynchronous call task; the executing the asynchronous call task includes executing an asynchronous call instruction using the target data; 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 includes: The content setting submodule is used to set the interception content in the interception operation to be asynchronous; a data acquisition submodule, configured 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: comprising at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program so that the electronic device can implement the asynchronous call control method according to 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 according to any one of claims 1 to 6.

Images