CN111813583A - Transaction management method, device, equipment and storage medium under micro-service architecture - Google Patents
Transaction management method, device, equipment and storage medium under micro-service architecture Download PDFInfo
- Publication number
- CN111813583A CN111813583A CN202010737956.5A CN202010737956A CN111813583A CN 111813583 A CN111813583 A CN 111813583A CN 202010737956 A CN202010737956 A CN 202010737956A CN 111813583 A CN111813583 A CN 111813583A
- Authority
- CN
- China
- Prior art keywords
- transaction
- distributed
- branch
- link
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
Abstract
The invention provides a transaction management method, a device, equipment and a storage medium under a micro-service architecture, wherein the method comprises the following steps: acquiring a transaction starting request initiated by a client; intercepting context information in the transaction starting request to obtain annotation information, and constructing a distributed XA transaction object when the annotation information indicates that the current transaction is a distributed XA transaction; when the distributed XA transaction object is judged to be remotely called, adding a transaction ID in the transaction starting request, starting a distributed XA transaction boundary of remote calling and writing data into a participating node; initiating a request for submitting a transaction, and sending a preparation instruction comprising a transaction ID, so that when a remotely called participating node receives the preparation instruction, a corresponding branch ID is obtained according to the transaction ID and the mapping relation, and then a local branch is searched according to the branch ID and a local resource executes the preparation instruction. The present invention enables the ability for a distributed XA transaction to propagate across multiple application instances.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a storage medium for managing transactions in a microservice architecture
Background
Under the micro-service architecture, a complete service entity is divided into a plurality of application instances for supporting, and each application instance is responsible for managing a data source used by the application instance. In the service scene, only one application instance is needed to participate in the service using only one data source, and a plurality of application instances are also needed to interactively use a plurality of data sources. For services involving multiple data sources, coordination of data consistency and integrity through distributed XA transactions is required. However, the independent distributed XA transaction manager currently provided in the industry is only capable of managing multiple data sources within one application instance through distributed XA transaction coordination, and is not capable of performing distributed XA transaction management across the boundaries of the application instance.
In addition, in one application example, not all businesses need to participate in interaction with other application services, and there are some businesses that only use their own data sources. In this case, if the XA transaction manager is used, since it can manage only XA transactions, it causes problems related to performance degradation and resource waste for a single data source.
Disclosure of Invention
In view of the above, an object of the present invention is to provide a transaction management method, apparatus, device and storage medium under a micro service architecture, which can switch between a stand-alone transaction and an XA transaction according to a configuration, and support distributed XA transaction management across a boundary of an application instance.
The embodiment of the invention provides a transaction management method under a micro-service architecture, which comprises the following steps:
acquiring a transaction starting request initiated by a client; wherein the transaction initiation request includes context information;
intercepting context information in the transaction opening request, and constructing a distributed XA transaction object when the context information indicates that the current transaction is a distributed XA transaction;
when the distributed XA transaction object is judged to be remotely called, adding a transaction ID in a transaction starting request, starting a distributed XA transaction boundary of remote calling and writing data into each participating node; the transaction ID is continuously transmitted to each participating node in a remote calling process, and the participating nodes map the transaction ID with the branch ID of the participating nodes;
after the data is successfully written, initiating a request for submitting a transaction to end a distributed XA transaction boundary, and sending a preparation instruction comprising a transaction ID, so that when a remotely called participating node receives the preparation instruction, a corresponding branch ID is obtained according to the transaction ID and a mapping relation, then a local branch and a local resource are searched according to the branch ID to execute the preparation instruction, a preparation state is fed back, and the preparation instruction is transmitted to a downstream node;
and after receiving the accurate states fed back by all the participating nodes, submitting or rolling back the transaction according to the preparation state.
Preferably, the method further comprises the following steps:
and when the context information indicates that the current transaction is a single-machine transaction, constructing a single-machine transaction object, and mentioning or rolling back the transaction at the node for starting the transaction.
Preferably, the intercepting is performed on the context information in the transaction opening request, specifically:
constructing a transaction method interceptor, and configuring the effective order of the transaction method interceptor before declaring a transaction;
the transaction starting request is intercepted through a transaction method interceptor so as to obtain context information which is annotated by a user in advance in the transaction starting request method.
Preferably, the constructing of the distributed XA transaction object is specifically:
creating a transaction ID and a branch ID, and instantiating a distributed XA transaction object using the transaction ID and the branch ID; the distributed XA transaction object comprises a Xaresesource and an XA link;
obtaining XA link settings from a data source into a distributed XA transaction object;
binding a link object provided by the XA link to a thread context for subsequent services to acquire the link;
the distributed XA transaction object is bound to a thread context.
Preferably, the method further comprises the following steps:
when a remote call is initiated, an address and port number information of a remote application are obtained through a transaction propagation interceptor, a XaResource object representing remote implementation is constructed according to the address and the port number information, and the XaResource object is listed into a distributed XA transaction object, so that resources of the remote application and local resources are regarded as uniform XaResources, and uniform management is performed in the distributed XA transaction object.
Preferably, the method further comprises the following steps:
fetching the distributed XA transaction object in the thread context and storing as a method's return value for return;
unbinding the database link object associated inside the current transaction from the Spring context;
the fetched distributed XA transaction object is returned as a result, storing this suspended distributed XA transaction in a Spring container.
Preferably, the method further comprises the following steps:
when the downtime is recovered, acquiring incomplete transaction information from the transaction log, and acquiring an incomplete distributed XA transaction object from the database;
acquiring an intersection of transaction information in the transaction log and an incomplete distributed XA transaction object, and traversing the distributed XA transaction object in the intersection;
obtaining a role for the distributed XA transaction object;
when the role is a participating node, the distributed transaction object is put into a participating node transaction set;
when the role is not a participating node, acquiring the submission state of the distributed transaction object;
when the distributed transaction object is submitted, acquiring a link carried by the distributed transaction object, setting the link to the current thread context, and submitting a local branch of the distributed transaction object by using the link;
when the distributed transaction object is uncommitted, acquiring a link carried by the distributed transaction object, setting the link to the current thread context, and performing rollback operation on a local branch of the distributed transaction object by using the link;
after the commit operation or the rollback operation is executed, if the state of the transaction is not the termination state, the transaction is put into a retry set to wait for subsequent deployment.
The embodiment of the present invention further provides an affairs management device under the micro-service architecture, including:
the starting request unit is used for acquiring a transaction starting request initiated by a client; wherein the transaction initiation request includes context information;
the intercepting unit is used for intercepting the context information in the transaction starting request and constructing a distributed XA transaction object when the context information indicates that the current transaction is a distributed XA transaction;
the remote call unit is used for adding a transaction ID in the transaction start request, starting a distributed XA transaction boundary of remote call and writing data into each participating node when judging that the distributed XA transaction object is remotely called; the transaction ID is continuously transmitted to each participating node in a remote calling process, and the participating nodes map the transaction ID with the branch ID of the participating nodes;
the preparation unit is used for initiating a request for submitting the transaction after the data is successfully written so as to end the distributed XA transaction boundary and send out a preparation instruction comprising the transaction ID; when the remotely called participating node receives the preparation instruction, acquiring a corresponding branch ID according to the transaction ID and the mapping relation, searching a local branch and a local resource execution preparation instruction according to the branch ID, feeding back a preparation state and transmitting the preparation instruction to a downstream node;
and the submission rollback unit is used for submitting or rolling back the transaction according to the preparation state after receiving the accurate state fed back by all the participating nodes.
The embodiment of the present invention further provides a transaction management device under the micro service architecture, which includes a memory and a processor, wherein a computer program is stored in the memory, and the computer program can be executed by the processor, so as to implement the transaction management method under the micro service architecture.
The embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored, where the computer program can be executed by a processor of a device in which the computer-readable storage medium is located, so as to implement the transaction management method under the micro service architecture.
In summary, compared with the conventional JTA transaction manager, the present embodiment has the following advantages:
the single machine affairs and the distributed XA affairs are switched according to the configuration information of the application, so that the single machine affairs and the XA affairs can be managed simultaneously through one affair manager, the reduction of performance and efficiency caused by using the XA affairs when the business is exchanged on only one data source is avoided, and the performance of the application and the utilization efficiency of resources are improved.
2. The capability of transmitting a distributed XA transaction on a plurality of application instances is realized by attaching a transaction ID to a request sent by a remote call; the technical scheme of the embodiment is that each application instance has a unique and exclusive data source, and each data source can be coordinated on a plurality of application instances to complete a distributed XA transaction, so that the aim of realizing XA transaction management on the data source on each application instance across the application instances is fulfilled.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present invention and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained according to the drawings without inventive efforts.
Fig. 1 is a flowchart illustrating a transaction management method under a microservice architecture according to a first embodiment of the present invention.
Fig. 2 is a functional block diagram of a transaction manager provided in the first embodiment of the present invention.
FIG. 3 is a schematic flow diagram of creating a distributed XA transaction object.
Fig. 4 is a complete interaction timing diagram for a distributed XA transaction when a remote call is made.
Fig. 5 is a block diagram of a transaction management device under the microservice architecture according to a first embodiment of the present invention.
Detailed Description
In order to make 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 described clearly and completely with reference to the accompanying drawings of the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, are within the scope of the present invention. Thus, the following detailed description of the embodiments of the present invention, 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, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, are within the scope of the present invention.
Referring to fig. 1, a first embodiment of the present invention provides a transaction management method under micro-service architecture, which can be executed by a transaction management device, and in particular, by one or more processors in the transaction management device, to at least include the following steps:
s101, acquiring a transaction starting request initiated by a client; wherein the transaction open request includes context information.
S102, intercepting the context information in the transaction starting request, and constructing a distributed XA transaction object when the context information indicates that the current transaction is a distributed XA transaction.
In this embodiment, the transaction management device may be a desktop computer, a notebook computer, a workstation, a server, or other terminal devices with data processing capability. The transaction management device is installed with a client for executing transaction processing and is implemented with a transaction manager based on JTA interface specification, so that the transaction management method of this embodiment is implemented based on the cooperation of the client and the transaction manager.
In this embodiment, as shown in fig. 2, the transaction manager based on JTA interface specification implements JTA related interface according to JTA specification, and the outermost layer is a JTA interface adaptation layer. When a transaction is started, a specific transaction implementation (such as a standalone transaction or an XA transaction) needs to be selected, and the responsibility is given to the transaction mode selector to complete. The JdbcTransaction realized at the transaction interface is used for realizing the management of the single-machine transaction. The XaTransaction implemented at the transaction interface is used to implement management of distributed XA transactions that should meet the requirements of distributed invocations.
In this embodiment, the selection of the transaction is done based on annotations on the business application. Wherein, the opening of the transaction and the committing of the transaction are completed by the declarative transaction in the Spring container. The opening of the transaction only calls a begin method of the JTA interface and does not transfer any context information. Therefore, in order to obtain context information sufficient to determine the transaction type selection, a transaction method interceptor, such as a transactionmethodnterpretector, needs to be implemented. By configuring the effective order of the transaction method interceptors before the declarative transaction, the transaction method interceptors can first obtain context information of a method for starting the transaction, wherein the context information includes a method name, a method object and the like. The transaction Method interceptor can acquire a Method object, namely a Method object, and acquire annotation information on the Method object through the Method object. The client can mark the annotation information on the transaction method in an annotation mode, and the transaction method interceptor can judge which transaction needs to be used by the current transaction method by analyzing the annotation information. And the judgment result is temporarily stored by a thread variable method for being inquired by a subsequent transaction manager. The thread variable is deleted after the transaction method has completely ended.
In this embodiment, the transaction manager will open a stand-alone transaction if the annotation information indicates that it is currently a stand-alone transaction. Since a single transaction only needs to control a single data source. If the transaction is down during execution, the data in the transaction can be automatically cancelled by the database, so that some series of actions such as fault recovery after the down are realized without persistent metadata information, and the transaction can be normally submitted only after the business method is finished in the memory. The opening and committing of the transaction relies on the setauto commit method provided by java.
Specifically, the Transaction manager opens the single Transaction is the actual Transaction interface returned by the method javax. The Spring context already makes corresponding support for the propagation strategy of the transaction, so that the JdbcTransaction does not need to consider the implementation content, and only three method contents of starting, submitting and rolling back of the transaction are needed. The implementation of the three methods can be realized by setAutocommit, commit and rollback of the Connection interface.
After a stand-alone transaction start-up session, Connection needs to be injected into the context of Spring, since support to Spring needs to be used. This is done by means of the tool method provided by Spring, or.
Correspondingly, at the end of the single-machine transaction submission, unbinding is also needed, which is also done by means of Spring's tool method org.
In this embodiment, if the annotation information indicates that a distributed XA Transaction is currently present, the Transaction manager will open the distributed XA Transaction, i.e. the actual implementation of the Transaction interface is XaTransaction.
As shown in fig. 3, implementing a distributed XA transaction object XaTransaction includes:
s1021, creating a transaction ID and a branch ID, and instantiating a distributed XA transaction object by using the transaction ID and the branch ID; the distributed XA transaction object includes a XaResource and an XA link.
Where the transaction ID and the branch ID may be created, for example, by a UUID-like algorithm.
S1022, get XA link setup from data source into distributed XA transaction object.
The link object provided by the XA link is then bound to the thread context for subsequent transactions to obtain the link.
S1023, the distributed XA transaction object is bound to a thread context.
S103, when the distributed XA transaction object is judged to be remotely called, adding a transaction ID in the transaction starting request, starting a remotely called distributed XA transaction boundary and writing data into each participating node; the transaction ID is continuously transmitted to each participating node in a remote calling process, and the participating nodes map the transaction ID with the branch ID of the participating nodes.
S104, after the data is successfully written, initiating a request for submitting a transaction to end the boundary of the distributed XA transaction and sending a preparation instruction comprising a transaction ID; when the remotely called participating node receives the preparation instruction, acquiring a corresponding branch ID according to the transaction ID and the mapping relation, searching a local branch and a local resource execution preparation instruction according to the branch ID, feeding back a preparation state and transmitting the preparation instruction to a downstream node;
and S105, after receiving the accurate states fed back by all the participating nodes, submitting or rolling back the transaction according to the preparation state.
In this embodiment, for a distributed XA transaction, the function of supporting distributed calls is required, and all service instances participating in one transaction are divided into two roles: the system comprises a coordination node and participating nodes, wherein the coordination node is a source initiator of the whole transaction, and the rest nodes are all participating nodes. The coordinating node can determine the trend of the whole transaction according to the feedback information of the direct downstream node; and the participating nodes receive the coordination instruction of the upstream node to execute corresponding service logic, and feed back information upwards according to the feedback information of the direct downstream participating nodes. When a distributed XA transaction needs to be started, the coordination node generates a globally unique transaction ID by adopting a distributed scheme, the transaction ID is continuously transmitted in a distributed call, and under the global transaction, each local branch generates a branch ID by itself. Each transaction manager stores a mapping of transaction IDs and local branch IDs.
In this embodiment, for a distributed XA transaction, the roles of participation include: the system comprises a client, a local transaction manager, a local RM participating node, a remote transaction manager and a remote RM participating node. The complete interaction timing for a distributed XA transaction is shown in fig. 4.
When executing local call, a client opens an XA transaction boundary to open a transaction, then writes data and sends the data to a local transaction manager, the transaction manager writes the data to a local RM participating node and feeds back the success of the written data to the client, and the client sequentially executes a series of operations of submitting a transaction request, ending the XA transaction boundary, sending a preparation instruction, submitting the transaction, writing a log and the like, which are conventional technical means in the field.
However, when a remote call is involved, the client initiates a request of the remote call to the remote transaction manager, where the request carries XA transaction information (i.e. global transaction ID), and after recognizing the transaction ID, the remote transaction manager creates an XATransaction object with a role as a participating node, takes the previous transaction ID as its own transaction ID, creates a branch ID belonging to itself, and sets the transaction in the context of the current thread.
After the creation is successful, the remote transaction manager writes a log, opens an XA transaction boundary, writes data into each remote RM participating node in the transaction boundary after the opening is successful, and feeds back the remote call success to the client after the writing is successful. After receiving the feedback of successful call, the client initiates an instruction for submitting a transaction to the local transaction manager, and the local transaction manager sends an instruction for finishing the XA transaction boundary to the remote transaction manager, so that the XA transaction boundary of the remote RM participating node is finished. After finishing XA transaction boundary, the local transaction manager sends a preparation instruction containing transaction ID to the remote transaction manager, the remote transaction manager searches corresponding local branch and resource according to the mapping relation between the transaction ID and the branch ID in the preparation instruction, executes corresponding instruction requirement, and continuously transmits the preparation instruction to downstream nodes to directly traverse all the participating nodes. After executing the instruction, each participating node also feeds back a preparation state, such as success in preparation or failure in preparation, to the coordinating node (i.e., the client). If all the nodes are successfully prepared, sending an execution instruction and a transaction ID to a direct downstream participant node; otherwise, a rollback instruction and a transaction ID are sent.
As can be seen from the above timing process, in the scope of the distributed XA transaction, if the service application makes a remote call, since the remote application also holds a data source belonging to itself, it is necessary for the local transaction manager to view the remote application as a special XAResource object, which can also initiate the prepare, commit, and rollback methods.
In particular implementation, when a remote call is initiated, a remote application is treated as a special xares resource. The transaction propagation interceptor may inject itself onto the corresponding remote access framework or tool, such as RestTemplate and Feign, which both provide respective plug-in mechanisms that may intercept before the direct request is issued. At this time, the address and port number information of the remote application can be obtained by interception, a xares object representing the remote application is constructed using the two information, and the xares object is listed in the distributed Xa transaction object. Therefore, the resource of the remote application and the resource of the local application are regarded as the uniform XaResource, and the uniform management is carried out in the XaTransaction.
In addition, in order for the remote application to be aware that the current business operation application is under a distributed XA transaction, it is also necessary to transparently pass the global transaction ID of the current transaction and make the remote application aware of the global transaction ID.
To this end, the interceptor may add metadata information to the request, which may include the transaction ID of the distributed XA transaction, before the request is actually sent to the remote application.
In summary, compared with the conventional JTA transaction manager, the present embodiment has the following advantages:
1. the single machine affairs and the distributed XA affairs are switched according to the configuration information of the application, so that the single machine affairs and the XA affairs can be managed simultaneously through one affair manager, the reduction of performance and efficiency caused by using the XA affairs when the business is exchanged on only one data source is avoided, and the performance of the application and the utilization efficiency of resources are improved.
2. The capability of transmitting a distributed XA transaction on a plurality of application instances is realized by attaching a transaction ID to a request sent by a remote call; the technical scheme of the embodiment is that each application instance has a unique and exclusive data source, and each data source can be coordinated on a plurality of application instances to complete a distributed XA transaction, so that the aim of realizing XA transaction management on the data source on each application instance across the application instances is fulfilled.
In order to facilitate an understanding of the invention, some preferred embodiments of the invention are described further below.
For transaction suspension and transaction resumption, a preferred embodiment of the present invention further comprises:
fetching the distributed XA transaction object in the thread context and storing as a method's return value for return;
unbinding the database link object associated inside the current transaction from the Spring context;
the fetched distributed XA transaction object is returned as a result, storing this suspended distributed XA transaction in a Spring container.
In the process of transaction propagation, if a transaction needs to be restarted, a new transaction can be started only after the current transaction is suspended. This interface is also provided in the JTA specification, namely the method Transactionmanager # suspend. Spring internally implements the transaction staging function for pending transactions during transaction propagation, so this consideration may be omitted for the implementer of the transaction manager of JTA. Based on this, the suspend method is relatively simple to implement. Only 2 actions need to be completed:
1. the transaction object in the thread context is fetched and stored as a return value of the method for return.
2. The database link object that is associated inside the current transaction is unbound from the Spring context. After the two actions are completed, the fetched transaction object is returned as a result. The Spring container will store this pending transaction and resume at a later appropriate time.
Transaction recovery
Transaction recovery and transaction suspension are inverse processes and are implemented by means of the method avax. Similar to resume and suspend, only 2 steps need to be implemented:
1. a given transaction object is bound to a thread context.
2. And binding the link resource associated with the transaction to the Spring context.
And for downtime recovery:
an application node in a transaction may fail or be down for various reasons, which will result in the transaction not being in an intermediate state (this is not the case for a single transaction, this scenario is only for distributed XA transactions). Therefore, after the application node is restarted, the first task to be completed is downtime recovery. The transaction that was previously in progress is completed, either committed or cancelled, eventually causing the transaction to complete. The downtime recovery depends on the incomplete transaction metadata information recorded in the transaction log and the decision information of the subsequent direction of the transaction, and by means of the information, the XA transactions to be recovered can be obtained from the database, and the commit or rollback action is executed to enable the database to complete the transactions, and finally the locked resources are released.
To this end, a preferred embodiment of the present invention further comprises:
when the downtime is recovered, acquiring incomplete transaction information from the transaction log, and acquiring an incomplete distributed XA transaction object from the database;
acquiring an intersection of transaction information in the transaction log and an incomplete distributed XA transaction object, and traversing the distributed XA transaction object in the intersection;
obtaining a role for the distributed XA transaction object;
when the role is a participating node, the distributed transaction object is put into a participating node transaction set;
when the role is not a participating node, acquiring the submission state of the distributed transaction object;
when the distributed transaction object is submitted, acquiring a link carried by the distributed transaction object, setting the link to the current thread context, and submitting a local branch of the distributed transaction object by using the link;
when the distributed transaction object is uncommitted, acquiring a link carried by the distributed transaction object, setting the link to the current thread context, and performing rollback operation on a local branch of the distributed transaction object by using the link;
after the commit operation or the rollback operation is executed, if the state of the transaction is not the termination state, the transaction is put into a retry set to wait for subsequent deployment.
It should be noted that, in this embodiment, under the XA protocol, the transaction manager needs to be responsible for failure recovery of restart after the application is down, and therefore, information related to the transaction needs to be recorded. For the RM, a distributed XA transaction will clear itself if it does not enter the prepare phase, and the transaction manager does not have to be responsible. Only the process of committing a transaction involves a prepare operation. So only the process of committing the transaction needs to write the log. Writing different contents in three nodes, namely:
before preparing for commit, write all participant information for the transaction, including: XID of the local XA participant, ip and port of the far end participant.
And after all the participating nodes are successfully prepared or have partial response failure, subsequently determining whether the whole nodes are submitted or rolled back, and writing the determination of the transaction.
And writing the result of the transaction after all the transactions are submitted or the rollback is successful.
A second embodiment of the present invention further provides a transaction management apparatus under a micro service architecture, including:
an open request unit 210, configured to obtain a transaction open request initiated by a client; wherein the transaction initiation request includes context information;
an intercepting unit 220, configured to intercept context information in the transaction start request, and construct a distributed XA transaction object when the context information indicates that the current transaction is a distributed XA transaction;
the remote invocation unit 230 is configured to, when it is determined that the distributed XA transaction object is remotely invoked, add a transaction ID to the transaction start request, start a distributed XA transaction boundary of the remote invocation, and write data into each participating node; the transaction ID is continuously transmitted to each participating node in a remote calling process, and the participating nodes map the transaction ID with the branch ID of the participating nodes;
a preparing unit 240, configured to initiate a request to commit the transaction after the data is successfully written, to end the distributed XA transaction boundary, and issue a preparing instruction including a transaction ID; when the remotely called participating node receives the preparation instruction, acquiring a corresponding branch ID according to the transaction ID and the mapping relation, searching a local branch and a local resource execution preparation instruction according to the branch ID, feeding back a preparation state and transmitting the preparation instruction to a downstream node;
and a commit rollback unit 250, configured to, after receiving the accurate states fed back by all the participating nodes, commit or rollback the transaction according to the preparation state.
The third embodiment of the present invention further provides a transaction management device under the micro service architecture, including a memory and a processor, where the memory stores a computer program, and the computer program can be executed by the processor to implement the transaction management method under the micro service architecture.
The fourth embodiment of the present invention further provides a computer-readable storage medium, which stores a computer program, where the computer program can be executed by a processor of a device where the computer-readable storage medium is located, so as to implement the transaction management method under the microservice architecture as described above.
In the embodiments provided in the present invention, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus and method embodiments described above are illustrative only, as the flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition, the functional modules in the embodiments of the present invention may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, an electronic device, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes. It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (10)
1. A transaction management method under a micro-service architecture is characterized by comprising the following steps:
acquiring a transaction starting request initiated by a client; wherein the transaction initiation request includes context information;
intercepting context information in the transaction starting request to obtain annotation information, and constructing a distributed XA transaction object when the annotation information indicates that the current transaction is a distributed XA transaction;
when the distributed XA transaction object is judged to be remotely called, adding a transaction ID in a transaction starting request, starting a distributed XA transaction boundary of remote calling and writing data into each participating node; the transaction ID is continuously transmitted to each participating node in a remote calling process, and the participating nodes map the transaction ID with the branch ID of the participating nodes;
after the data is successfully written, initiating a request for submitting a transaction to end a distributed XA transaction boundary, and sending a preparation instruction comprising a transaction ID, so that when a remotely called participating node receives the preparation instruction, a corresponding branch ID is obtained according to the transaction ID and a mapping relation, then a local branch and a local resource are searched according to the branch ID to execute the preparation instruction, and a preparation state is fed back and the preparation instruction is transmitted to a downstream participating node;
and after receiving the accurate states fed back by all the participating nodes, submitting or rolling back the transaction according to the preparation state.
2. The transaction management method under the micro-service architecture of claim 1, further comprising:
and when the annotation information indicates that the current transaction is a single-machine transaction, constructing a single-machine transaction object, and submitting or rolling back the single-machine transaction at the node for starting the transaction.
3. The transaction management method under the micro-service architecture according to claim 1, wherein intercepting context information in the transaction start request to obtain annotation information specifically comprises:
constructing a transaction method interceptor, and configuring the effective order of the transaction method interceptor before the declarative transaction;
intercepting the transaction starting request through a transaction method interceptor so as to obtain annotation information which is pre-marked by a user in context information of a method object of the transaction starting request.
4. The transaction management method under the micro-service architecture of claim 1, wherein constructing a distributed XA transaction object specifically comprises:
creating a transaction ID and a branch ID, and instantiating a distributed XA transaction object using the transaction ID and the branch ID; the distributed XA transaction object comprises a Xaresesource and an XA link;
obtaining XA link settings from a data source into a distributed XA transaction object;
binding a link object provided by the XA link to a thread context for subsequent services to acquire the link;
the distributed XA transaction object is bound to a thread context.
5. The transaction management method under the micro-service architecture of claim 4, further comprising:
when a remote call is initiated, an address and port number information of a remote application are obtained through a transaction propagation interceptor, a XaResource object representing remote implementation is constructed according to the address and the port number information, and the XaResource object is listed into a distributed XA transaction object, so that resources of the remote application and local resources are regarded as uniform XaResources, and uniform management is performed in the distributed XA transaction object.
6. The transaction management method under the micro-service architecture of claim 4, further comprising:
fetching the distributed XA transaction object in the thread context and storing as a method's return value for return;
unbinding the database link object associated inside the current transaction from the Spring context;
the fetched distributed XA transaction object is returned as a result, storing this suspended distributed XA transaction in a Spring container.
7. The transaction management method under the micro-service architecture of claim 4, further comprising:
when the downtime is recovered, acquiring incomplete transaction information from the transaction log, and acquiring an incomplete distributed XA transaction object from the database;
acquiring an intersection of transaction information in the transaction log and an incomplete distributed XA transaction object, and traversing the distributed XA transaction object in the intersection;
obtaining a role for the distributed XA transaction object;
when the role is a participating node, the distributed transaction object is put into a participating node transaction set;
when the role is not a participating node, acquiring the submission state of the distributed transaction object;
when the distributed transaction object is submitted, acquiring a link carried by the distributed transaction object, setting the link to the current thread context, and submitting a local branch of the distributed transaction object by using the link;
when the distributed transaction object is uncommitted, acquiring a link carried by the distributed transaction object, setting the link to the current thread context, and performing rollback operation on a local branch of the distributed transaction object by using the link;
after the commit operation or the rollback operation is executed, if the state of the transaction is not the termination state, the transaction is put into a retry set to wait for subsequent deployment.
8. A transaction management device under a microservice architecture, comprising:
the starting request unit is used for acquiring a transaction starting request initiated by a client; wherein the transaction initiation request includes context information;
the intercepting unit is used for intercepting the context information in the transaction starting request to obtain annotation information and constructing a distributed XA transaction object when the annotation information indicates that the current transaction is a distributed XA transaction;
the remote call unit is used for adding a transaction ID in the transaction start request, starting a distributed XA transaction boundary of remote call and writing data into each participating node when judging that the distributed XA transaction object is remotely called; the transaction ID is continuously transmitted to each participating node in a remote calling process, and the participating nodes map the transaction ID with the branch ID of the participating nodes;
the preparation unit is used for initiating a request for submitting the transaction after the data is successfully written so as to end the distributed XA transaction boundary and send out a preparation instruction comprising the transaction ID; when the remotely called participating node receives the preparation instruction, acquiring a corresponding branch ID according to the transaction ID and the mapping relation, searching a local branch and a local resource execution preparation instruction according to the branch ID, feeding back a preparation state and transmitting the preparation instruction to a downstream node;
and the submission rollback unit is used for submitting or rolling back the transaction according to the preparation state after receiving the accurate state fed back by all the participating nodes.
9. A transaction management device under micro-service architecture, comprising a memory and a processor, wherein the memory stores a computer program, and the computer program can be executed by the processor to implement the transaction management method under micro-service architecture according to any one of claims 1 to 7.
10. A computer-readable storage medium, in which a computer program is stored, the computer program being executable by a processor of a device in which the computer-readable storage medium is located, so as to implement the transaction management method under the micro-service architecture according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010737956.5A CN111813583B (en) | 2020-07-28 | 2020-07-28 | Transaction management method, device, equipment and storage medium under micro-service architecture |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010737956.5A CN111813583B (en) | 2020-07-28 | 2020-07-28 | Transaction management method, device, equipment and storage medium under micro-service architecture |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111813583A true CN111813583A (en) | 2020-10-23 |
| CN111813583B CN111813583B (en) | 2023-06-20 |
Family
ID=72863287
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010737956.5A Active CN111813583B (en) | 2020-07-28 | 2020-07-28 | Transaction management method, device, equipment and storage medium under micro-service architecture |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111813583B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112395104A (en) * | 2020-11-16 | 2021-02-23 | 中国工商银行股份有限公司 | Method and device for realizing transmission of distributed transaction context at routing layer |
| CN112463810A (en) * | 2020-12-08 | 2021-03-09 | 佳讯飞鸿（北京）智能科技研究院有限公司 | Data processing method, device, equipment and storage medium based on distributed transaction |
| CN113360299A (en) * | 2021-06-29 | 2021-09-07 | 深圳市商汤科技有限公司 | Transaction processing method and related product |
| CN116302845A (en) * | 2023-05-17 | 2023-06-23 | 建信金融科技有限责任公司 | Method and device for determining transaction operation mode, electronic equipment and storage medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050144171A1 (en) * | 2003-12-24 | 2005-06-30 | International Business Machines Corporation | Involving participants in a distributed transaction |
| CN106161519A (en) * | 2015-04-01 | 2016-11-23 | 阿里巴巴集团控股有限公司 | A kind of information getting method and device |
| CN108459919A (en) * | 2018-03-29 | 2018-08-28 | 中信百信银行股份有限公司 | A kind of distributed transaction processing method and device |
| CN109710431A (en) * | 2018-12-28 | 2019-05-03 | 四川新网银行股份有限公司 | A method of it reducing large-scale distributed system interface and service calculates call number |
| CN111062684A (en) * | 2019-11-29 | 2020-04-24 | 普元信息技术股份有限公司 | System and method for realizing consistent processing of business data and process data under cloud process platform |
-
2020
- 2020-07-28 CN CN202010737956.5A patent/CN111813583B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050144171A1 (en) * | 2003-12-24 | 2005-06-30 | International Business Machines Corporation | Involving participants in a distributed transaction |
| CN106161519A (en) * | 2015-04-01 | 2016-11-23 | 阿里巴巴集团控股有限公司 | A kind of information getting method and device |
| CN108459919A (en) * | 2018-03-29 | 2018-08-28 | 中信百信银行股份有限公司 | A kind of distributed transaction processing method and device |
| CN109710431A (en) * | 2018-12-28 | 2019-05-03 | 四川新网银行股份有限公司 | A method of it reducing large-scale distributed system interface and service calculates call number |
| CN111062684A (en) * | 2019-11-29 | 2020-04-24 | 普元信息技术股份有限公司 | System and method for realizing consistent processing of business data and process data under cloud process platform |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112395104A (en) * | 2020-11-16 | 2021-02-23 | 中国工商银行股份有限公司 | Method and device for realizing transmission of distributed transaction context at routing layer |
| CN112395104B (en) * | 2020-11-16 | 2023-12-01 | 中国工商银行股份有限公司 | Method and device for realizing distributed transaction context transfer in routing layer |
| CN112463810A (en) * | 2020-12-08 | 2021-03-09 | 佳讯飞鸿（北京）智能科技研究院有限公司 | Data processing method, device, equipment and storage medium based on distributed transaction |
| CN113360299A (en) * | 2021-06-29 | 2021-09-07 | 深圳市商汤科技有限公司 | Transaction processing method and related product |
| CN116302845A (en) * | 2023-05-17 | 2023-06-23 | 建信金融科技有限责任公司 | Method and device for determining transaction operation mode, electronic equipment and storage medium |
| CN116302845B (en) * | 2023-05-17 | 2023-08-15 | 建信金融科技有限责任公司 | Method and device for determining transaction operation mode, electronic equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111813583B (en) | 2023-06-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111813583A (en) | Transaction management method, device, equipment and storage medium under micro-service architecture | |
| US11914486B2 (en) | Cloning and recovery of data volumes | |
| US20230023262A1 (en) | System and method for supporting patching in a multitenant application server environment | |
| CN110768833B (en) | Application arrangement and deployment method and device based on kubernets | |
| CN113169952B (en) | Container cloud management system based on block chain technology | |
| US11061884B2 (en) | Method and system to accelerate transaction commit using non-volatile memory | |
| US8104043B2 (en) | System and method for dynamic cooperative distributed execution of computer tasks without a centralized controller | |
| US10133596B2 (en) | System and method for supporting application interoperation in a transactional middleware environment | |
| US9929916B1 (en) | Achieving stateful application software service behavior in distributed stateless systems | |
| US8484637B2 (en) | Parallel installation | |
| CN109981279B (en) | Block chain system, communication method, device, equipment and medium | |
| CN108681777B (en) | Method and device for running machine learning program based on distributed system | |
| US10581966B2 (en) | Cloud services integrated backup and restore | |
| WO2019208098A1 (en) | Coordination process restarting device and coordination process restarting method | |
| JPH11345130A (en) | Method for achieving data matching by synchronization with plural data stores | |
| CN114328432A (en) | Big data federal learning processing method and system | |
| CN112148436A (en) | Decentralized TCC (transmission control protocol) transaction management method, device, equipment and system | |
| CN108108119B (en) | Configuration method and device for extensible storage cluster things | |
| WO2006131440A1 (en) | Apparatus, system, and method for facilitating communication between an enterprise information system and a client | |
| CN112035062A (en) | Migration method of local storage of cloud computing, computer equipment and storage medium | |
| US10740085B2 (en) | Webserver interface for deployment management tool | |
| CN114787836A (en) | System and method for remotely executing one or more arbitrarily defined workflows | |
| CN113220480B (en) | Distributed data task cross-cloud scheduling system and method | |
| CN114860505A (en) | Object storage data asynchronous backup method and system | |
| CN111522688B (en) | Data backup method and device for distributed system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 361000 one of 504, No. 18, guanri Road, phase II, software park, Xiamen, Fujian Applicant after: XIAMEN YILIANZHONG YIHUI TECHNOLOGY CO.,LTD. Address before: Room 504, No.18, guanri Road, phase II, software park, Xiamen City, Fujian Province, 361000 Applicant before: XIAMEN YILIANZHONG YIHUI TECHNOLOGY CO.,LTD. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |