Long-lived transaction processing method, system, storage medium, and long-lived transaction processing terminal

Abstract

The application provides a long-living transaction processing method, system, storage medium and long-living transaction processing terminal, the method comprises the following steps: receiving long-living transaction processing parameters provided by a client based on an orchestrator; obtaining a long-living transaction execution strategy provided by the client; pre-setting long-living transaction orchestration logic corresponding to the long-living transaction recovery strategy; executing the corresponding long-living transaction orchestration logic based on the long-living transaction processing parameters and the long-living transaction recovery strategy; providing an interface required by the long-living transaction orchestration logic based on a participant; receiving an execution request of the long-living transaction orchestration logic of the client based on a management end. The long-living transaction processing method, system, storage medium and long-living transaction processing terminal of the application effectively improve the data processing efficiency in the data processing process of multiple business fields.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of network communication, and particularly relates to a long lived transaction processing method and system, a storage medium and a long lived transaction processing terminal. BACKGROUND

[0002] In the field of computer technology, with the increase of the business fields involved, data of multiple business fields is processed by the same transaction. In order to guarantee the integrity of the storage of the data of multiple business fields, the database will perform a locking operation until the transaction is completed, thereby preventing the data from being overlapped and the stored data from being inconsistent due to the simultaneous performance of other similar operations. However, the more the fields of the lock, the greater the probability of the database blocking. With the increase of the blocking, the data processing time also presents a linear rise, and even a deadlock occurs, resulting in a failure of data processing or even an unavailability of the associated system.

[0003] In the prior art, the above problems are usually solved by using a method of splitting the database and the table. The method specifically includes the following steps:

[0004] (1) determining the business data to be split.

[0005] (2) determining the splitting rule of the business data to be split. The splitting rule includes vertical splitting, horizontal splitting and vertical splitting. For example, the data of different business fields is stored in different databases to realize horizontal splitting, and the data of the same business field is stored in different databases.

[0006] (3) synchronizing the existing data to the new database, and continuously synchronizing the incremental data to the new and old databases.

[0007] (4) after the new database is stable, cutting off the synchronization of the old database, and switching the data source to the new database.

[0008] However, the above method has the following disadvantages:

[0009] a. The feasibility is very low, and the implementation cost is high. Splitting the originally together business data not only needs to consider the data itself, but also needs to consider the associated system functions; not only needs to split the data, but also needs to modify the data acquisition method of the related system functions.

[0010] b. The essential problem is not solved. With the development of the business, the originally simple business field will become a complex business field, and the originally single business field will naturally become multiple business fields with the iteration of the business. When splitting again, the problem in (a) will be faced again.

[0011] c. Data consistency cannot be guaranteed. Because when data is split into multiple database instances, each database instance is an individual entity and cannot perceive the data in other databases. SUMMARY

[0012] The application aims to provide a long-lived transaction processing method, system, storage medium and long-lived transaction processing terminal, which effectively improves the data processing efficiency in the data processing process of multiple business fields.

[0013] In a first aspect, the application provides a long-lived transaction processing method, which comprises: receiving long-lived transaction processing parameters provided by a client based on an orchestrator; obtaining a long-lived transaction execution strategy provided by the client; pre-setting long-lived transaction orchestration logic corresponding to the long-lived transaction recovery strategy; executing the corresponding long-lived transaction orchestration logic based on the long-lived transaction processing parameters and the long-lived transaction recovery strategy; providing an interface required by the long-lived transaction orchestration logic based on a participating end; receiving an execution request of the long-lived transaction orchestration logic from the client based on a management end, which is used to display the execution request and enable retry, wherein the type of the execution request includes: execution success request and execution failure request, and the content of the execution request includes: the long-lived transaction processing parameters, long-lived transaction execution context and execution exception information.

[0014] In an implementation form of the first aspect, the orchestrator is executed on an arbitrary host, and the long-lived transaction comprises a plurality of sub-transaction nodes; the sub-transaction nodes comprise normal transaction execution node, normal transaction node, transaction backtracking execution node and transaction backtracking node.

[0015] In an implementation form of the first aspect, the long-lived transaction execution strategy comprises a mission-critical strategy and a time backtracking strategy.

[0016] In an implementation form of the first aspect, the long-lived transaction orchestration logic corresponding to the mission-critical strategy comprises:

[0017] determining the execution order of the plurality of sub-transaction nodes to be executed currently;

[0018] for the current sub-transaction node, obtaining the corresponding normal transaction node and normal transaction execution node;

[0019] If the processing result of the current normal transaction node is yes, the current normal transaction node is processed according to the long-living transaction processing parameter; otherwise, it is determined whether the current sub-transaction node has a next sub-transaction node; if yes, the next normal transaction node is processed until all normal transaction nodes are processed; if no, the long-living transaction scheduling logic is ended.

[0020] In an implementation manner of the first aspect, the time travel strategy corresponds to long-living transaction scheduling logic including:

[0021] The execution order of the current to-be-executed sub-transaction nodes is determined.

[0022] For the current sub-transaction node, the corresponding normal transaction node and normal transaction execution node are obtained.

[0023] The current normal transaction execution node is processed according to the long-living transaction processing parameter; if the processing result of the current normal transaction node is no, it is determined whether the current sub-transaction node has a next sub-transaction node; otherwise, the current normal transaction node is processed according to the long-living transaction processing parameter.

