CN112148436B

CN112148436B - Decentralised TCC transaction management method, device, equipment and system

Info

Publication number: CN112148436B
Application number: CN202011010261.3A
Authority: CN
Inventors: 林斌; 施建安; 庄一波; 赵友平; 孙志伟
Original assignee: Xiamen Yilianzhong Yihui Technology Co ltd
Current assignee: Xiamen Yilianzhong Yihui Technology Co ltd
Priority date: 2020-09-23
Filing date: 2020-09-23
Publication date: 2023-06-20
Anticipated expiration: 2040-09-23
Also published as: CN112148436A

Abstract

The invention provides a decentralised TCC transaction management method, a device, a node and a system, wherein the method comprises the following steps: receiving a service execution request initiated by a user, and starting a TCC (transparent control) transaction according to the service execution request; generating a first try method according to the service execution request; wherein the first try-out method comprises a second try-out method of at least one called participating node; acquiring the execution condition of each called participating node on the second try method; generating a current marking state of the TCC transaction according to the execution condition; and coordinating the TCC transaction to enter a completion stage, and executing a confirmation operation or a rollback operation according to the marked state. The invention avoids single-point security and performance problems caused by the centralized node.

Description

Decentralised TCC transaction management method, device, equipment and system

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method, apparatus, device, and system for decentralized TCC transaction management

Background

Under the micro-service architecture, each micro-service manages a respective data source. And a complete multiservice often requires multiple data sources to participate in interactions. To ensure integrity and consistency of the traffic data in this case, a means of distributed transaction is required to do so. The distributed transaction means which are more used in the application are a long transaction scheme based on a Saga model, a final consistent transaction scheme based on a TCC model and a strong consistent transaction scheme based on an XA protocol.

The final consistency scheme based on the TCC model mainly requires that one business action be split into two steps in the implementation: 1) Attempting to conduct business; 2) When the first step is successful, the second step executes a confirmation action to persist the achievement of the first step; when the first step fails, the second step performs a cancel action, rolling back the contents of the first step.

The service in the Internet field emphasizes the performance, and the scheme of the TCC can not lock resources in the whole execution process and has better performance. There are two modes of implementing the TCC scheme: manual and automatic. The manual scheme is that the whole TCC flow is manually realized through service codes, including try, rollback, confirmation, and the like. Comparatively, the implementation workload is large. The automatic scheme is to complete the control of the whole TCC flow through the framework.

The modules that the TCC framework must implement include a TCC transaction manager. During the business process, the participating nodes in the same TCC transaction need to register themselves in the TCC transaction manager, so that after the trial phase is finished, the TCC transaction manager can decide to execute the confirmation action or the rollback action according to the success or failure of the trial phase.

Several TCC frames exist today, mainly: tcc-transaction, hmily, easyTransaction. All three frames are centralized, that is, the transaction manager is a central node mode manager. Once a transaction manager node fails, all traffic fails because new TCC transactions cannot be registered and existing TCCs cannot continue to execute because the transaction manager as a whole coordinator is lost.

Disclosure of Invention

In view of the above, the present invention aims to provide a method, apparatus, device and system for decentralized TCC transaction management, which adopts a decentralized transaction manager node implementation mechanism, so as to avoid the problem of single point failure of the transaction manager node in the prior art.

The embodiment of the invention provides a decentralizing TCC transaction management method, which comprises the following steps:

receiving a service execution request initiated by a user, and starting a TCC (transparent control) transaction according to the service execution request;

generating a first try method according to the service execution request; wherein the first try-out method comprises a second try-out method of at least one called participating node;

acquiring the execution condition of each called participating node on the second try method;

generating a current marking state of the TCC transaction according to the execution condition;

and coordinating the TCC transaction to enter a completion stage, and executing a confirmation operation or a rollback operation according to the marked state.

Preferably, the TCC transaction has the following attributes:

xid of TCC transaction itself;

the current marking state of the TCC transaction; wherein the marking state of the TCC transaction comprises an initial state, a commit/rollback state and an end state; when the execution conditions of all the try methods are successful, marking the marked state as the submitted state; when the execution condition of at least one try method is that the identification is executed, marking the marking state as a rollback state;

A list of attempted methods under TCC transaction scope;

current attempted methods under TCC transaction scope; wherein each attempted method to be executed requires an attempted method list that is first added to the TCC transaction object and written to the log before execution;

a remote participant list under TCC transaction scope; wherein the remote participant can only issue a remote call instruction to the remote participant after adding to the remote participant list.

Preferably, the xid comprises:

a globally unique ID for uniquely identifying the TCC transaction;

a branch ID to identify a local transaction that participates in the TCC transaction; wherein for a local transaction in which any node participates in the TCC transaction, it is one branch of a global TCC transaction; when the branch ID of the xid is empty, then the xid is indicated as being used to tag the TCC transaction itself.

Preferably, the method further comprises:

when a remote participating node is called, a TCC executing instruction is sent to the remote participating node; the TCC executing instruction comprises xid, an identifier of a node and a global unique traceId which is called at this time and used for preventing concurrent competition; after receiving the TCC executing instruction, the remote participating node judges whether a TCC transaction object corresponding to xid in the TCC executing instruction exists in a local TCC transaction warehouse, and if so, the remote participating node directly extracts and executes a corresponding second try method; if the TCC transaction object does not exist, a participant TCC transaction object is newly built through a transaction manager of the participant TCC transaction object, and a second try method is executed, so that the execution condition of the second try method is returned;

Transmitting a commit instruction to the remote participating node in accordance with execution of the second try method; after receiving the execution instruction, the remote participating node updates the TCC transaction state in a CAS mode, and a thread which is successfully updated continuously executes the flow of the subsequent completion stage and returns a success response; and after the log is written, the thread with failed updating waits until a successful response is returned.

Preferably, the method further comprises a log, wherein the log comprises a database log, and the database log is used for confirming whether the try phase method or the completion phase method is executed or not when the downtime is restarted; wherein:

the internal inclusion of the database log store is that the stored content is xid in the try method object, or completion phase xid in the validation method or rollback method.

Preferably, the log further comprises a log file, which is used for reconstructing the TCC transaction when the crash is restarted;

and writing the related key operations into a log file according to the occurrence sequence of time in the process of performing the TCC transaction, and executing the key operations after each key operation is written into the log file, so that after the shutdown restarting, the transaction recovery is performed according to the information recorded in the log file.

Preferably, when the transaction is recovered through the log file;

checking whether a first try method is successful when the TCC transaction is judged to be in an initial state;

if yes, updating the state of the TCC transaction into a commit/rollback state, and putting into an asynchronous thread pool to execute a corresponding completion phase flow;

if not, inquiring whether a record of xid of the first try method exists in the log file;

if so, updating the first try method to be successful, otherwise, updating the first try method to be failed;

updating the state of the TCC transaction according to the updated state of the first try method, and further executing a flow of a completion stage;

when the TCC transaction is judged to be in a commit/rollback state, firstly traversing a confirmation method/rollback method list, inquiring whether a finishing stage xid exists in a log file to update whether the corresponding confirmation method/rollback method is finished, and putting an object of the TCC transaction into an asynchronous thread pool after the completion of confirmation, and continuing to execute a commit or rollback flow.

Preferably, the flow of the completion phase is executed in a multithreading manner, which specifically includes:

transmitting corresponding instructions to all the remotely located participating nodes simultaneously in a multithreading mode and calling a completion phase method corresponding to a local first try method; the main thread is informed in a waiting or asynchronous notification mode through a countdown latch mode; in the multithreading process, the completion flags in the local and remote validation/rollback methods are modified with preset keywords.

Preferably, for an abnormal transaction placed in the transaction repository, the method further comprises:

taking out abnormal transactions in the abnormal transaction set; wherein the local participating node and the remote participating node currently in execution are marked with an identification number; the identification number is contended by the multithreading;

before preparing to execute the finishing stage, firstly judging whether the current identification number is the first number;

if not, aborting the abnormal transaction;

if the number is the first number, counting the currently required operand, updating by using a CAS mode, and obtaining the execution right when the updating is successful; wherein the operand is the sum of the number of local participating nodes and the number of remote participating nodes which are not successful;

a monitor is put in the execution methods of the local participating node and the remote participating node, and when the execution is finished, one subtracting operation is carried out on the operands;

for the thread with the operand of 0 detected, acquiring the completion conditions of a local participation node and a remote participation node in the current TCC transaction;

if the completion conditions of the local participating node and the remote participating node are all completed, updating the state of the TCC transaction, writing a log file and clearing a log;

If the local participating node and the remote participating node have outstanding, then the TCC transaction is put into the abnormal transaction set of the transaction repository again for the next attempt.

The embodiment of the invention also provides a device for decentralizing TCC transaction management, which comprises:

the TCC transaction starting unit is used for receiving a service execution request initiated by a user and starting a TCC transaction according to the service execution request;

an attempt method generating unit for generating a first attempt method according to the service execution request; wherein the first try-out method comprises at least one participating node which is called remotely and a second try-out method of the called participating node;

the execution condition acquisition unit is used for acquiring the execution condition of each called participating node on the second try method;

a marking unit, configured to generate a current marking state of the TCC transaction according to the execution condition;

and the coordination unit is used for coordinating the TCC transaction to enter a completion stage and executing a confirmation operation or a rollback operation according to the marking state.

The embodiment of the invention also provides a decentralised TCC transaction management node, which comprises a memory and a processor, wherein a computer program is stored in the memory, and the computer program can be executed by the processor to realize the decentralised TCC transaction management method.

The embodiment of the invention also provides a decentralised TCC transaction management system, which is characterized by comprising the decentralised TCC transaction management node and a plurality of participant nodes serving as participants.

In one embodiment, the state of the whole TCC transaction is changed, the process coordination does not have the participation of a central node, and any node which initiates the TCC transaction first can become a management node, and the management node is the actual transaction manager node. This design allows for more fault tolerance and resiliency in the management of the entire TCC transaction, as any node can become a management node, i.e., a manager node, thus avoiding single point security and performance problems with centralized nodes. Since the transaction manager responsibilities are shared by the entire business cluster, there is naturally no concern about performance and security.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the embodiments will be briefly described below, it being understood that the following drawings only illustrate some examples of the present invention and therefore should not be considered as limiting the scope, and other related drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of a method for decentralized TCC transaction management according to a first embodiment of the present invention.

Fig. 2 is a schematic diagram of call between nodes according to the first embodiment of the present invention.

FIG. 3 is a state change diagram for a TCC transaction.

Fig. 4 is a flow chart diagram of the success of the try method.

Fig. 5 is a flow chart diagram when the try method fails.

Fig. 6 is a process diagram of joining a remote participating node to a TCC transaction.

FIG. 7 is a flow chart of a remote participating node executing TCC execute instructions.

FIG. 8 is a flow chart of a remote participating node executing a TCC commit instruction.

Fig. 9 is a flow chart of a remote participating node executing a rollback instruction.

FIG. 10 is a schematic diagram of a de-centralized TCC transaction management device according to a second embodiment of the present invention.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments, based on the embodiments of the invention, which are apparent to those of ordinary skill in the art without inventive faculty, are intended to be within the scope of the invention. Thus, the following detailed description of the embodiments of the invention, as presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. All other embodiments, based on the embodiments of the invention, which are apparent to those of ordinary skill in the art without inventive faculty, are intended to be within the scope of the invention.

Referring to fig. 1, a first embodiment of the present invention provides a method for decentralized TCC transaction management, which may be performed by a decentralized TCC transaction management node (hereinafter referred to as management node) to implement at least the following steps:

s101, receiving a service execution request initiated by a user, and starting a TCC (transparent control) transaction according to the service execution request.

In this embodiment, the management node may be a computing device with data processing capability and communication capability, such as a notebook computer, a desktop computer, a mobile terminal, a PDA, a workstation, etc., in which corresponding service software is installed, and service processing is implemented by executing the service software.

S102, generating a first try method according to a service execution request; wherein the first try-out method comprises a second try-out method of at least one called participating node.

In this embodiment, when a user wants to execute a service, the user may send a service execution request through the management node, and when the management node receives the service execution request of the user, the management node starts a corresponding TCC transaction according to the service execution request.

It should be noted that, in this embodiment, the management node is not a specific node, and the user may initiate a TCC transaction through any service node, and the node that initiates the TCC transaction is called a management node.

For example, as shown in fig. 2, in the present embodiment, the service nodes include an a node, a B node, a C node, and a D node. When TCC transactions are not initiated, these service nodes are peer-to-peer nodes. At this time, if the user initiates a TCC transaction through the a node, and the first try method of the a node remotely invokes the second try method B (try) of the B node and the second try method D (try) of the D node, the identity of the a node is converted into a management node at this time, so as to coordinate the execution process of the whole TCC transaction, and the B node and the D node are converted into participating nodes. It should be noted that, similarly, for the node B or the node D, when executing its own second try method, it may also call the try method of the downstream node, for example, the second try method B (try) of the node B calls the second try method C (try) of the node C, then the node C is also a participating node, and the node higher level than the node C is the node B. It will be appreciated that the C node may also invoke further try methods of its downstream nodes when executing its second try method, provided that the nodes invoked during execution of the TCC transaction are referred to as participating nodes.

S103, the execution condition of each called participating node on the second try method is obtained.

S104, generating the current marking state of the TCC transaction according to the execution condition.

S105, coordinating the TCC transaction to enter a completion stage, and executing a confirmation operation or a rollback operation according to the marking state.

In this embodiment, each participating node executes its own second attempting method after being invoked, and sends the execution of the second attempting method to its upstream node.

Taking fig. 2 as an example, if the upstream node of the node B and the node D is the node a, it sends the execution of the second try method to the node a, and the upstream node of the node C is the node B, so the node C sends the execution of the second try method C (try) to the node B, and then the node B confirms and sends the confirmation to the node a.

As shown in FIG. 3, in this embodiment, after the execution condition of each node is obtained, the A node generates the current marking state of the TCC transaction, for example, marking as a commit state or a rollback state, according to the execution condition. The a node then coordinates TCC transactions into the completion phase to perform either the validation method or the rollback method. After entering the completion phase, both the confirmation method and the rollback method must be executed successfully, and if the execution fails, the retry is performed until the execution is successful. Therefore, after the management node A finishes executing the own completion phase method and successfully sends out an instruction for executing the completion phase method to the downstream node, the TCC distributed transaction can be considered to be completed. All participating nodes must be able to receive instructions to execute the completion phase and eventually execute successfully.

In one implementation:

if the four-node try method is successfully executed, the A node serving as the management node marks the current marking state of the TCC transaction as a commit state, and a completion phase is carried out. Since the try methods of all nodes are successfully executed in the try phase, the finish phase is to execute the confirm methods of all nodes. Firstly, the confirmation method Acommit of the A node as the management node is executed first, then the A node sends out the instruction for executing the confirmation method, and the instruction is transmitted to the directly downstream node B node by a remote mode. After receiving the instruction of executing the completion phase confirmation method, the node B executes the local Bcommit and continues to transmit the instruction of executing the confirmation method to the node C node directly downstream. After receiving the instruction, the C node also executes the local confirmation method Ccommit. Then, the a node issues an instruction to execute the confirmation method to the node D, and the node D executes the local confirmation method Dcommit.

In another implementation:

if a node has a problem in executing its try method, for example, in executing the second try method D (try) to the D node, the data state of the D node is still in an initial state since all try methods should be under the envelope of the local transaction. But the data states of both node B and node C are now in an intermediate state and need to be rolled back to the initial state. Because of the synchronous call, the failure of the second try method D (try) to execute is perceived by the upstream node, i.e. the A node, which coordinates the TCC transaction into the completion phase and is the rollback method to execute. Node a will issue a rollback instruction to node B. After receiving the rollback instruction of the node A, the node B locally executes the rollback method and continuously transmits the rollback instruction to the node C at the downstream node. The C node also executes the rollback method after receiving the rollback instruction of the B node. Thus, the data state is not affected by the failure of the method due to the attempt of the method by the A node and the D node under the surrounding of the local transaction. And the node B and the node C roll back the own data state from the intermediate state to the initial state by a rollback method, so that finally the whole TCC transaction is rolled back, and all node data of the whole service are consistent.

In summary, it can be seen that the state of the entire TCC transaction changes, and the process coordination does not have the participation of a central node, any node that initiates a TCC transaction first can become a management node or a coordination node, and the management node is the actual transaction manager node. This design allows for more fault tolerance and resiliency in the management of the entire TCC transaction, as any node can become a management node, i.e., a manager node, thus avoiding single point security and performance problems with centralized nodes. Since the transaction manager responsibilities are shared by the entire business cluster, there is naturally no concern about performance and security.

For the purposes of promoting an understanding of the invention, reference will now be made to a number of preferred embodiments or specific implementations of the invention.

Based on the above embodiments, in one specific implementation of the present invention, the TCC transaction has the following attributes:

(1) Xid of TCC transaction itself

In this embodiment, a TCC transaction uses a xid as the unique identifier, the xid being divided into two parts:

a globally unique ID (globalID) that uniquely identifies a TCC transaction, which must not be null.

Branch ID (brandid) to identify a local transaction that participates in a TCC transaction.

Wherein for local transactions on any node that participate in a TCC transaction, one branch of the TCC transaction is global in itself. When the value is empty, it means that the xid is used to mark the TCC transaction itself.

