Asynchronous interaction scheduling method and device, storage medium and terminal

Abstract

The embodiment of the invention discloses an asynchronous interaction scheduling method and device, a storage medium and a terminal. In response to the execution request of the target transaction, an internal request and an external request corresponding to the target transaction are determined, and a processing flow of the internal request is an upstream flow of a receipt acceptance flow of the external request; setting delay callback time for the target transaction, and pausing the transaction process of the target transaction before the delay callback time is ended; the external request is sent to an external server, so that the external server responds to the external request and returns a receipt result; and when the delayed callback time ends, callback the target transaction, judging whether a processing result corresponding to the internal request is obtained, and if so, executing a transaction process of the target transaction based on a receipt result. The delay processing is set for the target transaction, so that the internal request and the external request have more processing time, and the transaction execution stability in the system is enhanced by using the delay callback means in the embodiment of the specification.

Description

Technical Field

[0001] The embodiments of the present specification relate to the field of computer technology, and in particular, to an asynchronous interactive scheduling method, device, storage medium, and terminal. Background Art

[0002] In today's Internet industry, different software systems form a closely connected organic whole through in-depth and meticulous interactive activities, and jointly provide users with a more complete, comprehensive and efficient service experience. In terms of communication between systems, flexible asynchronous communication methods are often used, so that the sender can continue to perform other tasks immediately after sending data without waiting for the receiver's response. However, in actual applications, asynchronous communication methods sometimes result in the situation where the downstream system has asynchronously processed and received the data flow before the local transaction of the upstream system has been committed. Therefore, how to deal with the timing problem in asynchronous communication has become one of the difficult problems that need to be paid attention to and solved during the design and implementation of software products. Summary of the invention

[0003] The embodiments of the present specification provide an asynchronous interaction scheduling method, device, storage medium and terminal, which can solve the technical problem of cross-organization asynchronous interaction anomalies in the related art.

[0004] In a first aspect, an embodiment of the present specification provides an asynchronous interaction scheduling method, the method comprising:

[0005] In response to the execution request of the target transaction, an internal request and an external request corresponding to the target transaction are determined, and the processing flow of the internal request is an upstream flow of the receipt acceptance flow of the external request;

[0006] Setting a delayed callback time for the target transaction, and suspending the transaction process of the target transaction before the delayed callback time expires;

[0007] Processing the internal request, and sending the external request to the external server, so that the external server responds to the external request and returns a receipt result;

[0008] When the delayed callback time ends, the target transaction is called back to determine whether the processing result corresponding to the internal request has been obtained. If so, the transaction flow of the target transaction is executed based on the receipt result.

[0009] In a possible implementation, the above-mentioned setting of a delayed callback time for the above-mentioned target transaction includes: setting a delayed callback time for the above-mentioned target transaction through a preset delayer, and adding an unfinished tag to the above-mentioned target transaction; the above-mentioned calling back the above-mentioned target transaction when the above-mentioned delayed callback time ends includes: calling back the above-mentioned target transaction from the transaction library through a preset scheduler when the above-mentioned delayed callback time ends, and the above-mentioned preset scheduler is used to scan all transactions with unfinished tags in the above-mentioned transaction library and call back each transaction for which the delayed callback time has ended.

[0010] In a possible implementation, the processing of the internal request includes: acquiring transaction data corresponding to the internal request, and performing operations on the transaction data based on calling a preset logic module corresponding to the internal request to obtain a processing result corresponding to the internal request.

[0011] In a possible implementation, after sending the external request to an external server so that the external server responds to the external request and returns a receipt result, the method further includes: receiving the receipt result returned by the external server, and performing a legitimacy check on the receipt result; if the receipt result passes the legitimacy check, caching the receipt result in a result cache pool, and the result cache pool is used to cache received and unused receipt results.

[0012] In a possible implementation, after determining whether the processing result corresponding to the internal request has been obtained, the process further includes: if not, setting a delayed callback time for the target transaction, and recording the number of delays for the target transaction; when the number of delays for the target transaction reaches a preset threshold, outputting an execution failure result for the target transaction.

[0013] In a possible implementation, the method further includes: pre-setting a delay duration corresponding to each transaction type for at least one transaction type; and setting a delayed callback time for the target transaction includes: determining a target transaction type for the target transaction, and setting the target delay duration corresponding to the target transaction type as the delayed callback time for the target transaction.

[0014] In a second aspect, an embodiment of the present specification provides an asynchronous interactive scheduling device, the device comprising:

[0015] A transaction opening module, for responding to an execution request of a target transaction, determining an internal request and an external request corresponding to the target transaction, wherein the processing flow of the internal request is an upstream flow of the receipt acceptance flow of the external request;

[0016] A transaction delay module is used to set a delayed callback time for the target transaction and suspend the transaction process of the target transaction before the delayed callback time ends;

[0017] A logic processing module, used for processing the internal request and sending the external request to an external server, so that the external server responds to the external request and returns a receipt result;