[0024] When the normal transaction node is processed normally, it is determined whether the current sub-transaction node has a next sub-transaction node; if yes, the next normal transaction node is processed; if no, the long-living transaction scheduling logic is ended.

[0025] When the normal transaction node is processed abnormally, the transaction rollback execution node and transaction rollback node corresponding to the current sub-transaction node are obtained.

[0026] The transaction rollback execution node is processed according to the long-living transaction processing parameter; if the processing result of the transaction rollback execution node is yes, the transaction rollback node is processed according to the long-living transaction processing parameter; if the processing result of the rollback transaction execution node is no, it is determined whether the current sub-transaction node has a previous sub-transaction node; if yes, the transaction rollback execution node and transaction rollback node corresponding to the previous sub-transaction node are executed until the processing of the transaction rollback execution node and transaction rollback node corresponding to all sub-transaction nodes is completed; if no, the long-living transaction scheduling logic is ended.

[0027] In an implementation form of the first aspect, further comprising storing the long-lived transaction processing parameters and the long-lived transaction execution context into a storage medium before execution of the sub-transaction nodes or after execution of all the sub-transaction nodes; the long-lived transaction execution context comprises the location of the sub-transaction nodes and the long-lived transaction recovery strategy;

[0028] When the abnormal sub-transaction node is repaired, the management end obtains the corresponding long-lived transaction processing parameters and the long-lived transaction execution context from the storage medium, and makes the host computer where the orchestrator is located receive a request for re-executing the sub-transaction node.

[0029] In an implementation form of the first aspect, the sub-transaction node is an interface provided by an arbitrary application, the interface is provided by the participant, and supports an arbitrary technical protocol.

[0030] In an implementation form of the first aspect, the interface of the participant accessed by the sub-transaction node in the orchestrator is accessed by a corresponding software development kit provided by the participant or is wrapped into a software development kit according to an interface technical protocol provided by the participant, so that the participant does not need to be aware of the orchestrator and only needs to provide an access interface.

[0031] In a second aspect, the application provides a long-lived transaction processing system, the system comprising an orchestrator, a participant and a management end.

[0032] The orchestrator is configured to receive long-lived transaction processing parameters provided by a client, obtain a long-lived transaction execution strategy provided by the client, pre-set a long-lived transaction recovery strategy corresponding to long-lived transaction orchestration logic, and execute the corresponding long-lived transaction orchestration logic based on the long-lived transaction processing parameters and the long-lived transaction recovery strategy.

[0033] The participant is configured to provide an interface required by the long-lived transaction orchestration logic.

[0034] The management end is configured to receive an execution request of the long-lived transaction orchestration logic from the client, display the execution request and enable retry, wherein the type of the execution request comprises an execution success request and an execution failure request, and the content of the execution request comprises the long-lived transaction processing parameters, a long-lived transaction execution context and execution exception information.

[0035] In a third aspect, the application provides a long-lived transaction processing terminal, the long-lived transaction processing terminal comprising a processor and a memory; the memory is configured to store a computer program; and the processor is configured to execute the computer program stored in the memory, so that the long-lived transaction processing terminal executes the long-lived transaction processing method described above.

[0036] In a fourth aspect, the present application provides a computer readable storage medium, which stores a computer program, and the program is executed by a long-living transaction processing terminal to implement the long-living transaction processing method.

[0037] As described above, the long-living transaction processing method, system, storage medium and long-living transaction processing terminal of the present application have the following beneficial effects:

[0038] The long-living transaction processing method, system, storage medium and long-living transaction processing terminal of the present application solve the problems of low efficiency and insufficient performance in the prior art in the data processing of multiple business fields, provide a new data processing method for multiple business fields, effectively improve the data processing efficiency, and improve the access performance of application services. BRIEF DESCRIPTION OF DRAWINGS

[0039] Figure 1 A structural schematic diagram of the long-living transaction processing terminal according to an embodiment of the present application is shown;

[0040] Figure 2 A flowchart of the long-living transaction processing method according to an embodiment of the present application is shown;

[0041] Figure 3 A framework diagram of the long-living transaction orchestration logic corresponding to the mission must arrive strategy according to an embodiment of the present application is shown;

[0042] Figure 4 A framework diagram of the long-living transaction orchestration logic corresponding to the time travel strategy according to an embodiment of the present application is shown;

[0043] Figure 5 A flowchart of the long-living transaction orchestration logic corresponding to the mission must arrive strategy according to an embodiment of the present application is shown;

[0044] Figure 6 A flowchart of the long-living transaction orchestration logic corresponding to the time travel strategy according to an embodiment of the present application is shown;

[0045] Figure 7 An application scenario schematic diagram of the long-living transaction processing method according to an embodiment of the present application is shown;

[0046] Figure 8 A structural schematic diagram of the long-living transaction processing system according to an embodiment of the present application is shown;

[0047] Figure 9 A structural schematic diagram of the long-living transaction processing terminal according to an embodiment of the present application is shown.

[0048] Element No.

[0049] 81 orchestrator

[0050] 82 participating end

[0051] 83 managing end

[0052] 91 processing unit

[0053] 92 memory

[0054] 921 random access memory

[0055] 922 cache memory

[0056] 923 storage system

[0057] 924 program / utility

[0058] 9241 program module

[0059] 93 bus

[0060] 94 input / output interface

[0061] 95 network adapter DETAILED DESCRIPTION