The transactions committed in this embodiment include two types: TCC transactions and local transactions. Local transactions refer to database transactions on a single node, that is, transactions that are commonly initiated and committed through the JDBC interface. TCC transactions are defined using one class in this embodiment, while local transactions are conceptual only and there is no class to define. Xid allocated to a local transaction will actually be used by the corresponding tcctinvoke.

In this embodiment, when a TCC transaction is created, its identity may be immediately ascertained. The identity of the TCC transaction created on the original management node is the coordinator. The identity of the TCC transaction created by the remote invocation command is the participant.

When a TCC transaction is created, the value of xid can be immediately ascertained. If it is a coordinator, its value of xid is newly created. If a participant, the value of xid comes from the coordinator, which is the same as the xid value of the coordinator.

In this embodiment, the try phase boundary of a TCC transaction is identical to the first local transaction initiated in a TCC transaction. When an attempted method is to be performed and there is no TCC transaction in the context at this time, a TCC transaction is initiated and the identity of the TCC transaction is the coordinator. For this attempted method, it must be performed in a local transaction. When this attempted method is completed, the attempt phase of the TCC transaction is completed. At the same time, the first transaction to participate in the TCC transaction is the local transaction commit or rollback corresponding to the try method. Thus, it can be said that the try phase boundary of a TCC transaction is the same as the first local transaction in the TCC transaction scope.

(2) The current marking state of the TCC transaction.

As shown in fig. 3, from the above description, there are three distinct distinguishing states for the service nodes participating in the TCC transaction: initial state, intermediate state, end state. Obviously, any node participating in the service will have these three states, with a final consistency scheme.

For the TCC transaction itself, there are also three states corresponding, respectively:

Initially: the TCC transaction is in this state after it is created. In this state, all traffic nodes (including the management node or the participating node) may perform the try method.

Marked as commit/rollback status: this is an intermediate state, and when this state is entered, it means that the attempted method of the participating service node is either all successfully performed or any one of the execution fails. TCC transactions are either marked as commit status or rollback status depending on the outcome of the execution of the participating service node try method. The management node may let itself enter this state, whereas the participating nodes can only accept commands from the superordinate nodes to enter this state. After entering this state, the management node may coordinate each node to execute a corresponding method according to the current state, for example, a confirmation method is executed if the node is marked as commit, and a rollback method is executed if the node is marked as rollback.

Ending: the TCC transaction enters this state when both the local call and the remote call completion phase methods (acknowledge or rollback) involved in the TCC transaction have been performed. TCC transaction resources in the end state may be purged, such as memory resources and log occupancy may be purged.

In this embodiment, in any state in the TCC transaction progress, the related critical operations are written into a log according to the occurrence sequence of time, and after each critical operation is written into the transaction log, the critical operation is executed, so that after downtime is restarted, transaction recovery is performed according to the information recorded in the log.

Wherein TCC transactions are a global concept, and for each participating service node, the service node itself is also a branch of TCC transactions and can be considered as a local content of global transactions. The TCC transaction branches on each node will also go from an initial state after creation, to a state marked commit/rollback after execution of the try method (if the remote participating node, entry into this state is an instruction received from the superordinate node), to an end state after execution of the acknowledge/rollback method is completed.

For a TCC transaction, it is necessary to ensure data consistency for each service node. The consistency of data is seen from several perspectives:

data consistency for all participants in a service.

Consistency of data in an abnormal state on a single node.

From the point of view of data consistency for all participants of the service, the consistency guarantee of the data according to this embodiment is mainly based on the guarantee of the basic principle of final consistency.

Under normal operating conditions, a service node participating in a TCC transaction must all undergo three state changes. While all nodes reach the final state, necessarily in a data-consistent state.

For the consistency of the data on a single node, the embodiment is mainly ensured by the way of log. In this embodiment, any operation involving a TCC transaction will first write a log, and after the log is written successfully, the corresponding operation can be executed. Any operation that changes the TCC transaction state (including the addition of the three states described above, including the addition of the new participant, the execution of the new try method, the validation method, the rollback method, etc.) may also need to be logged before execution. In addition, all TCC operations are performed within the scope of local transactions. Since a TCC transaction itself is composed of multiple local transactions. Also, to determine whether a local transaction commits, after the local transaction is started, an xid is assigned to the transaction. This xid represents the branch concept of the local transaction in a global TCC transaction. The log is also written after the xid is allocated, and the xid is written into the log before the local transaction is submitted, so that the consistency of business operation and log operation is ensured through the local transaction. Thus, after downtime, whether the data of the business operation is successfully submitted can be deduced according to the information in the log.

Because the key operation is executed after the log is recorded, after the node is down and restarted, the state of the TCC transaction can be recovered through reading the key action and replaying the key action, the TCC transaction on the node is recovered to the state before the down, the execution is continued, and finally the TCC transaction is brought into the ending state, so that the data consistency of all the nodes is achieved.

In the log of TCC, key information is recorded, mainly: the current state of the TTC transaction, the list of local transactions involved in the TCC transaction. A local try-out method to participate in the TCC transaction, a local completion phase method to participate in the TCC transaction and try to execute. The related operations involved in a TCC transaction are written sequentially, so that the downtime is the playback of the log.

Specifically, after the shutdown is restarted, all necessary information of the TCC transaction object can be recovered only by reading the logs in a corresponding sequence, unnecessary information can be obtained by deducing the necessary information, and all information of the TCC transaction is finally recovered to a state before the shutdown.

All local transactions on a node (usually, one local transaction is used on one node, and a plurality of local transactions are started occasionally, each local transaction is a branch transaction of a global TCC transaction) register themselves in a TCC transaction object before starting, so that after downtime is recovered, a local transaction list in the TCC transaction object can be completely recovered by reading a log file.