[0018] The transaction callback module is used to call back the target transaction when the delayed callback time ends, determine whether the processing result corresponding to the internal request has been obtained, and if so, execute the transaction process of the target transaction based on the receipt result.

[0019] In a third aspect, an embodiment of the present specification provides a computer program product comprising instructions, which, when executed on a computer or a processor, enables the computer or the processor to execute the steps of the above method.

[0020] In a fourth aspect, an embodiment of the present specification provides a computer storage medium, wherein the computer storage medium stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the steps of the above method.

[0021] In a fifth aspect, an embodiment of the present specification provides a terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is suitable for being loaded by the processor and executing the steps of the above method.

[0022] The beneficial effects brought by the technical solutions provided by some embodiments of this specification include at least:

[0023] The embodiment of this specification provides an asynchronous interactive scheduling method, which responds to the execution request of the target transaction, determines the internal request and external request corresponding to the target transaction, and the processing flow of the internal request is the upstream flow of the receipt acceptance flow of the external request; sets a delayed callback time for the target transaction, and suspends the transaction flow of the target transaction before the delay callback time ends; sends the external request to the external server so that the external server responds to the external request and returns the receipt result; calls back the target transaction when the delay callback time ends, and determines whether the processing result corresponding to the internal request has been obtained. If so, the transaction flow of the target transaction is executed based on the receipt result. Since the target transaction is set to delay processing, the internal request and the external request will not grab the lock of the target transaction after obtaining the result, but need to wait until the system actively calls the target transaction after the delay time ends, and then they are used together for the continued execution of the target transaction. Therefore, this delay time allows both the internal request and the external request to have more processing time, thereby solving the problem that the inconsistent processing speed of the internal request and the external request leads to the inconsistent state of the two result data, that is, the embodiment of this specification strengthens the stability of transaction execution in the system by using the means of delayed callback. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0025] Figure 1 An exemplary system architecture diagram of an asynchronous interactive scheduling method provided in an embodiment of this specification;

[0026] Figure 2 A system interaction diagram of an asynchronous interactive scheduling method provided in an embodiment of this specification;

[0027] Figure 3 A flowchart of an asynchronous interactive scheduling method provided in an embodiment of this specification;

[0028] Figure 4 A structural block diagram of an asynchronous interactive scheduling device provided in an embodiment of this specification;

[0029] Figure 5 A schematic diagram of the structure of a terminal provided in an embodiment of this specification. DETAILED DESCRIPTION

[0030] In order to make the features and advantages of the embodiments of this specification more obvious and easy to understand, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the embodiments of this specification.

[0031] When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of this specification. Instead, they are merely examples of devices and methods consistent with some aspects of the embodiments of this specification as detailed in the appended claims. And in the description of the embodiments of this specification, unless otherwise indicated, " / " means or, for example, A / B can mean A or B: "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B, can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of this specification, "multiple" refers to two or more than two.

[0032] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.

[0033] The complexity and integration of software products in the Internet industry are increasing day by day. They are no longer limited to a single system framework, but widely involve the cooperation and interaction between multiple software systems. The interactive activities between systems are rich and varied, covering not only the basic data transmission links, but also the precise docking of interfaces and the comprehensive sharing of information. Specifically, data transmission is the basis of communication between systems, which ensures that all kinds of transaction data can flow accurately and efficiently between different systems. Interface docking is the key technical means to achieve this circulation. Through carefully designed interface protocols, different systems can exchange and process data according to agreed rules. Information sharing further broadens the breadth of interaction between systems, allowing each system to make full use of each other's resources, achieve functional complementarity and data intercommunication. Through these in-depth and meticulous interactive activities, different software systems can form a closely connected organic whole, jointly providing users with a more complete, comprehensive and efficient service experience. Whether it is order processing on e-commerce platforms, message push on social networks, or capital flow in financial services, they are inseparable from the close collaboration and efficient interaction of multiple software systems behind them.

[0034] In terms of the communication mode between systems, it is further divided into two modes, synchronous communication and asynchronous communication, according to different actual needs and transaction scenarios. Synchronous communication requires the sender and the receiver to maintain a strict timing relationship during the data transmission process, that is, the sender must receive the confirmation response from the receiver before continuing to perform subsequent operations. Asynchronous communication is relatively more flexible, allowing the sender to continue to perform other tasks immediately after sending data without waiting for the receiver's response.

[0035] However, in actual applications, asynchronous communication methods sometimes lead to situations where the downstream system has asynchronously processed and received data flow receipts before the local transaction of the upstream system has been submitted. For example, after the payment platform sends a payment instruction to an external institution, it may need to perform a series of complex and time-consuming transaction logic processing (such as risk assessment, account deduction, etc.) internally. At this time, the local transaction has not been submitted and the data status is still in an uncertain state. However, the downstream system (such as a bank or a third-party payment institution) may have quickly completed the processing of the payment instruction and notified the payment platform of the processing results asynchronously. Faced with this situation, the payment platform often falls into a dilemma: on the one hand, it cannot immediately confirm and accept the receipt information of the downstream system because the local transaction has not been completed and the data status has not been finalized; on the other hand, if these receipt information are ignored, important transaction feedback and status updates may be missed, thereby affecting the accuracy and reliability of the entire payment process.