[0062] The present application is herein described, by way of example only, with the

[0063] It is to be understood that the drawings are designed solely for the purpose of illustration and are not intended to limit the scope of the present application in any way. Further, the shapes and proportions of the various layers, regions, films, and / or elements in the drawings are not necessarily drawn to scale as some of these components have been exaggerated or minimized for clarity. Moreover, the various

[0064] The following embodiments of the present application provide a long-lived transaction processing method, which can be applied to, for example, a distributed database system as shown in FIG. 1. Figure 1The long-lived transaction processing terminal shown in the present application can include a mobile phone 11, a tablet computer 12, a notebook computer 13, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), and the like with wireless charging function, and the specific type of the long-lived transaction processing terminal is not limited in the embodiments of the present application.

[0065] For example, the long-lived transaction processing terminal can be a station (STATION, ST) in a WLAN with wireless charging function, can be a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA) device, a handheld device with wireless charging function, a computing device or other processing device, a computer, a laptop, a handheld communication device, a handheld computing device, and / or other devices for communicating over a wireless system and next-generation communication systems, such as a mobile terminal in a 5G network, a mobile terminal in a future evolved public land mobile network (PLMN), or a mobile terminal in a future evolved non-terrestrial network (NTN), and the like.

[0066] For example, the long-lived transaction processing terminal can communicate with the network and other devices through wireless communication. The wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS can include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou navigation satellite system (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS).

[0067] The technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings of the embodiments of the present application.

[0068] First, the special terms appearing in the present application will be explained.

[0069] Long transaction: In order to ensure data consistency, when operating database data, multiple domain data are usually executed together, which is called long transaction. A long transaction often contains multiple sub-transactions, each sub-transaction has different business domain data to execute, and these sub-transactions interfere with each other. The more business domain data, the lower the performance of accessing the database. Since different long transactions cannot access the same data in the same business domain, once data blocking occurs, it needs to wait for the completion of other long transactions.

[0070] Long transaction: the ability to break down multiple sub-transactions in a long transaction into separate, independent, non-interfering capability nodes (which do not depend on the database, can be any computer service, program provided data interface), and combine these capability nodes according to the orchestration strategy. When any node has an exception, according to the recovery strategy, the data is recovered to ensure data consistency. The value of long transaction mainly has the following two points:

[0071] 1. Solve the performance problem caused by the interaction of multiple business domains during the execution of a long transaction;

[0072] 2. Solve the data consistency problem in multi-capability orchestration.

[0073] As shown in Figure 2 , in an embodiment, the long transaction processing method of the present application comprises the following steps:

[0074] Step S1, based on the orchestrator receiving the long transaction processing parameters provided by the client; obtaining the long transaction execution strategy provided by the client; pre-setting the long transaction recovery strategy corresponding to the long transaction orchestration logic; based on the long transaction processing parameters and the long transaction recovery strategy, the corresponding long transaction orchestration logic is executed.

[0075] Specifically, the orchestrator is executed on any host. Through the setting of the orchestrator, the long transaction processing method of the present application can be applied to any host without the need for special adaptation, thereby expanding the application scenario.

[0076] The client sends a long transaction processing request containing long transaction processing parameters to the long transaction processing terminal of the present application. The long transaction processing terminal obtains the long transaction processing parameters. In an embodiment, the long transaction processing parameters include a long transaction processing identifier and a custom parameter. The long transaction processing identifier is used to indicate the long transaction that needs to be processed. The custom parameter is used to set the user required parameter.

[0077] The long transaction recovery strategy includes a mission must be accomplished strategy and a time back strategy. In the present application, the long transaction includes multiple sub-transaction nodes; the sub-transaction node includes a normal transaction execution node, a normal transaction node, a transaction back execution node and a transaction back node. Accordingly, the mission must be accomplished strategy is mainly aimed at the scenario of mission must be accomplished, all normal transaction nodes are expected to be executed, and the scenario of data back is not considered. The time back strategy mainly faces the scenario that when the normal transaction node has an exception, additional consideration is needed on how to back up the data affected by the execution of the normal transaction node through the corresponding transaction back node.

[0078] The client selects a suitable long-lived transaction recovery strategy according to its own needs and provides it to the orchestrator.

[0079] Specifically, the orchestrator is pre-configured with different long-lived transaction orchestration logics for different long-lived transaction recovery strategies.

[0080] As shown in FIG. 6, in an embodiment, the long-lived transaction orchestration logic corresponding to the mission-critical strategy includes: Figure 3

[0081] 31) determining the execution order of the plurality of sub-transaction nodes to be executed currently.

[0082] For example, as shown in FIG. 7, the long-lived transaction includes N sub-transaction nodes, and the execution order of the N sub-transaction nodes is sub-transaction node 1, sub-transaction node 2, …, and sub-transaction node N, which respectively correspond to normal transaction node 1, normal transaction node 2, …, and normal transaction node N. Figure 3

[0083] 32) for the current sub-transaction node, obtaining the corresponding normal transaction node and normal transaction execution node.

[0084] In the mission-critical strategy, only the normal transaction node and the normal transaction execution node are processed, and the transaction rollback execution node and the transaction rollback node are not involved.