Downtime may occur during the try phase of a TCC transaction as well as during the completion phase. If the TCC transaction state read in the log is the initial state, then this means that downtime occurred during the try phase, because the TCC state has not migrated to be marked commit/rollback. By querying the log to specify whether the xid record exists, whether the corresponding local transaction is successfully submitted can be judged. Because of the occurrence of downtime, this means that the attempt phase of the TCC transaction has ended, at which point it is first necessary to determine which intermediate state the TCC transaction needs to migrate from the initial state to. By determining whether the first local transaction on the coordinator node committed (because the first local transaction on the coordinator node is the local transaction that actually opened the TCC global transaction, which local transaction committed, meaning whether the TCC transaction was fully successful during the try phase) it can be determined whether the current TCC transaction should enter marked commit or marked rollback. And then executing the completion phase method of all the participating nodes.

If the TCC transaction is already marked as commit/rollback state when it is resumed, then execution of the completion method for each node in that state needs to continue. It is first necessary to determine which local completion methods have been performed. For each attempted method, a completion phase xid is assigned in advance before execution. Because the try method is in the completion phase, the corresponding completion phase branch of the try method needs to be executed. When the downtime is recovered, whether the method is executed in the completion stage of the trial method can be judged by checking whether the completion stage xid exists in a log, and if so, the execution is marked as executed; if not, the retry may continue. Thus, a TCC transaction that is not completed is fully restored.

In this embodiment, when a TCC transaction enters a state marked commit/rollback, it means that the TCC transaction enters a completion phase. To ensure data consistency, the completion phase must be performed successfully, whichever branch is. Thus, repeated execution is required once the method execution of the completion phase is in error. The method of the completion stage uses local transaction enclosure, so repeated execution after execution failure does not cause problems of local data, and the method can be safely retried.

Theoretically, the completion phase method must be successful, but if the method is still unsuccessful after multiple retries, then human intervention is required.

The framework logs the participating nodes before executing the try method, and the participation of the try method needs to be logged together and stored in the memory. When the TCC transaction enters the completion phase, and the validation/rollback method needs to be executed, the framework can acquire, through metadata information, how the validation or rollback method corresponding to one try method is invoked. The confirmation and rollback method should use the same approach as the try method. The framework may invoke a validation or rollback method and the incoming parameters used by the incoming attempt method to execute the corresponding method.

(3) A list of attempted methods under the TCC transaction scope.

In this embodiment, the try method call is the execution of a specific try method. Before the try method is executed, the method information should first be registered into the try method list of TCC transactions. Specifically, an object of the try method is generated and registered into the TCC transaction. The registered action content includes:

setting an object of a current try method in the TCC transaction as a precursor of the try method object, and setting the object of the try method as a current try method direction;

adding the object of the try method to a try method list of TCC transactions;

the object information of the try method is written to the log.

At the same time, from the implementation point of view, the object of the try method should be put into the current try method direction of the Tcc connection object, so that relevant processing is convenient when the local transaction is submitted or rolled back.

In this embodiment, the first attempt in a TCC transaction has a more important meaning, as the success or failure of this attempt means whether the branch of the TCC transaction was successful or failed. From the log file, the object of the first attempt method is first written to the log. But does not rely on this, there is also a simple way to determine whether the subject of the first attempt is the method. That is, the object of the try method where no precursor exists is the object of the first try method in the TCC transaction branch.

(4) Current attempted methods under TCC transaction scope; wherein each attempted method to be executed requires an attempted method list that is first added to the TCC transaction object and written to the log before execution.

In this embodiment, considering the responsibilities assumed by the try method, the attributes that it should contain are:

the method corresponds to the operation object.

The trial method performs the participation.

Xid of the local transaction when the try method is performed.

The completion phase xid assigned to the try method is used to write the log file and commit to the log table when executing its corresponding completion phase method.

From the above example, it is known that during execution of one try method, another try method may be invoked. When the trial method is finished, the method returns to the calling place of the last trial method to continue execution. To abstract this relationship, the object of the try method will have a forward pointer to the try method that called its own method. The value of xid in the try method object is the xid of the local transaction when the try method is executed. A local transaction is a logical concept and there are no actual class definitions and objects. The value of xid is thus actually determined logically. Specific rules are as follows:

When the try method has no forward try method object, the value of xid is created entirely new.

When an try method is created, there is a forward try method, and if the transaction propagation attribute of the method in which the current try method is located is that of the original transaction, the xid of the try method multiplexes the objects of the forward try method. If the transaction propagation attribute of the method in which the current try method is located is a new transaction, xid of the try method is new.

When a local transaction commits, the attempted methods, meaning the same xid value, are all performed.

First, the current trial method is completed. Second, it is necessary to determine whether the xid value of the object of the forward try method is the same as itself. If the same, it means that the forward try method is also performed in the same local transaction, and must be performed. By recursing this process, objects of all attempted methods in the same local transaction can be found. When this local transaction commits, the same xid attempt method needs to be marked as complete.

Before the local transaction is submitted, in order to consider the downtime recovery, the xid of the local transaction (i.e. the xid of the Tcc (try) under the scope of the local transaction) needs to be written into the log table together, and the consistent writing of the log data and the business table data is ensured by means of a single transaction.

If a local transaction commits successfully, there is no object of the uncommitted attempt method, meaning that the branches of the TCC transaction on that node are all successful, if that node is a coordinator node, it may be considered that the TCC transaction has been successful in the attempt phase, may be marked as committed, and enter the completion phase. If the local transaction commit fails, then the attempted method of the same xid should be marked as execution failure. At this time, the initial attempt method on the coordination node is finally failed to be executed by continuously throwing out errors, so that the corresponding TCC transaction is marked as rollback, and the completion phase is entered. A corresponding rollback method is performed.

For attempted method commit, as shown in FIG. 4, when a local transaction commits and the local transaction is under the scope of a TCC transaction, then the object of the current attempted method for the TCC transaction needs to be fetched. It is set to commit state and its precursor is accessed, and if the precursor's xid is the same as the object of the current try method, it is also set to commit. This action is repeated until the predecessor xid is different from the object of the current try method, then the object of the try method is set to the object of the current try method of the TCC transaction.