[0036] Therefore, the embodiments of this specification provide an asynchronous interaction scheduling method to solve the above-mentioned technical problem of cross-institution asynchronous interaction anomalies.

[0037] See also Figure 1 , Figure 1 An exemplary system architecture diagram of an asynchronous interactive scheduling method provided in an embodiment of this specification.

[0038] like Figure 1 As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 is used to provide a medium for a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired communication links or wireless communication links, for example, the wired communication link includes an optical fiber, a twisted pair, or a coaxial cable, and the wireless communication link includes a Bluetooth communication link, a Wireless-Fidelity (Wi-Fi) communication link, or a microwave communication link.

[0039] The terminal 101 can interact with the server 103 through the network 102 to receive messages from the server 103 or send messages to the server 103, or the terminal 101 can interact with the server 103 through the network 102 to receive messages or data sent by other users to the server 103. The terminal 101 can be hardware or software. When the terminal 101 is hardware, it can be various electronic devices, including but not limited to smart watches, smart phones, tablet computers, laptop portable computers and desktop computers. When the terminal 101 is software, it can be installed in the electronic devices listed above, which can be implemented as multiple software or software modules (for example: used to provide distributed services), or it can be implemented as a single software or software module, which is not specifically limited here.

[0040] In the embodiment of the present specification, first, terminal 101 responds to the execution request of the target transaction, determines the internal request and the external request corresponding to the target transaction, and the processing flow of the internal request is the upstream flow of the receipt acceptance flow of the external request; then, terminal 101 sets a delayed callback time for the target transaction, and suspends the transaction flow of the target transaction before the delayed callback time ends; at the same time, terminal 101 processes the internal request and sends the external request to the external server, so that the external server responds to the external request and returns the receipt result; when the delayed callback time ends, terminal 101 calls back the target transaction to determine whether the processing result corresponding to the internal request has been obtained, and if so, executes the transaction flow of the target transaction based on the receipt result.

[0041] The server 103 may be a business server that provides various services. It should be noted that the server 103 may be hardware or software. When the server 103 is hardware, it may be implemented as a distributed server cluster consisting of multiple servers, or it may be implemented as a single server. When the server 103 is software, it may be implemented as multiple software or software modules (for example, for providing distributed services), or it may be implemented as a single software or software module, which is not specifically limited here.

[0042] Alternatively, the system architecture may not include the server 103. In other words, the server 103 may be an optional device in the embodiments of this specification, that is, the method provided in the embodiments of this specification may be applied to a system structure that only includes the terminal 101, and the embodiments of this specification do not limit this.

[0043] It should be understood that Figure 1 The number of terminals, networks and servers in the figure is only for illustration and any number of terminals, networks and servers may be used according to implementation requirements.

[0044] See also Figure 2 , Figure 2 A flowchart of an asynchronous interactive scheduling method provided for an embodiment of this specification. The execution subject of the embodiment of this specification can be a terminal that executes asynchronous interactive scheduling, or a processor in the terminal that executes the asynchronous interactive scheduling method, or an asynchronous interactive scheduling service in the terminal that executes the asynchronous interactive scheduling method. For the convenience of description, the specific execution process of the asynchronous interactive scheduling method is introduced below by taking the execution subject being the processor in the terminal as an example.

[0045] like Figure 2 As shown, the asynchronous interaction scheduling method may at least include:

[0046] S202: In response to the execution request of the target transaction, determine the internal request and the external request corresponding to the target transaction, and the processing flow of the internal request is the upstream flow of the receipt acceptance flow of the external request.

[0047] Optionally, the processing of some complex transactions may involve cross-institutional and cross-system data interactions. In the face of such a link that requires external requests for processing results, it is generally chosen to process external requests and internal requests asynchronously, thereby improving transaction processing efficiency. Then, when receiving an execution request for a target transaction, if there is a need for asynchronous processing, the system will first determine the upstream and downstream processes that can be processed asynchronously corresponding to the target transaction. In the process of the target transaction, the processing flow of internal requests is usually upstream of the receipt acceptance process of external requests, among which internal requests usually refer to tasks or operations that can be processed independently within the system without relying on external resources or services, such as internal verification of data, logical operations, etc. External requests refer to requests that need to send requests to other servers or data sources outside the system to obtain necessary information or perform specific operations, such as calling a third-party API interface to obtain data, sending notifications to external services, etc.

[0048] S204: Set a delayed callback time for the target transaction, and suspend the transaction flow of the target transaction before the delayed callback time expires.