[0085] 33) processing the current normal transaction execution node according to the long-lived transaction processing parameter; if the processing result of the current normal transaction execution node is yes, processing the current normal transaction node according to the long-lived transaction processing parameter, otherwise, judging whether the current sub-transaction node has a next sub-transaction node; if yes, processing the next normal transaction node until all normal transaction nodes are processed; if no, ending the long-lived transaction orchestration logic.

[0086] In the mission-critical strategy, only the normal transaction node and the normal transaction execution node are processed, and the transaction rollback execution node and the transaction rollback node are not involved.

[0087] As shown in FIG. 8, in an embodiment, the long-lived transaction orchestration logic corresponding to the time travel strategy includes: Figure 4

[0088] 31’) determining the execution order of the plurality of sub-transaction nodes to be executed currently.

[0089] For example, as shown in FIG. 9, the long-lived transaction includes N sub-transaction nodes, and the execution order of the N sub-transaction nodes is sub-transaction node 1, sub-transaction node 2, …, and sub-transaction node N, which respectively correspond to normal transaction node 1, normal transaction node 2, …, and normal transaction node N. Figure 4 ​​​The N sub-transaction nodes include a sub-transaction node 1, a sub-transaction node 2, and a sub-transaction node N, which correspond to a normal transaction node 1, a normal transaction node 2, and a normal transaction node N, respectively, and a transaction rollback node 1, a transaction rollback node 2, and a transaction rollback node N.

[0090] 32') For the current sub-transaction node, the corresponding normal transaction node and normal transaction execution node are obtained.

[0091] In the time travel strategy, the normal transaction node and the normal transaction execution node are processed first, and the transaction rollback execution node and the transaction rollback node are not involved.

[0092] 33') For the current sub-transaction node, the corresponding normal transaction node and normal transaction execution node are obtained; the current normal transaction execution node is processed according to the long-lived transaction processing parameter; if the processing result of the current normal transaction execution node is no, it is determined whether the current sub-transaction node has a next sub-transaction node, otherwise the current normal transaction node is processed according to the long-lived transaction processing parameter.

[0093] According to the execution order, the sub-transaction nodes are processed. For each sub-transaction node, the current normal transaction execution node is processed according to the long-lived transaction processing parameter first. Only in the case that the processing result of the current normal transaction execution node is yes, the normal transaction node is processed, otherwise the processing of the next sub-transaction node is performed.

[0094] 34') When the normal transaction node processing is normal, it is determined whether the current sub-transaction node has a next sub-transaction node, if yes, the next normal transaction node is processed; if no, the long-lived transaction scheduling logic is ended, and the long-lived transaction processing result is returned to the client.

[0095] 35') When the normal transaction node processing is abnormal, the transaction rollback execution node and the transaction rollback node corresponding to the current sub-transaction node are obtained.

[0096] If the normal transaction node execution is abnormal, the rollback process needs to be entered, and the transaction rollback execution node and the transaction rollback node corresponding to the current sub-transaction node are obtained. If the current normal transaction node is executed normally, the execution of the normal transaction node of the next sub-transaction node is performed, and the subsequent normal transaction nodes are iteratively processed until all the normal transaction nodes of the sub-transaction nodes are executed or the rollback process is entered. In the rollback process, the transaction rollback execution node and the transaction rollback node are processed.

[0097] 36') processing the transaction backtracking whether to execute node according to the long-living transaction processing parameter, if the processing result of the transaction backtracking whether to execute node is yes, processing the transaction backtracking node according to the long-living transaction processing parameter; if the processing result of the transaction backtracking whether to execute node is no, judging whether the current sub-transaction node exists a previous sub-transaction node; if yes, executing the transaction backtracking whether to execute node and the transaction backtracking node corresponding to the previous sub-transaction node, and iterating the processing of the transaction backtracking whether to execute node and the transaction backtracking node of the previous level until completing the processing of the transaction backtracking whether to execute node and the transaction backtracking node corresponding to all sub-transaction nodes; if no, ending the long-living transaction orchestration logic.

[0098] Firstly, the transaction backtracking whether to execute node of the current sub-transaction node is processed. If the processing result of the transaction backtracking whether to execute node is yes, the transaction backtracking node is processed. If the processing result of the transaction backtracking whether to execute node is no, it is judged whether the current sub-transaction node exists a previous sub-transaction node. When yes, the transaction backtracking whether to execute node and the transaction backtracking node corresponding to the previous sub-transaction node are executed, and the processing of the transaction backtracking whether to execute node and the transaction backtracking node of the previous level is iterated until completing the processing of the transaction backtracking whether to execute node and the transaction backtracking node corresponding to all sub-transaction nodes, and returning the long-living transaction processing result to the client.

[0099] The orchestrator determines the long-living transaction to be processed and the long-living transaction recovery strategy to be adopted according to the received long-living transaction processing parameter and the long-living transaction recovery strategy, and processes the long-living transaction according to the long-living transaction recovery strategy.

[0100] The long-living transaction processing method can make a long transaction become multiple sub-transaction nodes, and each sub-transaction node can be provided by an interface of a different application and be uniformly governed by a long-living transaction orchestration strategy. The data involved in the sub-transactions can be provided by the same database or different databases. If provided by the same database, the cost of data migration and system function reconstruction is avoided. If provided by different databases, the data consistency can be ensured by the long-living transaction strategy. In the long-living transaction orchestration strategy, it is not concerned which database provides the data involved in the sub-transactions of the sub-transaction nodes, and whether the data in the sub-transactions belongs to the same database, which is only determined according to actual needs. In an embodiment, the sub-transaction node is an interface provided by an arbitrary application, i.e., a computer-recognizable interface can be used as a sub-transaction node.