For the try method failure, as shown in fig. 5, the processing logic and ideas of try method failure and try method commit are similar, with the difference in the direction of the two.

When a local transaction rolls back due to an exception, the current attempted method of fetching a TCC transaction is marked as failed if the local transaction is under the scope of the TCC transaction. And accessing its precursor, if xid of the precursor try method is the same as the try method, the precursor is also marked as failed. This process is repeated until no precursor is found or the xid of the precursor does not correspond to the current attempted method, then the precursor may be set to the current attempted method direction of the TCC transaction.

In this embodiment, when all of the try methods under the TCC transaction scope are performed, that is, the current try method of the TCC transaction is empty, it means that the try phase of the TCC transaction has finished. The TCC transaction should be marked as either commit or rollback at this point, depending on the circumstances of the try phase, to guide the trend of the finish phase.

The decision was then in fact simple, and the first attempt to register with a TCC transaction under the TCC transaction scope was special in that it initiated the entire TCC transaction. If the attempted method is successful, the TCC transaction is marked as committed; if the method is failed, the TCC transaction is marked as rollback.

The state change of a TCC transaction is a critical operation and therefore requires the updated TCC transaction state to be logged. Once this state is entered, the TCC transaction needs to perform the completion phase method until the TCC transaction state is complete. If the completion phase method is abnormal, repeated retries are required until successful.

In this embodiment, the transaction states differ according to TCC: the methods that need to be performed for the commit, rollback, completion phases are different. Specifically, when the state is commit, the confirmation method is performed, and when the state is rollback, the rollback method is performed.

Confirmation method/TccCommit

When a TCC transaction enters the completion phase and is marked as committed, a corresponding validation method needs to be performed for each attempted method registered with the TCC transaction.

The validation methods are triggered by the framework, each of which should first be surrounded by local transactions. Considering that Spring is adopted as a running container in most Java development scenes, the requirement can be met only by confirming that @ transitional annotation is annotated on the method.

Similar to the try method, when the confirmation method is executed, the local transaction needs to be submitted, and the completion phase xid of the local transaction needs to be written into the log together, so that the local transaction can be submitted. The source of the value of the completion phase xid is assigned to the corresponding try method. From the aspects of function and utility, the attributes that the validation method should possess are:

The method is the same as the corresponding trial method.

The completion phase xid, the value is assigned by the object of the corresponding try method.

Method object method, defined in tcoperation.

Rollback method/tccRollback

When a TCC transaction enters the completion phase and is marked as rollback, a corresponding rollback method needs to be performed for each attempted method registered into the TCC transaction.

Similar to the validation method, the rollback method is also triggered by the framework and should also be surrounded by local transactions.

The rollback method and validation method are basically similar except for the direction: all triggered by the framework, all required to be surrounded by local transactions, all required to write to completion phase xid at the time of local transaction commit. The attributes that the entity should possess are therefore also the same as those of the validation.

The only difference is that if a TCC transaction enters the completion phase and is marked as committed, all validation methods need to be performed. While TCC transactions enter the completion phase and are marked as rollback, whether the rollback method is executed depends on whether the corresponding attempted method is successfully executed. If the corresponding try method fails to be executed, the middle data needing to be rolled back does not exist, and the corresponding rollback method does not need to be executed naturally. In order to unify the logic of the validation method and the rollback method, in a scenario where the rollback method does not need to be performed, the rollback method may be considered to be performed directly successfully.

(5) A remote participant list under the TCC transaction scope; wherein the remote participant can only issue a remote call instruction to the remote participant after adding to the remote participant list.

Since it is a distributed transaction, there must be a remote participant (e.g., node B, C, D). A remote participant is an abstract description or proxy for a remote resource. Itself should be provided with a commit and rollback interface for sending corresponding instructions to the remote participants through the proxy during the completion phase.

Considering that the same remote participant may be called multiple times within the calling range of an try method, in order to save resources, the remote participant should implement an isSame interface to determine whether the remote participant added to the same TCC transaction later is the same as before, if so, no need to be added again, and use of repeated objects is reduced.

Specifically, as shown in FIG. 6, in performing an attempted method, the providing node of the remote service is considered a remote participant to the TCC transaction if a remote invocation is required. Thus, before invoking the remote participant, the remote participant needs to be registered in the remote participant list of the TCC transaction. Registering a remote participant requires a first determination to confirm whether the current remote participant already exists.

The implementation of the remote participant commit and rollback method is to send commit or rollback instructions to the remote node by remote invocation (RPC or Http Api). The xid value of the TCC transaction is carried as a parameter.

In this case, as shown in fig. 7, when the RPC method is actually executed, the relevant information of the TCC execution instruction needs to be carried. And also requires sending TCC transaction commit/rollback instructions to the remote participants when executing the completion phase of the TCC transaction. The information that each remote TCC execution instruction needs to contain in common is:

xid for tcc transaction.

2. An identifier of the propagating node.

When receiving a TCC execution instruction, a remote participant first needs to acquire a TCC transaction object corresponding to xid in the execution instruction from a TCC transaction warehouse before invoking an attempt method of a service. If not, then a participant TCC transaction object needs to be created by the transaction manager. After the TCC transaction is established, the call to the try method is made to be consistent with the management node (or coordinator) and is not differentiated.

Many RPC frameworks have an automatic retry function when they fail, which results in a situation where the service provider is competing concurrently when processing TCC execution instructions. To handle concurrency contention, TCC execution instructions additionally carry a parameter: the traceId of this call. The traceId is globally unique and is uniquely assigned for each remote call, and the service provider can exercise anti-replay control based on this parameter.

This remote call under the TCC transaction scope cannot be performed in an asynchronous form because the upper node needs to know the outcome of the remote call (whether it is abnormal) to decide whether to perform the subsequent steps and the completion phase confirms the selection of the branch and cancel the branch.