[0049] Optionally, due to the difference in request content between internal and external requests, and the difference in processing capabilities between internal and external systems, there will inevitably be a time difference in the processing time between internal and external requests. Generally speaking, the asynchronous processing logic is set to pull the transaction data stream once the external receipt result is obtained to handle the receipt result in the transaction process. However, if the internal request has not been processed, the transaction data stream will be occupied by the internal request processing process. At this time, the transaction process will fail due to the inconsistent data status of the two parties.

[0050] In the embodiments of the present specification, in order to avoid the problem of inconsistent interactive data status due to inconsistent internal and external processing efficiency, it is considered that the system can be given enough time to asynchronously process internal requests and wait for responses to external requests, thereby ensuring that the system can efficiently and orderly process the processing results of these requests. Based on this, a reasonable delayed callback time can be set for the target transaction. During the period when the delayed callback time is in effect, the transaction flow of the target transaction is temporarily suspended so that the target transaction will not continue to execute downward, thereby ensuring that before the delayed callback time ends, the target transaction will not be abnormal due to different external or internal processing efficiencies. This delay time can allow both internal and external requests more processing time, thereby solving the problem of inconsistent status of the two result data caused by inconsistent processing speeds of internal and external requests.

[0051] S206: Process the internal request and send the external request to the external server, so that the external server responds to the external request and returns a receipt result.

[0052] Optionally, for internal requests, the system will process them quickly and accurately according to established logic and rules, including but not limited to data verification, conversion, storage and other operations. At the same time, for external requests, the system will encapsulate them into a suitable format and send them to the corresponding external server through the network communication protocol. After receiving the request, the external server will process it according to its own logic and transaction rules, and return a receipt result to the system after the processing is completed. This receipt result usually contains important information such as the processing status of the request by the external server, the returned data or error information.

[0053] S208. When the delayed callback time ends, the target transaction is called back to determine whether the processing result corresponding to the internal request has been obtained. If so, the transaction flow of the target transaction is executed based on the receipt result.

[0054] Optionally, when the delayed callback time set for the target transaction ends, it means that the callback mechanism will be triggered to restore the target transaction from a suspended state to an executable state. At this time, when the target transaction is retrieved and is ready to be executed, first determine whether the processing result of the internal request has been successfully obtained. Since the target transaction is delayed in advance, both the internal request and the external request will have more time to get the result during this delay period. If the upstream internal request processing process has ended, the next transaction process of the target transaction can be continued based on the receipt result obtained. This may include but is not limited to updating the system status based on the returned data, executing subsequent transaction logic, and feeding back the processing results to the user.

[0055] In an embodiment of the present specification, an asynchronous interactive scheduling method is provided. In response to the execution request of the target transaction, the internal request and the external request corresponding to the target transaction are determined. The processing flow of the internal request is the upstream flow of the receipt acceptance flow of the external request; the delayed callback time is set for the target transaction, and the transaction flow of the target transaction is suspended before the delayed callback time ends; the internal request is processed, and the external request is sent to the external server, so that the external server responds to the external request and returns the receipt result; when the delayed callback time ends, the target transaction is called back to determine whether the processing result corresponding to the internal request has been obtained. If so, the transaction flow of the target transaction is executed based on the receipt result. Since the delayed processing is set for the target transaction, the internal request and the external request will not grab the lock of the target transaction after obtaining the result, but need to wait until the system actively calls the target transaction after the delay time ends, and then they are used together for the continued execution of the target transaction. Therefore, this delay time allows both the internal request and the external request to have more processing time, thereby solving the problem that the processing speed of the internal request and the external request is inconsistent, resulting in inconsistent states of the two result data. That is to say, the embodiment of the present specification enhances the stability of transaction execution in the system by using the delayed callback method.

[0056] See also Figure 3 , Figure 3 A flowchart of an asynchronous interactive scheduling method provided in an embodiment of this specification.

[0057] like Figure 3 As shown, the asynchronous interaction scheduling method may at least include:

[0058] S302: In response to the execution request of the target transaction, determine the internal request and the external request corresponding to the target transaction, and the processing flow of the internal request is the upstream flow of the receipt acceptance flow of the external request.

[0059] Regarding step S302, please refer to the detailed description in step S202, which will not be repeated here.

[0060] S304: Set a delayed callback time for the target transaction through a preset delayer, and add an unfinished tag to the target transaction.

[0061] Optionally, in the system, an asynchronous delay component can be used to implement the delay and callback of the target transaction. In the asynchronous delay component, different modules can be used to implement each step in the delay callback operation. Specifically, the asynchronous delay component may include a delayer and a scheduler, wherein the delayer is used to set the delay time and the scheduler is used to call back the target transaction. In the embodiment of the present specification, a delay callback time is set for the target transaction by a preset delayer, and an unfinished tag is added to the target transaction, so that the preset scheduler can retrieve and call back the target transaction with the unfinished tag at the end of the delay time.