[0101] In an embodiment, the long-living transaction processing method further comprises storing the long-living transaction processing parameters and the long-living transaction execution context into a storage medium before or after the execution of all the sub-transaction nodes. The long-living transaction execution context comprises the location of the currently executed sub-transaction node and the long-living transaction recovery strategy. When the long-living transaction recovery strategy is the mission-critical strategy and the normal transaction node is abnormal, the normal transaction node stops executing; when the long-living transaction recovery strategy is the time-back strategy and the transaction backtracking node is abnormal, the transaction backtracking node stops executing; after the abnormal sub-transaction node is repaired, the management end obtains the corresponding long-living transaction processing parameters and the long-living transaction execution context from the storage medium, and makes the host computer where the orchestrator is located receive a request for re-executing the sub-transaction node.

[0102] In an implementation form of the first aspect

[0103] In an implementation form of the first aspect,

[0104] Step S2, providing an interface required by the long-living transaction orchestration logic based on the participating end.

[0105] The sub-transaction node is an interface provided by any application, the interface is provided by the participating party, and any technical protocol is supported.

[0106] The participating party interface accessed by the sub-transaction node in the orchestrator is accessed by a software development kit provided by the participating party or is wrapped into a software development kit according to the interface technical protocol provided by the participating party, so that the participating party does not need to be aware of the orchestrator and only needs to provide an access interface.

[0107] Step S3, receiving an execution request of the client for the long-living transaction orchestration logic based on the management end, for displaying the execution request and being able to retry, wherein the type of the execution request comprises an execution success request and an execution failure request, and the content of the execution request comprises the long-living transaction processing parameters, the long-living transaction execution context, and execution exception information.

[0108] Specifically, the management end mainly implements the retry of the long-living transaction orchestration logic. The long-living transaction processing method of the present application is further described by specific embodiments.

[0109] Embodiment one

[0110] In this embodiment, the long-lived transaction includes 3 sub-transaction nodes: sub-transaction node 1, sub-transaction node 2, and sub-transaction node 3. These sub-transaction nodes only include normal transaction nodes and normal transaction execution nodes. The long-lived transaction recovery strategy is the mission-critical strategy. As shown in Figure 5 includes the following steps:

[0111] Step S101, a current sub-transaction node to be executed is obtained, wherein only normal transaction nodes and normal transaction execution nodes in the sub-transaction node are executed; in the sub-transaction

[0112] Step S102, before the sub-transaction node is executed, the long-lived transaction processing parameter and the long-lived transaction execution context are sent to the management end according to the processing identifier, and are persisted in the storage medium;

[0113] Step S103, the software development kit provided by the participant interface in the normal transaction execution node is accessed according to the long-lived transaction processing parameter, and a return result is obtained, if the return result is yes, step 104 is executed, otherwise, step S101 is executed;

[0114] Step S104, the software development kit provided by the participant interface in the normal transaction node is accessed according to the long-lived transaction processing parameter, if the normal transaction node has an exception, step S105 is executed, if there is no exception, step S106 is executed;

[0115] Step S105, the normal transaction node continues to be executed, after the exception is repaired, the management end re-executes step S101 according to the processing identifier from the storage medium;

[0116] Step S106, it is judged whether the long-lived transaction arrangement scheme has a next sub-transaction node, a return result is obtained, if the return result is yes, step S101 is executed, otherwise, the long-lived transaction arrangement scheme is ended;

[0117] Step S107, when all the sub-transaction nodes are executed, the long-lived transaction processing parameter and the long-lived transaction execution context are persisted in the storage medium according to the processing identifier.

[0118] Embodiment two

[0119] In this embodiment, the long-lived transaction includes 3 sub-transaction nodes: sub-transaction node 1, sub-transaction node 2, and sub-transaction node 3. These sub-transaction nodes include normal transaction execution nodes, normal transaction nodes, transaction backtracking execution nodes, and transaction backtracking nodes. The long-lived transaction recovery strategy is the time travel strategy.Figure 6 as shown, specifically comprising the following steps:

[0120] Step S201, obtaining a current sub-transaction node to be executed, wherein only normal transaction nodes and normal transaction execution nodes in the sub-transaction node are executed;

[0121] Step S202, before the execution of the sub-transaction node, the long-lived transaction processing parameters and the long-lived transaction execution context are sent to the management end according to the processing identifier, and are persisted in the storage medium;

[0122] Step S203, according to the long-lived transaction processing parameters, the software development kit provided by the participant interface in the normal transaction execution node is accessed, and a return result is obtained, if the return result is yes, step S204 is executed, otherwise, step S201 is executed;

[0123] Step S204, according to the long-lived transaction processing parameters, the software development kit provided by the participant interface in the normal transaction node is accessed, if the normal transaction node occurs an exception, step S208 is executed, if no exception occurs, step S205 is executed;

[0124] Step S205, judging whether the long-lived transaction arrangement scheme has a next sub-transaction node, obtaining a return result, if the return result is yes, step S201 is executed, otherwise, the long-lived transaction arrangement scheme is ended;

[0125] Step S206, obtaining a current sub-transaction node to be executed, wherein only transaction rollback nodes and transaction rollback execution nodes in the sub-transaction node are executed;