To this end, the method of performing the completion phase begins when the TCC transaction attempt phase of the management node is completed. If the management node's try phase method is executed successfully, the management node's TCC transaction will be marked as commit, at which point commit instructions will be sent to all remote participants.

When the remote participant receives the commit instruction, the TCC transaction state needs to be updated to be marked as committed. Considering the nature of the possible retries of the RPC framework, changes to TCC transaction state need to be made using CAS. That is, only the TCC transaction state is updated by way of CAS, the successfully updated thread can continue with subsequent flows and return caller success responses. The thread that failed the CAS continues to try and cannot immediately return a success message if it is found that the transaction state has been updated.

This is because, after the state of the TCC transaction object is updated in memory, it also needs to be logged to perform subsequent business actions. Suppose there are two threads A, B at this time. The A-thread CAS operation is successful, the B-thread CAS operation fails, and at the moment, the B-thread retries, the transaction state is found to be changed, and a caller success response is returned. And the A thread is not available and is down after writing the log. Resulting in the method actually failing. This causes errors in the determination of whether the method is being performed by the superordinate node and the local node. Thus, there should be an attribute (e.g., named Intermediate Logged) in the TCC transaction that indicates whether the log was completed after the update to the intermediate state. The retried thread can only return to the caller response after the log is written. In summary, the flow of executing commit instructions on a node of a remote participant is shown in FIG. 8.

The execution method and flow logic of the rollback instruction is very similar to that of the commit instruction. But rollback instructions may need to handle situations that some commit instructions do not encounter. And thus may be somewhat complex in overall flow.

The first possibility is that the remote participant may receive repeated rollback instructions. This is because the upper node has not sent a successful response from the remote participant node to the upper node after the rollback instruction has been issued, for reasons such as network failure. The upper node issues a rollback instruction again at the time of retry. At this point the TCC transaction is also executing in the rollback branch.

For this case, the problem is solved using the flow in the TCC execute instruction, so that the second arriving rollback instruction does not participate in the CAS race. The method can directly return to the successful response of the upper node after checking the state of the TCC transaction and the value of the IntermediateLogged flag bit.

The second possibility is that the remote participant node still receives the rollback instruction while performing the try-phase method. This is the case because the participant nodes are disconnected from the network during the execution of the attempt phase, resulting in failure of the upper node to receive a successful response, at which point the management node would consider it necessary to rollback the entire TCC transaction. A rollback instruction may be issued to the remote participant node at which time the remote participant node may remain during the method of the execution attempt phase.

For this case, it is to avoid the method of starting execution of the completion phase while the try phase is still in progress. The simple basis is whether the first attempt in the TCC transaction is successful or failed (i.e., not in the initial state). The rollback branch can only be prepared after the explicit attempt phase has been completed, otherwise it is necessary to wait until the attempt phase ends.

For additional consideration of both cases, the final flow of the TCC rollback instruction is shown in FIG. 9.

Design of logs

In this embodiment, the log is mainly embodied in two places: database logs and log files. The responsibilities assumed by two different journals are different. The database log plays a role in confirming whether the try phase method or the completion phase method is executed or not when the downtime is restarted. The log file then plays the role of TCC transaction reconstruction when the crash is restarted.

The database log is used for checking the data of the log when the downtime is restarted, and confirming whether the trial phase method or the completion phase method is executed or not. Thus, the service method itself is not required to realize idempotency. Thus, it stores what is the completion phase xid in the try method object, or in the validation method or rollback method. The design is shown in table 1:

TABLE 1

The log file is used to take responsibility for downtime restart recovery, so critical operations in the TCC transaction object lifecycle need to be recorded. The log information in the log file has a general format as shown in Table 2

TABLE 2

The value of the schema is registered in advance. The values allowed are as follows:

schema：1

the body format is as follows:

TABLE 3 Table 3

Registering a local TCC call:

TABLE 4 Table 4

The value of sequence number 4 here is a chose way. For an attempted method under the same local transaction, the values of sequence numbers 1 and 2 are the same and therefore cannot be used to identify the attempted method. The value of sequence number 3 is different for each try method and therefore can be used to identify the object of a particular try method in addition to the value of the branch ID used to make the completion phase xid of the completion phase. Sequence number 4 thus uses this value as the precursor's pointer.

Registering remote resources:

TABLE 5

/>

Transaction state update:

TABLE 6

Log archiving

The present embodiment employs a general log solution. According to the scheme, the archiving of the log can be triggered in the running process. The loose log is compressed into tight data. Thereby realizing multiplexing of log file space. Log archiving, most important is providing the format of the archive log, as shown in table 7:

TABLE 7

In this embodiment, transaction recovery and exception handling during downtime may be implemented based on the log designed as described above.

Specifically, the main tasks in the completion phase are:

1. corresponding instructions are sent to all remote participants.

2. And calling a completion stage method corresponding to the local try method.

Both require traversing the list, operating on each element, so parallelization can be accelerated by multithreading. While the main thread may be notified in the form of a wait or asynchronous notification by way of a countdown latch.

Because of the multi-threading involved, the completion flag in the validation/rollback should be modified with a predetermined key (e.g., volatile); the same is true for the completion identification bit in the remote participant.

The use of countdown latches can cause main thread blocking, and thus the use of asynchronous notification can reduce the degree of blocking. Whether local or remote, after the corresponding flow is executed, the notification is performed, and only the completion conditions of all local TCC completion phase method calls and remote completion phase method calls need to be traversed, and the last completed thread can see all completed views. And this thread can perform the final TCC transaction state update to the completed work. And at the same time, the information of the transaction can be written into the clearing log to keep the corresponding log table record of the subsequent asynchronous clearing.