[0062] Optionally, there are multiple ways to set the delayed callback time, for example, it can be set by countdown, starting from the current time, and calling back the target transaction after the countdown ends; it can also be set by adding the delay time to the current time to get the callback time, and calling back the target transaction according to the callback time.

[0063] In a possible implementation, different types of transactions often have different characteristics and processes, so the processing time in these transaction processes is often different, and different delay times can be preset according to different types of transactions, that is, the delay time corresponding to each transaction type can be preset for at least one transaction type. Based on this, when setting the delayed callback time for the target transaction, the target transaction type of the target transaction can be determined first, and then the target delay time corresponding to the target transaction type can be set as the delayed callback time of the target transaction.

[0064] S306: Acquire transaction data corresponding to the internal request, and calculate the transaction data based on calling a preset logic module corresponding to the internal request to obtain a processing result corresponding to the internal request.

[0065] Optionally, for the processing of internal requests, it is first necessary to accurately locate and extract the transaction data related to it according to the parameters or identifiers carried in the request. These data may be stored in a relational database, or in an unstructured data warehouse or distributed storage system. In order to ensure the accuracy and timeliness of the data, an efficient data retrieval algorithm can be used, combined with a cache mechanism to optimize the data access speed and reduce waiting time. Next, the system will call the pre-defined logic module according to the type and specific requirements of the internal request. These logic modules are the specific implementation of the transaction logic, which encapsulates the algorithms, rules and processes required to process specific transaction scenarios. For example, for an order processing request of an e-commerce platform, multiple logic modules such as inventory inspection, price calculation, and coupon application may be involved. Each logic module has been carefully designed and rigorously tested to ensure that it can correctly and efficiently process the corresponding transaction data. After calling the logic module, the system will pass the transaction data as input to the corresponding logic module for calculation processing. In this process, the logic module will perform various operations on the transaction data according to predefined rules and algorithms, such as addition, subtraction, multiplication, division, conditional judgment, loop iteration, etc., to obtain intermediate results or final processing results. In order to ensure the accuracy and reliability of the operation, the system will also monitor and verify the operation process to promptly detect and handle any possible exceptions or errors. After the logic module completes the operation, the result can be formatted or packaged to ensure that it meets the expected format and requirements of the internal request, and then the processing result is returned to the internal request.

[0066] S308: Send the external request to the external server, so that the external server responds to the external request and returns a receipt result.

[0067] Regarding step S308, please refer to the detailed description in step S206, which will not be repeated here.

[0068] S310, receiving the receipt result returned by the external server, and performing a validity check on the receipt result; if the receipt result passes the validity check, the receipt result is cached in a result cache pool, and the result cache pool is used to cache received and unused receipt results.

[0069] Optionally, the external server will return the receipt result after responding to the external request. Then, after the system receives the receipt result returned by the external server, it needs to first perform a legitimacy check on the received receipt result. This step is used to ensure that the receipt result is authentic and valid. The legitimacy check may include multiple aspects, such as verifying the signature of the receipt result, checking the correctness of the data format, confirming the timeliness of the information, and comparing the consistency between the expected result and the actual receipt result. These verification measures can effectively prevent malicious attacks, data tampering, or information errors.

[0070] Furthermore, if the receipt result passes the validity check, the system will cache the receipt result in the result cache pool. The result cache pool is a storage space dedicated to storing received and unused receipt results. The main function of this cache pool is to store flood water to improve the stability of the system. By caching the receipt results, the system can quickly access this information when needed without having to communicate with the external server again.

[0071] S312: Call back the target transaction from the transaction library through a preset scheduler when the delayed callback time ends. The preset scheduler is used to scan all transactions with unfinished tags in the transaction library and call back transactions that have ended the delayed callback time.

[0072] Optionally, it can be known from the introduction of the above embodiments that the asynchronous delay component includes a scheduler for retrieving and calling back the target transaction. Through the preset scheduler, the system will automatically and accurately call back the specified target transaction from the transaction library. Specifically, the preset scheduler has a built-in scanning algorithm that can periodically traverse the transaction library and scan and check the status label of each transaction. In this process, the scheduler will pay attention to those transactions marked as "unfinished", which are often the transactions that are being delayed. Once the delayed callback time of a transaction ends, it means that the transaction has met the conditions for being called back. At this time, the preset scheduler will respond quickly and start the callback process. This process includes retrieving all relevant information of the transaction from the transaction library, such as transaction type, operation content, associated data, etc., and processing it according to the pre-defined callback logic.

[0073] It should be noted that when the preset scheduler calls back a transaction, it will also intelligently adjust the order and speed of the callback according to factors such as the priority and urgency of the transaction and the current load of the system to ensure the stability and efficiency of the entire system. In this way, the preset scheduler not only effectively solves the delay problem in transaction processing, but also greatly improves the system's response speed and transaction processing capabilities.