[0126] Step S207, according to the long-lived transaction processing parameters, the software development kit provided by the participant interface in the transaction rollback execution node is accessed, and a return result is obtained, if the return result is yes, step S208 is executed, otherwise, step S210 is executed;

[0127] Step S208, according to the long-lived transaction processing parameters, the software development kit provided by the participant interface in the transaction rollback node is accessed, if the transaction rollback node occurs an exception, step S209 is executed, if no exception occurs, step S210 is executed;

[0128] Step S209, stopping the transaction rollback node from continuing to execute, after the exception is repaired, the management end re-executes step S208 according to the processing identifier to obtain the long-lived transaction processing parameters and the long-lived transaction execution context from the storage medium;

[0129] Step S210, judging whether the long-lived transaction arrangement scheme has a previous sub-transaction node, obtaining a return result, if the return result is yes, executing step S206, otherwise, ending the long-lived transaction arrangement scheme;

[0130] Step S211, when all the sub-transaction nodes are executed, the long-lived transaction processing parameters and the long-lived transaction execution context are sent to the management end according to the processing identifier, and are persisted to the storage medium.

[0131] Embodiment three

[0132] In order to better understand the long-lived transaction processing method shown in the above embodiment, an application example is explained and described as follows. Figure 7

[0133] The recovery strategy of the long-lived transaction processing scheme is a time backtracking strategy, and there are totally 5 sub-transaction nodes. The normal transaction node of the first sub-transaction node is checking a user, and no transaction backtracking node is needed; the normal transaction node of the second sub-transaction node is initializing an order, and no transaction backtracking node is needed; the normal transaction node of the third sub-transaction node is preoccupying inventory, and the transaction backtracking node is restoring inventory; the normal transaction node of the fourth sub-transaction node is preoccupying points, and the transaction backtracking node is restoring points; and the normal transaction node of the fifth sub-transaction node is creating an order, and the transaction backtracking node is order cancellation.

[0134] The long-lived transaction arrangement scheme ends in two cases, which are: 1) when all the normal transaction nodes are executed successfully; and 2) when any normal transaction node occurs an exception, and is executed backtracking step by step to the top after completion.

[0135] The protection scope of the long-lived transaction processing method of the embodiment of the application is not limited to the step execution order listed in the embodiment, and any scheme realized by adding, reducing or replacing steps of the prior art according to the principle of the application is included in the protection scope of the application.

[0136] The embodiment of the application further provides a long-lived transaction processing system, which can realize the long-lived transaction processing method of the application. However, the implementation device of the long-lived transaction processing method of the application includes but is not limited to the structure of the long-lived transaction processing system listed in the embodiment, and any structure deformation and replacement of the prior art according to the principle of the application is included in the protection scope of the application.

[0137] As shown in Figure 8 In an embodiment, the long-lived transaction processing system of the application includes an arranger 81, a participant 82 and a management end 83.

[0138] ​The orchestrator 81 is configured to receive a long-lived transaction processing parameter provided by a client, acquire a long-lived transaction execution strategy provided by the client, pre-set long-lived transaction orchestration logic corresponding to the long-lived transaction recovery strategy, and execute the corresponding long-lived transaction orchestration logic based on the long-lived transaction processing parameter and the long-lived transaction recovery strategy.

[0139] The participant 82 is configured to provide an interface required by the long-lived transaction orchestration logic.

[0140] The management end 83 is configured to receive an execution request of the long-lived transaction orchestration logic from the client, display the execution request and enable retry, wherein the type of the execution request includes an execution success request and an execution failure request, and the content of the execution request includes the long-lived transaction processing parameter, a long-lived transaction execution context, and execution exception information.

[0141] The orchestrator 81, the participant 82 and the management end 83 correspond to the steps of the long-lived transaction processing method in one-to-one correspondence, and thus will not be described here.

[0142] In the several embodiments provided in the present application, it should be understood that the disclosed system, device or method can be implemented in other ways. For example, the device embodiments described above are only schematic. The division of the modules / units is only a logical function division. There can be another division manner in actual implementation. For example, a plurality of modules or units can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the modules / units shown or discussed can be indirect coupling or communication connection through some interfaces, devices or modules / units, and can be electrical, mechanical or other forms.

[0143] The modules / units described as separate components can or can not be physically separate, and the components shown as modules / units can or can not be physical modules, i.e., can be located in one place or distributed on a plurality of network units. Some or all of the modules / units can be selected according to actual needs to achieve the purpose of the embodiments of the present application. For example, the functional modules / units in the embodiments of the present application can be integrated into a processing module, or each module / unit can be physically independent, or two or more modules / units can be integrated into one module / unit.

[0144] Those of ordinary skill in the art should further appreciate that the units and algorithm steps of each example described in connection with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both, and that the described examples are merely illustrative of the principles of the application. In order to clearly illustrate the interchangeability of hardware and software, various components and steps have been described above generally in terms of their functionality, without reference to the detailed programming techniques in which such functionality can be implemented. Such programming techniques are well known to those of ordinary skill in the art and are intended to be encompassed by the embodiments disclosed herein. The software implemented aspects of the application are not described with reference to any particular programming language. Such software can, and can be implemented by, software written in any programming language: Java, C++, Visual Basic, Python, etc. Any of the programming languages mentioned in this paragraph have open-source implementations that can be used to implement the embodiments disclosed herein.

