CN119322658A - Distributed transaction processing method, system, equipment and storage medium - Google Patents
Distributed transaction processing method, system, equipment and storage medium Download PDFInfo
- Publication number
- CN119322658A CN119322658A CN202411218979.XA CN202411218979A CN119322658A CN 119322658 A CN119322658 A CN 119322658A CN 202411218979 A CN202411218979 A CN 202411218979A CN 119322658 A CN119322658 A CN 119322658A
- Authority
- CN
- China
- Prior art keywords
- transaction
- resource manager
- branch
- global transaction
- global
- 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.)
- Pending
Links
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/466—Transaction processing
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The present specification relates to a method, system, device and storage medium for processing distributed transactions. The method comprises the steps of determining one resource manager from a plurality of resource managers executing business logic to serve as a master resource manager when a global transaction sent by a client is received, dividing the global transaction into at least one branch transaction when the global transaction needs to execute external call logic by the master resource manager, calling at least one slave resource manager to execute the branch transaction, receiving an execution result of a corresponding branch transaction returned by the master resource manager, and submitting or rolling back the global transaction according to the execution result of each branch transaction by the master resource manager. According to the embodiment of the specification, the distributed transaction processing of the decentralization service is realized, a method for maintaining the states of global and branch transactions by a fixed transaction coordinator is abandoned, and the problem of single-point faults is avoided.
Description
Technical Field
Embodiments of the present disclosure relate to the field of distributed processing technologies, and in particular, to a method, a system, an apparatus, and a storage medium for processing a distributed transaction.
Background
A problem with existing TCC (Try-Confirm-cancer) solutions is the need for a transaction coordinator, namely seata services (TC), which acts as a global transaction manager, responsible for receiving and managing global transactions. When a client initiates a global transaction, the transaction coordinator will assign it a globally unique transaction ID and track the status of the transaction. In addition, in branch transaction management, the transaction coordinator ensures that multiple branch transactions execute in the correct order and eventually achieve a consistent state. The protocol control of two-phase commit includes two phases, pre-commit (try) and commit/rollback (commit/rollback), where the transaction coordinator will notify all resource managers participating in the transaction to commit or rollback. Although the transaction coordinator plays an important role in the TCC transaction framework, if the transaction coordinator fails (single point of failure), the entire global transaction operation is not available, affecting the transaction processing of the distributed system.
The technical problem to be solved is currently urgent in how to improve the stability of the distributed system.
Disclosure of Invention
In order to solve the problem that single-point faults are easy to occur in the existing TCC technical scheme, the whole global transaction operation is unavailable and the problem of responding to the transaction processing of a distributed system is solved, the embodiment of the specification provides a distributed transaction processing method, a system, equipment and a storage medium, the distributed transaction processing of a decentralization service is realized, a method for maintaining the states of global and branch transactions by a fixed transaction coordinator is abandoned, and the single-point fault problem is avoided.
The specific technical scheme of the embodiment of the specification is as follows:
in one aspect, embodiments of the present disclosure provide a method for processing a distributed transaction, where the method includes:
when a global transaction sent by a client is received, one resource manager is determined from a plurality of resource managers executing business logic to serve as a master resource manager of the global transaction, and other resource managers serve as slave resource managers of the global transaction;
when the global transaction needs to execute the callout logic, the master resource manager splits the global transaction into at least one branch transaction and calls at least one slave resource manager to execute the branch transaction;
the master resource manager receives the execution result of the corresponding branch transaction returned by the slave resource manager;
And the master resource manager submits or rolls back the global transaction according to the execution result of each branch transaction.
Further, after the master resource manager splits the global transaction into at least one branch transaction, the method further comprises:
The master resource manager performs at least one branch transaction.
Further, before the master resource manager invokes at least one slave resource manager to execute the branch transaction, the method further comprises:
The master resource manager determines a submitting mode of the branch transaction according to the configuration information, wherein the submitting mode is one-stage submitting or two-stage submitting;
the master resource manager invoking at least one slave resource manager to execute the branch transaction further comprises:
and the resource manager calls the slave resource manager to execute the branch transaction according to the submitting mode.
Further, when the master resource manager invokes the slave resource manager to execute the branch transaction, the method further comprises:
The slave resource manager judges whether the branch transaction executed by the slave resource manager needs to execute the callout logic;
If yes, the slave resource manager splits the branch transaction into at least one sub-branch transaction, and invokes at least one idle slave resource manager of the global transaction to execute the sub-branch transaction, the slave resource manager receives the execution result of the corresponding sub-branch transaction returned by the slave resource manager, and returns the execution result of the branch transaction to the master resource manager according to the execution result of each sub-branch transaction.
Further, after determining the master resource manager, the method further comprises:
The master resource manager creates a global transaction ID of the global transaction, binds the global transaction ID into a thread context corresponding to the global transaction, so that the slave resource manager can acquire the global transaction ID from the thread context, and executes the branch transaction corresponding to the global transaction ID.
Further, the method further comprises:
And the master resource manager writes the information of the global transaction into a global transaction table, writes the information of the branch transaction into a branch transaction table, and associates the global transaction table with the branch transaction table.
Further, the information of the global transaction includes a global transaction state.
Further, the method further comprises:
Each slave resource manager executes the respective timing task to asynchronously inquire the global transaction state in the global transaction table, judges whether the global transaction state is overtime and not updated, and if so, determines the slave resource manager with the overtime and not updated global transaction state as the master resource manager to roll back the global transaction.
Further, each slave resource manager executing a respective timed task asynchronously querying global transaction states in the global transaction table includes:
the slave resource manager executes the self timing task to acquire the query lock of the global transaction state in the global transaction table;
if the query lock is obtained, executing the steps of querying the global transaction state and judging whether the global transaction state is overtime and not updated;
releasing the query lock if the global transaction state is not updated after timeout;
if the global transaction state is overtime and is not updated, releasing the query lock after taking the global transaction state as the main resource manager;
And if the query lock is not acquired, ending the timing task, and executing the next timing task to acquire the query lock after the next timing time arrives.
Further, the information of the branch transactions includes the correspondence between each branch transaction and the corresponding slave resource manager.
Further, the step of the master resource manager performing rollback of the global transaction includes:
And the master resource manager determines a branch transaction table associated with the global transaction table, and calls the slave resource manager corresponding to each branch transaction to re-execute each branch transaction according to the branch transaction table.
Further, determining one resource manager from the plurality of resource managers executing the business logic as the master resource manager includes:
The resource manager that receives the global transaction acts as the master resource manager.
Further, the splitting the global transaction into at least one branch transaction by the master resource manager comprises:
And the master resource manager splits the global transaction into branch transactions corresponding to the service types according to at least one service type in the global transaction.
In another aspect, embodiments of the present disclosure further provide a distributed transaction processing system, the system including a plurality of resource managers executing business logic;
the plurality of resource managers perform the method described above when processing global transactions sent by clients.
In another aspect, embodiments of the present disclosure further provide a computer device, including a memory, a processor, and a computer program stored on the memory, where the processor implements the method described above when executing the computer program.
In another aspect, the present description embodiment also provides a computer-readable storage medium storing a computer program which, when executed by a processor, implements the above-described method.
Finally, the present description embodiment also provides a computer program product comprising a computer program which, when executed by a processor, implements the above-mentioned method.
According to the embodiment of the specification, a transaction coordinator is abandoned, one resource manager is determined from a plurality of resource managers executing business logic to serve as a main resource manager of the global transaction when the global transaction sent by a client is received, the main resource manager executes TC service of the original transaction coordinator, namely, when the global transaction needs to execute callout logic, the main resource manager splits the global transaction into at least one branch transaction and calls at least one slave resource manager to execute the branch transaction, then the main resource manager receives an execution result of a response branch transaction returned by the slave resource manager, and finally the main resource manager submits or rolls back the global transaction according to the execution result of each branch transaction. The method of the embodiment of the specification realizes the processing of the decentralized distributed transaction, avoids the occurrence of single-point fault, and compared with the traditional TCC implementation mode, the branch transaction and the global transaction registration of the embodiment of the specification do not need to be adjusted outwards, thereby reducing the communication time of the external adjustment.
Drawings
In order to more clearly illustrate the embodiments of the present description or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present description, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram of a system for implementing a method for processing distributed transactions according to an embodiment of the present disclosure;
FIG. 2 is a flow chart illustrating a method of processing distributed transactions according to an embodiment of the present disclosure;
FIG. 3 is a flow chart illustrating a method of submitting a configured branch transaction according to an embodiment of the present disclosure;
FIG. 4 is a schematic flow chart of the saga-stage client execution logic in the embodiment of the present disclosure;
FIG. 5 is a flow diagram illustrating a nested call from a resource manager in an embodiment of the present disclosure;
FIG. 6 is a schematic flow chart of the execution logic of the saga two-stage server when there is a nested call in the embodiment of the present disclosure;
FIG. 7 is a flow diagram illustrating global transaction rollback upon determination of a primary resource manager failure in an embodiment of the present disclosure;
FIG. 8 is a flow chart of asynchronous querying of global transaction states in the global transaction table by each slave resource manager executing a respective timed task in an embodiment of the present disclosure;
fig. 9 is a schematic diagram showing the structure of a computer device in the embodiment of the present specification.
[ Reference numerals description ]:
101. A client;
102. a distributed system;
1021. a resource manager;
902. a computer device;
904. A processing device;
906. storing the resource;
908. A drive system;
910. an input/output module;
912. an input device;
914. an output device;
916. a presentation device;
918. A graphical user interface;
920. a network interface;
922. a communication link;
924. A communication bus.
Detailed Description
The technical solutions of the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is apparent that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the embodiments of the present disclosure, are intended to be within the scope of the embodiments of the present disclosure.
It should be noted that the terms "first," "second," and the like in the description and the claims of the embodiments of the present specification and the above-described drawings are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present description described herein may be capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, apparatus, article, or device that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or device.
It should be noted that, in the technical solution of the embodiments of the present disclosure, the acquiring, storing, using, processing, etc. of data all conform to relevant regulations of national laws and regulations.
It should be noted that, in the embodiments of the present disclosure, some existing solutions in the industry such as software, components, models, etc. may be mentioned, and they should be considered as exemplary, only for illustrating the feasibility of implementing the technical solution of the present disclosure, but it does not mean that the applicant has or must not use the solution.
Fig. 1 is a schematic structural diagram of a system for implementing a method for processing a distributed transaction in an embodiment of the present disclosure, including a client 101 and a distributed system 102, where the distributed system 102 includes a plurality of resource managers 1021 for executing service logic, and it is understood that the resource managers 1021 are processing nodes in the distributed system 102 and have service processing capability.
Alternatively, resource manager 1021 may be a computer, and distributed system 102 may be a system comprising multiple computers interconnected by a network and functioning as a distributed processing system.
In addition, it should be noted that, fig. 1 is only one application environment provided in the embodiment of the present disclosure, and in practical application, other application environments may also be included, which is not limited in the present disclosure.
In the existing TCC scheme, a separate transaction coordinator TC needs to be deployed, the transaction coordinator TC executes a service of a service (ta), all transactions sent by clients (i.e., services, such as banking services sent by users through internet banking or mobile banking clients) need to be managed by the transaction coordinator TC, and at least one resource manager 1021 is coordinated to process, where the commit mode includes one-stage commit and two-stage commit, and the transaction coordinator TC is responsible for one-stage commit or rollback, two-stage commit or rollback of the global transactions.
If the transaction coordinator TC fails, all transactions cannot be processed normally, and the influence is large.
In view of the above problems, the embodiments of the present disclosure provide a method for processing a distributed transaction, which implements distributed transaction processing of a decentralized service, and abandons a method for maintaining the states of global and branch transactions by a fixed transaction coordinator, without a single point of failure problem.
Fig. 2 is a flow chart illustrating a method of processing a distributed transaction according to an embodiment of the present disclosure. The global transaction processing is described in this figure. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When a system or apparatus product in practice is executed, it may be executed sequentially or in parallel according to the method shown in the embodiments or the drawings.
As shown in detail, the method may include:
step 201, when a global transaction sent by a client is received, determining one resource manager from a plurality of resource managers executing business logic as a master resource manager of the global transaction, and other resource managers as slave resource managers of the global transaction;
step 202, when the global transaction needs to execute the callout logic, the master resource manager splits the global transaction into at least one branch transaction and calls at least one slave resource manager to execute the branch transaction;
step 203, the master resource manager receives the execution result of the corresponding branch transaction returned by the slave resource manager;
And 204, the master resource manager submits or rolls back the global transaction according to the execution result of each branch transaction.
According to the embodiment of the specification, a transaction coordinator is abandoned, one resource manager is determined from a plurality of resource managers executing business logic to serve as a main resource manager of the global transaction when the global transaction sent by a client is received, the main resource manager executes TC service of the original transaction coordinator, namely, when the global transaction needs to execute callout logic, the main resource manager splits the global transaction into at least one branch transaction and calls at least one slave resource manager to execute the branch transaction, then the main resource manager receives an execution result of a response branch transaction returned by the slave resource manager, and finally the main resource manager submits or rolls back the global transaction according to the execution result of each branch transaction. The method of the embodiment of the specification realizes the processing of the decentralized distributed transaction, avoids the occurrence of single-point fault, and compared with the traditional TCC implementation mode, the branch transaction and the global transaction registration of the embodiment of the specification do not need to be adjusted outwards, thereby reducing the communication time of the external adjustment.
In this embodiment of the present disclosure, a distributed system may deploy a load balancer, where the load balancer distributes, according to the load condition of each resource manager, a global transaction sent by a client to one resource manager, and the resource manager that receives the global transaction may be a master resource manager of the global transaction, and execute TC service. The other resource manager is the slave resource manager of the global transaction.
The master resource manager generates a global transaction ID of the global transaction, and then writes information of the global transaction such as the global transaction ID into a global transaction table, where the information of the global transaction may further include a global transaction state (a transaction state such as start, commit, rollback, two-stage commit, etc.), a transaction timeout time, a global transaction name, a transaction start time, and the like. The master resource manager performs TC services, maintains the states of global and branch transactions, coordinates global transaction commit or rollback, and is responsible for updating the global transaction state and other information for the global transaction in the global transaction table.
When the global transaction needs to execute the callout logic (such as rpc callout or feign callout), the master resource manager splits the global transaction into at least one branch transaction, specifically, the global transaction may be split into branch transactions corresponding to the service types according to at least one service type in the global transaction, such as deposit service, loan service, comprehensive service, and the like.
Optionally, each service type corresponds to a branch transaction, and the master resource manager invokes a slave resource manager corresponding to the number of branch transactions to execute the branch transactions.
In addition, because the master resource manager also has business logic execution capability, the master resource manager may also execute at least one branch transaction, and send the execution result of the branch transaction to the TC service running on its own.
The execution result of each branch transaction is successful under normal conditions, however, the situation of execution failure may also occur, and the master resource manager judges whether the execution result of each branch transaction is successful, if so, the global transaction is submitted. If the branch transaction is not executed successfully, rollback is carried out, and the corresponding branch transaction is indicated to be re-executed from the resource manager.
The master resource manager also writes information of the branch transaction into the branch transaction table, and the information of the branch transaction may include an ID of the branch transaction, a branch transaction state, a branch transaction timeout time, a branch transaction name, an application name and a class name of a call, a method name of a try phase, a rollback method name, unit information (for saga transactions under a unitized architecture), a request type (for distinguishing rpc callbacks or feign callbacks), a correspondence between the branch transaction and the slave resource manager, and the like.
According to one embodiment of the present description, the step of the master resource manager performing rollback of the global transaction includes:
And the master resource manager determines a branch transaction table associated with the global transaction table, and calls the slave resource manager corresponding to each branch transaction to re-execute each branch transaction according to the branch transaction table.
In the present embodiment, a plurality of containers may be deployed on each resource manager, each container having business logic processing capabilities. The master resource manager may execute the TC service on a free container. The branch transaction includes a plurality of computing tasks that may be performed by a plurality of containers of the resource manager, embodiments of the present description are not limited.
Thus, the master resource manager may execute branch transactions of other global transactions as slave resource managers of other global transactions at the same time, in addition to the TC service that may execute the global transaction.
According to one embodiment of the present disclosure, after determining the master resource manager, in order to optimize the processing flow of the branch transaction, the method further includes:
The master resource manager creates a global transaction ID of the global transaction and binds the global transaction ID to a thread (threadlocal) context corresponding to the global transaction, so that the slave resource manager obtains the global transaction ID from the thread context and executes the branch transaction corresponding to the global transaction ID.
It will be appreciated that binding the global transaction ID in threadlocal context, the processing of the branch transaction may obtain the global transaction ID from the context without reference.
In an embodiment of the present disclosure, the manner of submitting the branch transaction may include a one-stage commit and a two-stage commit, so as to improve flexibility of submitting the branch transaction, and before the master resource manager invokes at least one slave resource manager to execute the branch transaction, according to one embodiment of the present disclosure, as shown in fig. 3, the method further includes:
Step 301, the master resource manager determines a submitting mode of the branch transaction according to configuration information, wherein the submitting mode is one-stage submitting or two-stage submitting;
the master resource manager invoking at least one slave resource manager to execute the branch transaction further comprises:
step 302, the resource manager calls the slave resource manager to execute the branch transaction according to the submitting mode.
In the embodiment of the present disclosure, the configuration information may be configured by a banking staff according to an actual service, and instruct a commit mode (one-stage commit or two-stage commit) of the branch transaction under each global transaction.
Based on this, the embodiment of the present specification adds two-stage method names in saga stages, and the default format is { class name. Method name }, which is used to locate the two-stage execution method after the one-stage execution is completed. The branch transaction annotation @ ApSagaBranch adds a two-phase method attribute apTwoCommitMethod. And meanwhile, the two-stage execution type is added to distinguish whether a try stage call, a rollback stage call or a two-stage confirm call.
In the embodiment of the specification, the server side of the try phase is modified, and for the context required by calling the two-phase method after the execution of the try phase is completed or the context required by calling the cancelation phase method by the anomaly of the try phase, the context can be persisted into a saga registry record table (saga registry record table is a server side table and is mainly used for preventing hanging and idle rollback functions and context transfer). Because saga the two-phase commit and rollback of the transaction is a retry function, which is a two-phase method or rollback method that is invoked by an asynchronous thread pool, then at this point, because the traffic data in the threadLocal context is already emptied due to the thread switch, the traffic data needs to be persisted to the database before the thread switch, and read from the database and put back into the context after the thread switch. Such as the ID of the operational data used in the service, then the same is used in the two-phase and rollback procedure. Examples of the use are as follows:
SagaBusinessActionContextUtil.addContext ("service data key", "service data value");
SagaBusinessActionContextUtil is a saga context manipulation tool class that places business data into a context and persists to a saga registry record;
in this way, the SagaBusinessActionContextUtil. GetContext (). Get ("service data key") obtains service data values from the context. Both the Saga two-stage method execution and the rollback method execution utilize this approach for context transfer usage.
The embodiment of the specification improves the saga two-stage client model, and mainly comprises the following steps:
after saga a phase execution succeeds, a two-phase logic execution is performed at this time.
After one-stage execution is successful, first, local transaction commit is performed, if the local transaction commit fails, global transaction rollback operation is performed, if the local transaction commit is successful, the global transaction state is changed to the committed state and two-stage transaction commit is performed, meanwhile, whether the two-stage commit is configurable or not is controlled by a service, the flexibility of a framework is increased, and one-stage saga mode can be adapted, and no change is required for original service.
As shown in fig. 4, saga two-phase client execution logic is as follows:
1. and obtaining a branch transaction list, wherein the branch transaction list is registered in the branch transaction list in a saga-stage try.
2. The branch transaction list judges whether the branch transaction list is empty, if the branch transaction list is empty, the global transaction is not started, the logic of the branch transaction list is a local call, and then the global transaction state is updated to be a two-stage submitted state, and the global transaction is completed.
3. If the branch transaction list is not empty, indicating that there is callout logic for this global transaction, the loop reflection call saga two-phase method is required.
4. And when saga the two-stage reflection call is successful, updating the global transaction state in the global transaction table to be a two-stage submitted state, and ending the global transaction. The global transaction commit node is the active global transaction node, i.e., the master resource manager.
5. When saga two-stage reflection call has branch transaction execution failure, updating the global transaction state to be a failed retried state, wherein the global transaction is unsuccessful, and scanning the global transaction with the failed retried state in the global transaction table through an asynchronous thread timing task.
6. The scanning task is executed once every 5s, a branch transaction list corresponding to the global transaction meeting the conditions is queried out, and branch transactions which are not in a two-stage submitted state are filtered out, and a two-stage method of saga is performed by callout (rpc/feign callout).
7. If the reflection outer regulating two-stage method is successful, updating the global transaction state to be a two-stage submitted state, and ending the global transaction;
8. If the retry saga stages reflect the external call for 5 times (the retry times are configurable), the branch transaction stage does not call successfully, updates the global transaction state as failure, and is manually accessed.
The embodiment saga of the present description relates to idempotent implementation, i.e., two-stage resubmission cannot be performed when the saga two-stage method is executed asynchronously. Also involved is nested transaction saga two-phase commit.
Nested transactions refer to branch transactions that also need to execute callout logic, e.g., global transactions are deposit services, a master resource manager needs to invoke loan services in execution, branch transactions of loan services are split, branch transactions of loan services are executed from a resource manager, and integrated services need to be invoked in execution, where the integrated services belong to nested invocations.
Specifically, according to one embodiment of the present disclosure, as shown in fig. 5, when the master resource manager invokes the slave resource manager to execute the branch transaction, the method further includes:
step 501, the slave resource manager judges whether the branch transaction executed by the slave resource manager needs to execute the callout logic;
If yes, the slave resource manager splits the branch transaction into at least one sub-branch transaction, and invokes at least one idle slave resource manager of the global transaction to execute the sub-branch transaction, the slave resource manager receives the execution result of the corresponding sub-branch transaction returned by the slave resource manager, and returns the execution result of the branch transaction to the master resource manager according to the execution result of each sub-branch transaction.
In the embodiment of the present specification, first, when executing a branch transaction from the resource manager, it is determined whether there is a global transaction id in the context, and whether there is a global transaction on the branch transaction callout method, that is, whether there is a global transaction annotation (@ ApSagaGlobal), and if so, a nested transaction is started. If the nested transaction has been opened, then the sub-branch transaction needs to be split from the resource manager and stored in the sub-branch transaction list, the loop-out performs a two-phase approach, with overall logic consistent with the saga-phase client logic described above. The logic flow is shown in FIG. 6 as follows:
the saga two-stage service end execution logic is as follows:
1. the transaction branch receives saga the two-phase execution request (from the resource manager) and opens the local transaction.
2. Whether nested transactions are open is queried, whether there is a global transaction id in the context, and whether an open global transaction annotation is added.
3. If a global transaction is started, then the branch transaction state in the saga registry record is updated to a two-phase committed state, and the node is invoked in a loop to start the branch transaction list, the logic of which is the same as the saga-phase client execution flow described above, and the local transaction is ended after the invocation is successful. At this point, the slave resource manager performs the TC service, responsible for maintaining the state of the nested global transaction among the branch transactions it executes and the branch transactions in the nested global transaction.
4. If the global transaction is not started in the branch transaction, first, whether the two-stage committed state is judged.
5. If the two-stage submitted state is the two-stage submitted state, the response result of the previous two-stage execution is returned to play a role in preventing the duplicate.
6. If the branch transaction is not a two-phase committed state, then two-phase business logic is executed and the response result is written saga into the registry record table, ending the local transaction.
The saga two-stage service end is provided with a service expansion interface, the expansion interface is added before the execution of the two-stage local transaction, after the local transaction and before the local transaction, and after the local transaction, the service can realize own logic in the interface. Such as to effect release of the distributed lock after completion of the two-phase execution.
In the embodiment of the present disclosure, the master resource manager may also fail, and since the global transaction state in the global transaction table is maintained by the master resource manager, if the master resource manager fails, the global transaction state cannot be updated to be the global transaction execution failure caused by the failure of the master resource manager, and the failed master resource manager cannot notify each slave resource manager of the self-failure message, so that the global transaction cannot continue to be processed.
In view of the above, according to one embodiment of the present disclosure, as shown in fig. 7, the method further includes:
Step 701, each slave resource manager executes each timing task to asynchronously inquire the global transaction state in the global transaction table;
step 702, judging whether the global transaction state is overtime and not updated;
And 703, if so, determining that the global transaction state is overtime and the slave resource manager is not updated as the master resource manager, and rolling back the global transaction.
In the embodiment of the specification, each slave resource manager queries the global transaction state in the global transaction table through an asynchronous timing thread, and if the global transaction state is overtime and not updated, the master resource manager is considered to have a fault, so that the slave resource manager which is determined that the global transaction state is overtime and not updated is used as the master resource manager, the TC service is operated, and rollback of the global transaction is carried out, thereby solving the problem of execution failure of the global transaction.
In the embodiment of the present disclosure, a plurality of slave resource managers may negotiate to elect one resource manager as a master resource manager, and each slave resource manager may vote on a load condition, and elect the slave resource manager with the lowest load as the master resource manager.
According to some other embodiments of the present description, as shown in fig. 8, each slave resource manager performing a respective timed task asynchronously querying the global transaction state in the global transaction table comprises:
step 801, the slave resource manager executes self timing task to obtain the query lock of the global transaction state in the global transaction table;
Step 802, judging whether the query lock is acquired;
803, if the query lock is obtained, executing the step of querying the global transaction state;
Step 804, judging whether the global transaction state is overtime and not updated;
step 8041, if the global transaction state is not updated due to overtime, releasing the query lock;
Step 8042, if the global transaction state is overtime and not updated, releasing the query lock after taking the global transaction state as the master resource manager;
Step 805, if the query lock is not obtained, ending the timing task, and executing the next timing task to obtain the query lock after the next timing time arrives.
In the embodiment of the present disclosure, the global transaction state in the global transaction table only supports asynchronous query, that is, the resource manager needs to acquire the query lock first, then query the global transaction state, and release the query lock after query, so that other resource managers acquire the query lock to query the global transaction state. Therefore, in this embodiment of the present disclosure, each slave resource manager has its own timing task, after the timing time arrives, the timing task execution script obtains the query lock of the global transaction state, if the query lock is obtained, queries the global transaction state, and determines whether the global transaction state is not updated due to timeout, if the global transaction state is not updated due to timeout, then after taking itself as the master resource manager, releases the query lock, and if the query lock is not updated due to timeout, releases the query lock. If the query lock is not acquired, ending the local timing task, and executing the next timing task to acquire the query lock after the next timing time arrives.
Thus, when the original master resource manager fails, the global transaction state will appear as a timeout un-updated, which will be discovered by the timing task of the slave resource manager, and the slave resource manager that has the global transaction state appearing as a timeout un-updated is discovered first as the master resource manager. The re-determined master resource manager then rolls back the global transaction, specifically the master resource manager rolls back the global transaction comprising:
And the master resource manager determines a branch transaction table associated with the global transaction table, and calls the slave resource manager corresponding to each branch transaction to re-execute each branch transaction according to the branch transaction table.
Based on the same inventive concept, the embodiments of the present specification also provide a distributed transaction processing system, where the system includes a plurality of resource managers executing business logic;
The plurality of resource managers perform the methods of the embodiments of the present description when processing global transactions sent by clients.
Fig. 9 is a schematic structural diagram of a computer device according to an embodiment of the present disclosure, and the method in the embodiment of the present disclosure may be applied to the computer device of the present disclosure.
In particular, as shown in fig. 9, the computer device 902 may include one or more processing devices 904, such as one or more Central Processing Units (CPUs), each of which may implement one or more hardware threads. The computer device 902 may also include any storage resources 906 for storing any kind of information, such as code, settings, data, etc. By way of non-limiting example, the storage resources 906 may include any one or more combinations of any type of RAM, any type of ROM, flash memory devices, hard disks, optical disks, and the like. More generally, any storage resource may store information using any technology.
Further, any storage resource may provide volatile or non-volatile retention of information.
Further, any storage resources may represent fixed or removable components of computer device 902. In one case, the computer device 902 may perform any of the operations of the associated instructions when the processing device 904 executes the associated instructions stored in any storage resource or combination of storage resources. The computer device 902 also includes one or more drive systems 908, such as a hard disk drive system, optical disk drive system, and the like, for interacting with any storage resources.
The computer device 902 may also include an input/output module 910 (I/O) for receiving various inputs (via an input device 912) and for providing various outputs (via an output device 914). One particular output mechanism may include a presentation device 916 and an associated Graphical User Interface (GUI) 918. In other embodiments, input/output module 910 (I/O), input device 912, and output device 914 may not be included, but merely as a computer device in a network. The computer device 902 may also include one or more network interfaces 920 for exchanging data with other devices via one or more communication links 922. One or more communication buses 924 couple the above-described components together.
The communication link 922 may be implemented in any manner, for example, through a local area network, a wide area network (e.g., the internet), a point-to-point connection, etc., or any combination thereof. Communication link 922 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.
The present description embodiment also provides a computer-readable storage medium storing a computer program which, when executed by a processor, implements the above-described method.
The present description also provides computer-readable instructions, wherein the program therein causes a processor to perform the above-described method when the processor executes the instructions.
It should be understood that, in various embodiments of the present disclosure, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation of the embodiments of the present disclosure.
It should also be understood that, in the embodiments of the present specification, the term "and/or" is merely one association relationship describing the association object, meaning that three relationships may exist. For example, A and/or B may mean that A alone, both A and B, and B alone are present. In the embodiment of the present specification, the character "/", generally indicates that the front and rear associated objects are in an "or" relationship.
Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the various illustrative elements and steps have been described above generally in terms of function in order to best explain the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments herein.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.
In the several embodiments provided in the embodiments of this specification, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. In addition, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices, or elements, or may be an electrical, mechanical, or other form of connection.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purposes of the embodiments of the present description.
In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the embodiments of the present specification is essentially or a part contributing to the prior art, or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in the embodiments of the present specification. The storage medium includes a U disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, an optical disk, or other various media capable of storing program codes.
The principles and implementations of the embodiments of the present invention are described in the embodiments of the present invention, and the above description of the embodiments is only for aiding in understanding the methods and core ideas of the embodiments of the present invention, and meanwhile, those skilled in the art will change in terms of the ideas of the embodiments of the present invention, and in light of the foregoing description, the present invention should not be construed as limiting the embodiments of the present invention.
Claims (17)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411218979.XA CN119322658A (en) | 2024-09-02 | 2024-09-02 | Distributed transaction processing method, system, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411218979.XA CN119322658A (en) | 2024-09-02 | 2024-09-02 | Distributed transaction processing method, system, equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN119322658A true CN119322658A (en) | 2025-01-17 |
Family
ID=94228216
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202411218979.XA Pending CN119322658A (en) | 2024-09-02 | 2024-09-02 | Distributed transaction processing method, system, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN119322658A (en) |
-
2024
- 2024-09-02 CN CN202411218979.XA patent/CN119322658A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10942823B2 (en) | Transaction processing system, recovery subsystem and method for operating a recovery subsystem | |
| WO2018103318A1 (en) | Distributed transaction handling method and system | |
| CN109739935B (en) | Data reading method and device, electronic equipment and storage medium | |
| US9417977B2 (en) | Distributed transactional recovery system and method | |
| US7640249B2 (en) | System and method for transactional session management | |
| JP3582963B2 (en) | Transaction processing method and system | |
| JP5841177B2 (en) | Method and system for synchronization mechanism in multi-server reservation system | |
| CN112925614B (en) | Distributed transaction processing method, device, medium and equipment | |
| US9417906B2 (en) | Transaction participant registration with caveats | |
| US20030005172A1 (en) | Apparatus, method and computer program product for client/server computing with improved correspondence between transaction identifiers when supporting subordinate resource manager(s) | |
| US20040158549A1 (en) | Method and apparatus for online transaction processing | |
| US6381617B1 (en) | Multiple database client transparency system and method therefor | |
| US11681683B2 (en) | Transaction compensation for single phase resources | |
| EP2194495B1 (en) | A transaction aware, flexible interface for a state correlation and transition execution engine | |
| US6785722B2 (en) | Apparatus, methods, and computer program products for transactional support of network management operations | |
| US6389431B1 (en) | Message-efficient client transparency system and method therefor | |
| WO2003093987A1 (en) | Plug-in configuration manager | |
| WO2023082992A1 (en) | Data processing method and system | |
| CN112148436A (en) | Decentralized TCC (transmission control protocol) transaction management method, device, equipment and system | |
| CN112632093B (en) | Work order processing method, device, system, storage medium and program product | |
| JP3548030B2 (en) | Server processing apparatus and server processing method | |
| US6256641B1 (en) | Client transparency system and method therefor | |
| CN114356596A (en) | Message processing method and device for distributed system | |
| CN114138504A (en) | Data processing method, device, device and storage medium for multiple registration centers | |
| CN119322658A (en) | Distributed transaction processing method, system, equipment and storage medium |
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 |