[0074] S314: Determine whether the processing result corresponding to the internal request has been obtained. If so, execute the transaction process of the target transaction based on the receipt result; if not, set a delayed callback time for the target transaction and record the number of delays for the target transaction; when the number of delays for the target transaction reaches a preset number threshold, output an execution failure result for the target transaction.

[0075] Optionally, when the target transaction is retrieved and is ready to be executed, first determine whether the processing result of the internal request has been successfully obtained. If the upstream internal request processing process has ended, the next transaction process of the target transaction can be continued based on the received receipt result. This may include but is not limited to updating the system status based on the returned data, executing subsequent transaction logic, and feeding back the processing result to the user.

[0076] Optionally, if the upstream process is not yet completed when the target transaction is called back, that is, the processing result corresponding to the internal request has not yet been obtained in the embodiment of this specification, it means that the downstream process, that is, the normal acceptance of the receipt result, cannot proceed smoothly. Therefore, a delayed callback event can be set for the target transaction again, so that the target transaction is delayed again, providing more processing time for the upstream process.

[0077] Furthermore, if the upstream process cannot be completed for a long time, it is likely that it is not simply due to the large scale of operations, but rather an exception or error. Considering that the target transaction cannot be delayed indefinitely, the number of delays of the target transaction can be recorded starting from the second delay of the target transaction. When the number of delays of the target transaction reaches the preset threshold, it is determined that the target transaction cannot be carried out normally, and then the target transaction is output as an execution failure result. In this way, reasonable and planned delay callbacks for the target transaction are conducive to improving the stability of the transaction processing flow in the system.

[0078] In an embodiment of the present specification, an asynchronous interactive scheduling method is provided, which allocates different delay durations according to the specific type of transaction, so that each transaction can get a reasonable delay. The delayed callback time is set for the target transaction by a preset delayer, and an unfinished tag is added to the target transaction; the target transaction is called back from the transaction library at the end of the delayed callback time by a preset scheduler, and the preset scheduler is used to scan all transactions with unfinished tags in the transaction library and call back each transaction that has ended the delayed callback time. During the delay period, only a simple transaction parameter check is performed on the receipt result returned externally. After the check is completed, the result data is submitted to the asynchronous component for flood storage, waiting for use after the delay ends. If the internal processing result has not been obtained after the delay ends, the delay wait is repeated again; if the number of delays reaches a certain threshold, an error is directly reported for the current transaction, and the delay wait is no longer continued. By performing reasonable and planned delayed callbacks on the target transaction, it is beneficial to improve the stability of the transaction processing flow in the system.

[0079] See also Figure 4 , Figure 4 This is a structural block diagram of an asynchronous interactive scheduling device provided in an embodiment of this specification. Figure 4 As shown, the asynchronous interaction scheduling device 400 includes:

[0080] The transaction opening module 410 is used to respond to the execution request of the target transaction, determine the internal request and the external request corresponding to the target transaction, and the processing flow of the internal request is the upstream flow of the receipt acceptance flow of the external request;

[0081] The transaction delay module 420 is used to set a delayed callback time for the target transaction and suspend the transaction process of the target transaction before the delayed callback time ends;

[0082] The logic processing module 430 is used to process the internal request and send the external request to the external server, so that the external server responds to the external request and returns a receipt result;

[0083] The transaction callback module 440 is used to call back the target transaction when the delayed callback time ends, determine whether the processing result corresponding to the internal request has been obtained, and if so, execute the transaction process of the target transaction based on the receipt result.

[0084] Optionally, the transaction delay module 420 is also used to set a delayed callback time for the target transaction through a preset delayer, and add an unfinished tag to the target transaction; the transaction callback module is also used to call back the target transaction from the transaction library at the end of the delayed callback time through a preset scheduler, and the preset scheduler is used to scan all transactions with unfinished tags in the transaction library and call back each transaction that has ended the delayed callback time.

[0085] Optionally, the logic processing module 430 is used to obtain transaction data corresponding to the internal request, and to perform operations on the transaction data based on calling a preset logic module corresponding to the internal request to obtain a processing result corresponding to the internal request.

[0086] Optionally, the asynchronous interactive scheduling device 400 also includes: a legitimacy verification module, which is used to receive the receipt result returned by the external server and perform legitimacy verification on the receipt result; if the receipt result passes the legitimacy verification, the receipt result is cached in a result cache pool, and the result cache pool is used to cache received and unused receipt results.

[0087] Optionally, the asynchronous interaction scheduling device 400 also includes: a delay reset module, which is used to set a delay callback time for the target transaction and record the number of delays of the target transaction; when the number of delays of the target transaction reaches a preset number threshold, output an execution failure result for the target transaction.

[0088] Optionally, the asynchronous interaction scheduling device 400 also includes: a delay duration preset module, used to pre-set the delay duration corresponding to each transaction type for at least one transaction type; a transaction delay module, also used to determine the target transaction type of the target transaction, and set the target delay duration corresponding to the target transaction type as the delay callback time of the target transaction.