[0145] The embodiments of the present application further provide a computer readable storage medium. Those of ordinary skill in the art can understand that all or part of the steps of the methods described above can be completed by a program instructing a processor, and the program can be stored in a computer readable storage medium, which is a non-transitory medium, such as a random access memory, a read only memory, a flash memory, a hard disk, a solid state disk, a magnetic tape, a floppy disk, an optical disc, and any combination thereof. The storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, a data center, etc. integrated with one or more available medium sets. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a digital video disc (DVD)), or a semiconductor medium (for example, a solid state disk (SSD)), etc.

[0146] The embodiments of the present application further provide a long-lived transaction processing terminal. The long-lived transaction processing terminal comprises a processor and a memory.

[0147] The memory is configured to store a computer program.

[0148] The memory comprises a ROM, a RAM, a disk, a U disk, a memory card, or various media capable of storing program codes such as an optical disc.

[0149] The processor is connected to the memory and is configured to execute the computer program stored in the memory, so that the long-lived transaction processing terminal performs the long-lived transaction processing method described above.

[0150] Preferably, the processor can be a general processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; also can be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0151] As shown in Figure 9 The long-lived transaction processing terminal of the present application is in the form of a general purpose computing device. The components of the long-lived transaction processing terminal can include, but are not limited to, one or more processors or processing units 91, a memory 92, a bus 93 that connects the various system components including the memory 92 and the processing unit(s) 91.

[0152] The bus 93 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration bus (e.g., AGP bus) and a local bus using any of a variety of bus architectures (e.g., Industrial Standard Architecture (ISA), Micro Channel Architecture (MCA), Enhanced ISA (EISA), Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus).

[0153] The long-lived transaction processing terminal typically includes a variety of computer system readable media. Such media can be any available media that is accessible by the long-lived transaction processing terminal and includes both volatile and non-volatile media, removable and non-removable media.

[0154] The memory 92 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 921 and / or cache memory 922. The long-lived transaction processing terminal can further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 923 can be used for reading from and writing to non-removable, non-volatile magnetic media (e.g., a "hard drive"). Figure 9 (not shown), commonly referred to as a "hard disk drive", for reading from and writing to non-removable, non-volatile magnetic media (e.g., a platter). Although not specifically shown, such computer system can further include other removable / non-removable, volatile / non-volatile computer system storage media including, but not limited to, magnetic cassette, memory cards or sticks, DVD, etc. As will be appreciated by those skilled in the art, storage media 923 can be provided in any combination of the above. Figure 9A disk drive, a floppy disk drive, and / or other mass storage device can be provided for in the example of FIG. 9, which can be used to read from or write to a removable, nonvolatile magnetic or optical media (e.g., a floppy disk). The disk drive can be connected to the system bus 93 by a data media interface. The memory 92 can include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the application.

[0155] Program / utility 924 having a set (at least one) of program modules 9241 can be stored in memory 92, for example, with the program modules 9241 including an operating system, one or more application programs, other program modules, and program data, and each or some combination thereof, which can include implementation of a network environment. The program modules 9241 generally carry out the functions and / or methodologies of embodiments of the application as described herein.

[0156] The long-lived transaction processing terminal can also communicate with one or more external devices such as a keyboard, a pointing device, a display, etc. through I / O interface 94 and can communicate with one or more devices that enable a user to interact with the long-lived transaction processing terminal and / or one or more devices that enable the long-lived transaction processing terminal to communicate with one or more other computing devices. Such communication can occur via an I / O interface 94. Still yet, the long-lived transaction processing terminal can communicate with one or more networks such as a local area network (LAN), a wide area network (WAN), and / or the Internet through a network adapter 95. As Figure 9 illustrated, network adapter 95 communicates with the other modules of the long-lived transaction processing terminal via bus 93. As will be appreciated, although not explicitly illustrated, one or more other hardware and / or software modules are typically provided and can be used in conjunction with the long-lived transaction processing terminal. For example, a microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc. are generally provided as part of the long-lived transaction processing terminal.

[0157] The foregoing is considered as illustrative only of the principles of the application. Numerous modifications and adaptations thereof will be apparent to those skilled in the art without departing from the spirit and scope of the present application. Therefore, the scope of the application is not to be limited to the specific illustrative embodiments disclosed in this specification but is instead defined by the following claims, including all equivalents thereof.

Claims

1. A long-lived transaction processing method, characterized in that: The method comprises: Based on the orchestrator, the orchestrator receives long-lived transaction processing parameters provided by the client; obtains the long-lived transaction recovery strategy provided by the client; pre-sets the long-lived transaction orchestration logic corresponding to the long-lived transaction recovery strategy; and executes the corresponding long-lived transaction orchestration logic based on the long-lived transaction processing parameters and the long-lived transaction recovery strategy. Provide the interface required by the long-lived transaction orchestration logic based on the participating end; Receiving, based on the management end, an execution request from the client for the long-lived transaction orchestration logic, and displaying the execution request and enabling a retry, wherein the execution request type includes: an execution success request and an execution failure request, and the execution request content includes: the long-lived transaction processing parameters, the long-lived transaction execution context, and execution exception information; The orchestrator is hosted and executed on any host machine, and the long-lived transaction includes multiple sub-transaction nodes; the sub-transaction nodes include a normal transaction execution node, a normal transaction node, a transaction backtracking execution node, and a transaction backtracking node; The method further includes storing the long-lived transaction processing parameters and the long-lived transaction execution context in a storage medium before the sub-transaction node is executed or after all the sub-transaction nodes are executed; the long-lived transaction execution context includes the location of the sub-transaction node and the long-lived transaction recovery strategy; When the abnormal sub-transaction node is repaired, the management end obtains the corresponding long-lived transaction processing parameters and the long-lived transaction execution context from the storage medium, and causes the host machine where the orchestrator is located to receive a request to re-execute the sub-transaction node.