Consider that if the completion phase is erroneous, a TCC transaction may be put into the transaction repository and retried by the timed task thread. For a single local participant or remote resource, its completion phase cannot be performed concurrently, otherwise data errors may result. Thus, there is a precondition for retrying the completion phase of the TCC transaction that all local participants and remote resources are not executing. To solve this problem, an identification number may be used to mark how many local participants and remote resources are currently in execution. The identification number is contended by the multithreading, and from this point of view, the TCC transaction object may be allowed to inherit the atom intelger class, and before the completion phase is ready to be executed, it is first determined whether the current identification number is the first number (e.g. -1), and if not, discarded. If the number is the first number, the number of currently required operands (after the number of local participants and the number of remote participants that have not been successful) is counted. And updating by using a CAS mode, and obtaining the execution right if the updating is successful. Monitors are arranged in the execution methods of the local participant and the remote participant, and when the execution is finished, the identification number is subtracted by one. The thread that monitors 0 may decide based on the completion of the local participant and remote resources within the current TCC transaction, update the state of the transaction if all are complete, write the log file and clear the log. If there are more outstanding transactions, then the transaction is placed again into the abnormal transaction set of the transaction repository for the next attempt.

Since the TCC transaction state is updated to be marked commit/rollback, subsequent stages may retry without adverse effects, the participant node may return a response once written to the log file after receiving the commit/rollback instruction from the superordinate node. And the execution of the completion phase is put on the asynchronous task thread, so that the delay of the whole link can be reduced.

Referring to fig. 10, a second embodiment of the present invention also provides a de-centralized TCC transaction management device, including:

a TCC transaction starting unit 210, configured to receive a service execution request initiated by a user, and start a TCC transaction according to the service execution request;

an attempting method generating unit 220 for generating a first attempting method according to the service execution request; wherein the first try-out method comprises at least one participating node which is called remotely and a second try-out method of the called participating node;

an execution condition acquiring unit 230, configured to acquire an execution condition of the second try method by each called participating node;

a marking unit 240, configured to generate a current marking state of the TCC transaction according to the execution situation;

and a coordination unit 250, configured to coordinate the TCC transaction into a completion phase, and perform a validation operation or a rollback operation according to the marking status.

The third embodiment of the present invention also provides a decentralised TCC transaction management node comprising a memory and a processor, the memory having stored therein a computer program executable by the processor to implement a decentralised TCC transaction management method as described above.

The fourth embodiment of the present invention also provides a decentralised TCC transaction management system comprising a decentralised TCC transaction management node as a coordinator as described above and a plurality of participant nodes as participants.

The above description is only of the preferred embodiments of the present invention and is not intended to limit the present invention, but various modifications and variations can be made to the present invention by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method of decentralized TCC transaction management, comprising:

generating a current marking state of the TCC transaction according to the execution condition; when the execution conditions of all the try methods are successful, marking the marked state as the submitted state; when the execution condition of at least one try method is that the identification is executed, marking the marking state as a rollback state;

coordinating the TCC transaction to enter a completion phase, and executing a confirmation operation or a rollback operation according to the marked state;

the system comprises a database log, a log file and a control unit, wherein the database log is used for confirming whether an attempt phase method or a completion phase method is executed when the system is restarted due to downtime; wherein: the internal storage of the database log comprises the stored content which is xid in an object of the try method or finishing stage xid in a confirmation method or a rollback method; the log file is used for reestablishing the TCC transaction when the machine is in downtime and restarted; during the process of the TCC transaction, writing the related key operations into a log file according to the occurrence sequence of time, and executing the key operations after each key operation is written into the log file, so as to restore the transaction according to the information recorded in the log file after downtime restarting; when the transaction is recovered through the log file; checking whether a first try method is successful when the TCC transaction is judged to be in an initial state; if yes, updating the state of the TCC transaction into a commit/rollback state, and putting into an asynchronous thread pool to execute a corresponding completion phase flow; if not, inquiring whether a record of xid of the first try method exists in the log file; if so, updating the first try method to be successful, otherwise, updating the first try method to be failed; updating the state of the TCC transaction according to the updated state of the first try method, and further executing a flow of a completion stage; when the TCC transaction is judged to be in a commit/rollback state, firstly traversing a confirmation method/rollback method list, inquiring whether a finishing stage xid exists in a log file to update whether the corresponding confirmation method/rollback method is finished, and putting an object of the TCC transaction into an asynchronous thread pool after the completion of confirmation, and continuing to execute a commit or rollback flow.

2. The decentralized TCC transaction management method according to claim 1, wherein the TCC transaction has the following attributes:

xid of TCC transaction itself; the xid comprises: a globally unique ID for uniquely identifying the TCC transaction; a branch ID to identify a local transaction that participates in the TCC transaction; wherein for a local transaction in which any node participates in the TCC transaction, it is one branch of a global TCC transaction; when the branch ID of the xid is empty, then indicating that the xid is used to tag the TCC transaction itself;

the current marking state of the TCC transaction; wherein the marking state of the TCC transaction comprises an initial state, a commit/rollback state and an end state;

a list of attempted methods under TCC transaction scope;

3. The decentralized TCC transaction management method according to claim 2, further comprising:

4. The decentralized TCC transaction management method according to claim 1, wherein the completion phase flow is performed in a multithreaded manner, specifically:

5. The method of decentralized TCC transaction management according to claim 4, further comprising, for an abnormal transaction placed in the transaction repository:

if not, aborting the abnormal transaction;

6. An decentralized TCC transaction management device, comprising:

A marking unit, configured to generate a current marking state of the TCC transaction according to the execution condition; when the execution conditions of all the try methods are successful, marking the marked state as the submitted state; when the execution condition of at least one try method is that the identification is executed, marking the marking state as a rollback state;

a coordination unit, configured to coordinate the TCC transaction to enter a completion phase, and perform a validation operation or a rollback operation according to the marking state;

7. A de-centralized TCC transaction management node comprising a memory and a processor, the memory having stored therein a computer program executable by the processor to implement a de-centralized TCC transaction management method as claimed in any one of claims 1 to 5.

8. A de-centralized TCC transaction management system comprising a de-centralized TCC transaction management node in accordance with claim 7 and a plurality of participant nodes acting as participants.