[0089] In an embodiment of the present specification, an asynchronous interactive scheduling device is provided, wherein a transaction start module is used to respond to the execution request of the target transaction, determine the internal request and the external request corresponding to the target transaction, and the processing flow of the internal request is the upstream flow of the receipt acceptance flow of the external request; a transaction delay module is used to set a delayed callback time for the target transaction, and suspend the transaction flow of the target transaction before the delayed callback time ends; a logic processing module is used to process the internal request and send the external request to the external server so that the external server responds to the external request and returns the receipt result; a transaction callback module is used to call back the target transaction when the delayed callback time ends, and determine whether the processing result corresponding to the internal request has been obtained. If so, the transaction flow of the target transaction is executed based on the receipt result. Since the target transaction is delayed, the internal request and the external request will not grab the lock of the target transaction after obtaining the result, but need to wait until the system actively calls the target transaction after the delay time ends, and then they are used together for the continued execution of the target transaction. Therefore, this delay time allows both internal requests and external requests more processing time, thereby solving the problem of inconsistent status of the two result data caused by inconsistent processing speeds of internal requests and external requests. In other words, the embodiment of this specification enhances the stability of transaction execution in the system by using delayed callback.

[0090] The embodiments of this specification provide a computer program product including instructions. When the computer program product is executed on a computer or a processor, the computer or the processor executes the steps of any one of the methods in the above embodiments.

[0091] The embodiments of this specification also provide a computer storage medium, which can store multiple instructions, and the instructions are suitable for being loaded by a processor and executing the steps of any method in the above embodiments.

[0092] See also Figure 5 , Figure 5 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Figure 5 As shown, the terminal 500 may include: at least one terminal processor 501 , at least one network interface 504 , a user interface 503 , a memory 505 , and at least one communication bus 502 .

[0093] The communication bus 502 is used to realize the connection and communication between these components.

[0094] The user interface 503 may include a display screen (Display) and a camera (Camera), and the optional user interface 503 may also include a standard wired interface and a wireless interface.

[0095] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0096] Among them, the terminal processor 501 may include one or more processing cores. The terminal processor 501 uses various interfaces and lines to connect various parts in the entire terminal 500, and executes various functions and processes data of the terminal 500 by running or executing instructions, programs, code sets or instruction sets stored in the memory 505, and calling data stored in the memory 505. Optionally, the terminal processor 501 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The terminal processor 501 can integrate one or a combination of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communication. It can be understood that the above-mentioned modem may not be integrated into the terminal processor 501, and it can be implemented separately through a chip.

[0097] Among them, the memory 505 may include a random access memory (Random Access Memory, RAM) and may also include a read-only memory (Read-Only Memory, ROM). Optionally, the memory 505 includes a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 505 may also be optionally at least one storage device located away from the aforementioned terminal processor 501. As Figure 5 As shown, the memory 505 as a computer storage medium may include an operating system, a network communication module, a user interface module, and an asynchronous interaction scheduling program.

[0098] exist Figure 5 In the terminal 500 shown, the user interface 503 is mainly used to provide an input interface for the user and obtain the data input by the user; and the terminal processor 501 can be used to call the asynchronous interaction scheduling program stored in the memory 505, and specifically perform the following operations:

[0099] In response to the execution request of the target transaction, an internal request and an external request corresponding to the target transaction are determined, and the processing flow of the internal request is an upstream flow of the receipt acceptance flow of the external request;

[0100] Set a delayed callback time for the target transaction and suspend the transaction process of the target transaction before the delayed callback time ends;

[0101] Process internal requests and send external requests to external servers, so that the external servers respond to the external requests and return receipt results;

[0102] When the delayed callback time ends, the target transaction is called back to determine whether the processing result corresponding to the internal request has been obtained. If so, the transaction process of the target transaction is executed based on the receipt result.

[0103] In some embodiments, when the terminal processor 501 executes setting a delayed callback time for a target transaction, the terminal processor 501 specifically performs the following steps: setting a delayed callback time for the target transaction through a preset delayer, and adding an unfinished tag to the target transaction; when the terminal processor 501 executes calling back the target transaction when the delayed callback time ends, the terminal processor 501 specifically performs the following steps: calling back the target transaction from the transaction library at the end of the delayed callback time through a preset scheduler, and the preset scheduler is used to scan all transactions with unfinished tags in the transaction library and call back each transaction for which the delayed callback time has ended.

[0104] In some embodiments, when the terminal processor 501 executes processing of an internal request, it specifically performs the following steps: obtaining transaction data corresponding to the internal request, and performing operations on the transaction data based on calling a preset logic module corresponding to the internal request to obtain a processing result corresponding to the internal request.

[0105] In some embodiments, after executing sending the external request to the external server so that the external server responds to the external request and returns a receipt result, the terminal processor 501 further specifically performs the following steps: receiving the receipt result returned by the external server, and performing a legitimacy check on the receipt result; if the receipt result passes the legitimacy check, caching the receipt result in a result cache pool, which is used to cache received and unused receipt results.