2. The long-lived transaction processing method according to claim 1, characterized in that: The long-lived transaction recovery strategy includes a mission-must-reach strategy; The long-lived transaction orchestration logic corresponding to the mission-must-achieve strategy includes: Determine the execution order of multiple sub-transaction nodes currently to be executed; For the current sub-transaction node, obtain the corresponding normal transaction node and the node indicating whether the normal transaction is executed; Whether the current normal transaction is to be executed is processed according to the long-lived transaction processing parameters; if the processing result of whether the current normal transaction is to be executed is yes, the current normal transaction node is processed according to the long-lived transaction processing parameters; otherwise, it is determined whether the current sub-transaction node has a next sub-transaction node; if so, the next normal transaction node is processed until all normal transaction nodes are processed; if not, the long-lived transaction orchestration logic is terminated.

3. The long-lived transaction processing method according to claim 1, characterized in that: The long-lived transaction recovery strategy includes a time-backward strategy; The long-lived transaction orchestration logic corresponding to the time-back strategy includes: Determine the execution order of multiple sub-transaction nodes currently to be executed; For the current sub-transaction node, obtain the corresponding normal transaction node and the node indicating whether the normal transaction is executed; Processing whether the current normal transaction is executed at the node according to the long-lived transaction processing parameters; if the processing result of whether the current normal transaction is executed at the node is no, determining whether the current sub-transaction node has a next sub-transaction node; otherwise, processing the current normal transaction node according to the long-lived transaction processing parameters; When the normal transaction node is processed normally, it is determined whether the current sub-transaction node has a next sub-transaction node; if so, the processing of the next normal transaction node is performed; if not, the long-lived transaction orchestration logic is terminated; When the normal transaction node processes an exception, obtaining the transaction backtracking execution node and the transaction backtracking node corresponding to the current sub-transaction node; The transaction backtracking execution node is processed according to the long-lived transaction processing parameters. If the processing result of the transaction backtracking execution node is yes, the transaction backtracking node is processed according to the long-lived transaction processing parameters. If the processing result of the transaction backtracking execution node is no, it is determined whether the current sub-transaction node has a previous sub-transaction node. If so, the transaction backtracking execution node and transaction backtracking node corresponding to the previous sub-transaction node are executed until the corresponding transaction backtracking execution nodes and transaction backtracking nodes of all sub-transaction nodes are processed. If not, the long-lived transaction orchestration logic is terminated.

4. The long-lived transaction processing method according to claim 1, characterized in that: The sub-transaction node is an interface provided by any application, which is provided by the participating parties and supports any technical protocol.

5. The long-lived transaction processing method according to claim 4, characterized in that: The participant interface accessed by the sub-transaction node in the orchestrator is accessed by the participant through a corresponding software development kit provided by the participant or packaged as a software development kit according to the interface technology protocol provided by the participant, so that the participant does not need to be aware of the orchestrator and only needs to provide an access interface.

6. A long-lived transaction processing system, characterized in that: The system includes an orchestrator, a participant terminal, and a management terminal; The orchestrator is used to receive long-lived transaction processing parameters provided by the client; and obtain the long-lived transaction recovery strategy provided by the client; Presetting the long-lived transaction orchestration logic corresponding to the long-lived transaction recovery strategy; Executing corresponding long-lived transaction orchestration logic based on the long-lived transaction processing parameters and the long-lived transaction recovery strategy; The participating end is used to provide the interface required by the long-lived transaction orchestration logic; The management end is used to receive an execution request from the client for the long-lived transaction orchestration logic, and is used to display the execution request and enable retry, wherein the types of the execution request include: execution success request and execution failure request, and the content of the execution request includes: the long-lived transaction processing parameters, the long-lived transaction execution context, and execution exception information; The orchestrator is hosted and executed on any host machine, and the long-lived transaction includes multiple sub-transaction nodes; the sub-transaction nodes include a normal transaction execution node, a normal transaction node, a transaction backtracking execution node, and a transaction backtracking node; The method further includes storing the long-lived transaction processing parameters and the long-lived transaction execution context in a storage medium before the sub-transaction node is executed or after all the sub-transaction nodes are executed; the long-lived transaction execution context includes the location of the sub-transaction node and the long-lived transaction recovery strategy; When the abnormal sub-transaction node is repaired, the management end obtains the corresponding long-lived transaction processing parameters and the long-lived transaction execution context from the storage medium, and causes the host machine where the orchestrator is located to receive a request to re-execute the sub-transaction node.

7. A long-lived transaction processing terminal, characterized in that: The long-lived transaction processing terminal includes: a processor and a memory; The memory is used to store computer programs; The processor is configured to execute the computer program stored in the memory, so as to enable the long-lived transaction processing terminal to execute the long-lived transaction processing method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a long-lived transaction processing terminal, the long-lived transaction processing method according to any one of claims 1 to 5 is implemented.

Images