[0106] In some embodiments, after determining whether the processing result corresponding to the internal request has been obtained, the terminal processor 501 further specifically performs the following steps: if not, a delayed callback time is set for the target transaction, and the number of delays of the target transaction is recorded; when the number of delays of the target transaction reaches a preset threshold, an execution failure result is output for the target transaction.

[0107] In some embodiments, the terminal processor 501 further specifically performs the following steps: pre-setting a delay duration corresponding to each transaction type for at least one transaction type; when the terminal processor 501 sets a delayed callback time for a target transaction, it specifically performs the following steps: determining a target transaction type for the target transaction, and setting a target delay duration corresponding to the target transaction type as the delayed callback time of the target transaction.

[0108] In the several embodiments provided in this specification, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules is only a logical function division, and there may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0109] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0110] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The above computer program product includes one or more computer instructions. When the above computer program instructions are loaded and executed on a computer, the above process or function according to the embodiment of this specification is generated in whole or in part. The above computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The above computer instructions can be stored in a computer-readable storage medium or transmitted by the above computer-readable storage medium. The above computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The above computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, data center, etc. that contains one or more available media integrated. The above-mentioned available media can be magnetic media (for example, floppy disks, hard disks, tapes), optical media (for example, digital versatile discs (DVD)), or semiconductor media (for example, solid state drives (SSD)), etc.

[0111] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0112] In addition, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0113] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0114] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0115] The above is a description of an asynchronous interactive scheduling method, device, storage medium and terminal provided in the embodiments of this specification. For technical personnel in this field, according to the ideas of the embodiments of this specification, there may be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on the embodiments of this specification.

Claims

1. An asynchronous interactive scheduling method, the method comprising: In response to the execution request of the target transaction, an internal request and an external request corresponding to the target transaction are determined, and the processing flow of the internal request is an upstream flow of the receipt acceptance flow of the external request; Setting a delayed callback time for the target transaction, and suspending the transaction flow of the target transaction before the delayed callback time expires; Processing the internal request, and sending the external request to an external server, so that the external server responds to the external request and returns a receipt result; When the delayed callback time ends, the target transaction is called back to determine whether the processing result corresponding to the internal request has been obtained. If so, the transaction process of the target transaction is executed based on the receipt result.

2. According to the method of claim 1, setting a delayed callback time for the target transaction comprises: Setting a delayed callback time for the target transaction through a preset delayer, and adding an unfinished tag to the target transaction; The calling back the target transaction when the delayed calling back time ends includes: The target transaction is called back from the transaction library by a preset scheduler when the delayed callback time ends. The preset scheduler is used to scan all transactions with unfinished tags in the transaction library and call back transactions that have ended the delayed callback time.

3. The method according to claim 1, wherein processing the internal request comprises: Transaction data corresponding to the internal request is obtained, and based on calling a preset logic module corresponding to the internal request, the transaction data is operated to obtain a processing result corresponding to the internal request.

4. The method according to claim 1, after sending the external request to the external server so that the external server responds to the external request and returns a receipt result, further comprising: Receive the receipt result returned by the external server, and perform a validity check on the receipt result; If the receipt result passes the legitimacy check, the receipt result is cached in a result cache pool, and the result cache pool is used to cache received and unused receipt results.

5. The method according to claim 1, after determining whether the processing result corresponding to the internal request has been obtained, further comprising: If not, a delayed callback time is set for the target transaction, and the number of delays of the target transaction is recorded; When the delay times of the target transaction reaches a preset times threshold, an execution failure result is output for the target transaction.

6. The method according to claim 1, further comprising: Presetting a delay time corresponding to each transaction type for at least one transaction type; The step of setting a delayed callback time for the target transaction includes: A target transaction type of the target transaction is determined, and a target delay duration corresponding to the target transaction type is set as a delay callback time of the target transaction.

7. An asynchronous interactive scheduling device, the device comprising: A transaction opening module, for responding to an execution request of a target transaction, determining an internal request and an external request corresponding to the target transaction, wherein the processing flow of the internal request is an upstream flow of a receipt acceptance flow of the external request; A transaction delay module, used to set a delayed callback time for the target transaction, and suspend the transaction process of the target transaction before the delayed callback time expires; A logic processing module, used for processing the internal request and sending the external request to an external server, so that the external server responds to the external request and returns a receipt result; The transaction callback module is used to call back the target transaction when the delayed callback time ends, determine whether the processing result corresponding to the internal request has been obtained, and if so, execute the transaction process of the target transaction based on the receipt result.

8. A computer program product comprising instructions, which, when executed on a computer or a processor, causes the computer or the processor to execute the steps of the method according to any one of claims 1 to 6.

9. A computer storage medium storing a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the steps of the method according to any one of claims 1 to 6.

10. A terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of claims 1 to 6 when executing the computer program.

Images