Distributed transaction processing method, system and equipment and storage medium

Abstract

The invention relates to a distributed transaction processing method, system and device and a storage medium. Comprising the steps that when a global transaction sent by a client side is received, one resource manager is determined from a plurality of resource managers executing service logic to serve as a main resource manager, and other resource managers serve as slave resource managers; the master resource manager splits the global transaction into at least one branch transaction when the global transaction needs to execute the export logic, and calls at least one slave resource manager to execute the branch transaction; the master resource manager receives an execution result of the corresponding branch transaction returned by the slave resource manager; and the main resource manager submits or rolls back the global transaction according to the execution result of each branch transaction. Through the embodiment of the invention, distributed transaction processing of decentralized service is realized, a method for maintaining the states of global and branch transactions by a fixed transaction coordinator is abandoned, and a single-point fault problem is avoided.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of distributed processing technology, and more particularly to a distributed transaction processing method, system, device, and storage medium. Background Art

[0002] The problem with the existing TCC (Try-Confirm-Cancel) technical solution is that a transaction coordinator, namely the seata service (TC), is required. Its role is global transaction management and is 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 are executed in the correct order and eventually reach a consistent state. The protocol control of the two-phase commit includes two stages: pre-commit (try) and commit / rollback (confirm / rollback). 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 failure), the entire global transaction operation will be unavailable, affecting the transaction processing of the distributed system.

[0003] How to improve the stability of distributed systems is a technical problem that needs to be solved urgently. Summary of the invention

[0004] In order to solve the problem of single point failure in the existing TCC technical solution, which makes the entire global transaction operation unavailable and responds to the transaction processing problem of the distributed system, the embodiments of this specification provide a distributed transaction processing method, system, device and storage medium, which realizes distributed transaction processing of decentralized services, abandons the method of maintaining the status of global and branch transactions by a fixed transaction coordinator, and eliminates the single point failure problem.

[0005] The specific technical solutions of the embodiments of this specification are as follows:

[0006] On the one hand, an embodiment of this specification provides a method for processing a distributed transaction, the method comprising:

[0007] When receiving a global transaction sent by a client, a resource manager is determined from multiple resource managers that execute business logic as the master resource manager of the global transaction, and other resource managers are slave resource managers of the global transaction;

[0008] When the global transaction needs to execute external call 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;

[0009] The master resource manager receives the execution result of the corresponding branch transaction returned by the slave resource manager;

[0010] The main resource manager commits or rolls back the global transaction according to the execution results of each branch transaction.

[0011] Furthermore, after the main resource manager splits the global transaction into at least one branch transaction, the method further includes:

[0012] The master resource manager executes at least one branch transaction.

[0013] Furthermore, before the master resource manager calls at least one slave resource manager to execute the branch transaction, the method further includes:

[0014] The main resource manager determines a commit mode of the branch transaction according to the configuration information, wherein the commit mode is a one-phase commit or a two-phase commit;

[0015] The master resource manager calling at least one slave resource manager to execute the branch transaction further comprises:

[0016] The resource manager calls the slave resource manager to execute the branch transaction according to the submission mode.

[0017] Furthermore, when the master resource manager calls the slave resource manager to execute the branch transaction, the method further includes:

[0018] The slave resource manager determines whether the branch transaction executed by it needs to execute external call logic;

[0019] If so, the slave resource manager splits the branch transaction into at least one sub-branch transaction, and calls 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 it called, and returns the execution result of its own branch transaction to the master resource manager based on the execution results of each sub-branch transaction.

[0020] Furthermore, after determining the primary resource manager, the method further includes:

[0021] The master resource manager creates a global transaction ID of the global transaction and binds the global transaction ID to a thread 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.

[0022] Furthermore, the method further comprises:

[0023] 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.

[0024] Furthermore, the global transaction information includes a global transaction state.

[0025] Furthermore, the method further comprises:

[0026] Each slave resource manager executes its own scheduled task to asynchronously query the global transaction status in the global transaction table, and determines whether the global transaction status has timed out and has not been updated. If so, the slave resource manager whose global transaction status has timed out and has not been updated is determined as the master resource manager to roll back the global transaction.

[0027] Further, each slave resource manager executes its own scheduled task to asynchronously query the global transaction status in the global transaction table, including:

[0028] The slave resource manager executes its own scheduled task to obtain a query lock of the global transaction state in the global transaction table;

[0029] If the query lock is acquired, the steps of querying the global transaction status and determining whether the global transaction status has timed out and has not been updated are executed;

[0030] If the global transaction status has not timed out and has not been updated, releasing the query lock;

[0031] If the global transaction state times out and is not updated, the query lock is released after the system serves as the primary resource manager;

[0032] If the query lock is not obtained, the current scheduled task is terminated, and the next scheduled task is executed to obtain the query lock after the next scheduled time arrives.

[0033] Furthermore, the branch transaction information includes a correspondence between each branch transaction and a corresponding slave resource manager.

[0034] Furthermore, the step of the primary resource manager rolling back the global transaction includes:

[0035] The master resource manager determines a branch transaction table associated with the global transaction table, and calls a slave resource manager corresponding to each branch transaction according to the branch transaction table to re-execute each branch transaction.

[0036] Further, determining a resource manager as a primary resource manager from a plurality of resource managers executing business logics includes:

[0037] The resource manager that receives the global transaction serves as the master resource manager.

[0038] Further, the main resource manager splitting the global transaction into at least one branch transaction includes:

[0039] The main resource manager splits the global transaction into branch transactions corresponding to at least one service type in the global transaction.

[0040] On the other hand, an embodiment of this specification also provides a distributed transaction processing system, the system comprising a plurality of resource managers that execute business logic;

[0041] Multiple resource managers execute the above method when processing global transactions sent by clients.

[0042] On the other hand, an embodiment of the present specification further provides a computer device, including a memory, a processor, and a computer program stored in the memory, and the processor implements the above method when executing the computer program.

[0043] On the other hand, an embodiment of the present specification further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program implements the above method when executed by a processor.

[0044] Finally, the embodiments of this specification also provide a computer program product, wherein the computer program product includes a computer program, and the computer program implements the above method when executed by a processor.

[0045] Using the embodiments of this specification, the transaction coordinator is abandoned. Instead, when a global transaction sent by a client is received, a resource manager is determined from multiple resource managers that execute business logic as the main resource manager of the global transaction, and the main resource manager executes the TC service of the original transaction coordinator, that is, when the global transaction needs to execute external call 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, and then the main resource manager receives the execution result of the response branch transaction returned by the slave resource manager, and finally the main resource manager commits or rolls back the global transaction according to the execution result of each branch transaction. The method of the embodiments of this specification realizes the processing of decentralized distributed transactions, avoids the occurrence of single point failure problems, and compared with the traditional TCC implementation method, the branch transaction and global transaction registration of the embodiments of this specification do not need external call, which reduces the external call communication time. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0047] Figure 1 The figure shows a schematic diagram of the structure of a distributed transaction processing method implementation system in the embodiment of this specification;

[0048] Figure 2 The figure is a flow chart of a method for processing a distributed transaction according to an embodiment of the present specification;

[0049] Figure 3 The figure is a schematic diagram of the process of configuring the submission method of the branch transaction in the embodiment of this specification;

[0050] Figure 4 The figure is a flow chart of the client execution logic of the second stage of saga in the embodiment of this specification;

[0051] Figure 5 It is a schematic diagram of the process of nested calling from the resource manager in the embodiment of this specification;

[0052] Figure 6 The figure is a flow chart of the execution logic of the saga second-stage server when there is a nested call in the embodiment of this specification;

[0053] Figure 7 The figure is a schematic diagram of a process of determining a global transaction rollback when a primary resource manager fails in an embodiment of the present specification;

[0054] Figure 8 It is a schematic diagram of a process in which each slave resource manager executes its own scheduled task and asynchronously queries the global transaction status in the global transaction table in an embodiment of this specification;

[0055] Fig. 9 The figure is a schematic diagram of the structure of a computer device in an embodiment of the present specification.

[0056]

Description of reference numerals

[0057] 101. Client;

[0058] 102. Distributed systems;

[0059] 1021. Resource manager;

[0060] 902. Computer equipment;

[0061] 904. Processing equipment;

[0062] 906. Storage resources;

[0063] 908, drive system;

[0064] 910, input / output module;

[0065] 912. Input device;

[0066] 914. Output device;

[0067] 916. Presentation equipment;

[0068] 918. Graphical user interface;

[0069] 920, network interface;

[0070] 922, communication link;

[0071] 924. Communication bus. DETAILED DESCRIPTION

[0072] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on the embodiments in the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the embodiments of this specification.

[0073] It should be noted that the terms "first", "second", etc. in the description and claims of the embodiments of this specification and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the embodiments of this specification described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, device, product or equipment that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0074] It should be noted that the acquisition, storage, use, and processing of data in the technical solutions of the embodiments of this specification comply with the relevant provisions of national laws and regulations.

[0075] It should be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of this application, but it does not mean that the applicant has or will necessarily use the solution.

[0076] like Figure 1 The figure shows a structural diagram of a distributed transaction processing method implementation system in an embodiment of the present specification, including a client 101 and a distributed system 102. The distributed system 102 includes multiple resource managers 1021 that execute business logic. It can be understood that the resource manager 1021 is a processing node in the distributed system 102 and has business processing capabilities.

[0077] Alternatively, the resource manager 1021 may be a computer, and the distributed system 102 may include a plurality of computers interconnected by a network and operating as a distributed processing system.

[0078] In addition, it should be noted that Figure 1 What is shown is only one application environment provided by the embodiment of this specification. In actual application, other application environments may also be included, and this specification does not limit it.

[0079] In the existing TCC solution, a separate transaction coordinator TC needs to be deployed. The transaction coordinator TC executes the seata (TC) service. All transactions sent by clients (that is, services, such as banking services sent by users through online banking or mobile banking clients) need to be managed by the transaction coordinator TC for global transaction management, and coordinate at least one resource manager 1021 for processing. Its submission methods include one-phase submission and two-phase submission. The transaction coordinator TC is responsible for the one-phase submission or rollback and two-phase submission or rollback of global transactions.

[0080] If the transaction coordinator TC fails, all transactions will not be processed normally, causing a great impact.

[0081] In response to the above problems, the embodiments of this specification provide a method for processing distributed transactions, which implements distributed transaction processing of decentralized services, abandons the method of maintaining the status of global and branch transactions by a fixed transaction coordinator, and has no single point failure problem.

[0082] Figure 2 The flowchart of the method for processing distributed transactions in the embodiment of this specification is shown. The process of processing global transactions is described in this figure. The order of steps listed in the embodiment is only one way of executing the order of many steps, and does not represent the only execution order. When the system or device product is executed in practice, it can be executed in the order of the method shown in the embodiment or the accompanying drawings or in parallel.

[0083] Specifically, as shown in the figure, the method may include:

[0084] Step 201: when a global transaction sent by a client is received, a resource manager is determined from multiple resource managers that execute business logic as the master resource manager of the global transaction, and other resource managers are slave resource managers of the global transaction;

[0085] Step 202: When the global transaction needs to execute external call 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;

[0086] Step 203: the master resource manager receives the execution result of the corresponding branch transaction returned by the slave resource manager;

[0087] Step 204: The main resource manager commits or rolls back the global transaction according to the execution results of each branch transaction.

[0088] Using the embodiments of this specification, the transaction coordinator is abandoned. Instead, when a global transaction sent by a client is received, a resource manager is determined from multiple resource managers that execute business logic as the main resource manager of the global transaction, and the main resource manager executes the TC service of the original transaction coordinator, that is, when the global transaction needs to execute external call 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, and then the main resource manager receives the execution result of the response branch transaction returned by the slave resource manager, and finally the main resource manager commits or rolls back the global transaction according to the execution result of each branch transaction. The method of the embodiments of this specification realizes the processing of decentralized distributed transactions, avoids the occurrence of single point failure problems, and compared with the traditional TCC implementation method, the branch transaction and global transaction registration of the embodiments of this specification do not need external call, which reduces the external call communication time.

[0089] In the embodiments of this specification, a load balancer may be deployed in a distributed system, and the load balancer may distribute the global transaction sent by the client to a resource manager according to the load of each resource manager. The resource manager that receives the global transaction may be the master resource manager of the global transaction and execute the TC service. Other resource managers are slave resource managers of the global transaction.

[0090] The master resource manager generates a global transaction ID for the global transaction, and then writes the global transaction ID and other global transaction information into the global transaction table. The global transaction information may also include the global transaction status (start, committing, committed, rolling back, rolled back, two-phase commit, two-phase committed, etc.), transaction timeout, global transaction name, transaction start time, etc. The master resource manager executes TC services, maintains the status of global and branch transactions, coordinates global transaction commit or rollback, and is responsible for updating the global transaction status and other information of the global transaction in the global transaction table.

[0091] When a global transaction needs to execute external call logic (such as RPC external call or feign external call), the main resource manager splits the global transaction into at least one branch transaction. Specifically, the global transaction can be split into branch transactions corresponding to at least one service type in the global transaction, such as deposit service, loan service, comprehensive service, etc.

[0092] Optionally, each service type corresponds to a branch transaction, and the master resource manager calls slave resource managers corresponding to the number of branch transactions to execute these branch transactions.

[0093] In addition, because the main resource manager also has the ability to execute business logic, the main resource manager can also execute at least one branch transaction and send the execution result of the branch transaction to the TC service running on itself.

[0094] Normally, the execution results of each branch transaction are successful, but there may be execution failures. The master resource manager determines whether the execution results of each branch transaction are successful. If so, the global transaction is committed. If a branch transaction is not executed successfully, it is rolled back and the slave resource managers are instructed to re-execute the corresponding branch transaction.

[0095] The main resource manager also writes the branch transaction information into the branch transaction table. The branch transaction information may include the branch transaction ID, branch transaction status, branch transaction timeout, branch transaction name, application name and called class name, try phase method name, rollback method name, unit information (for saga transactions under the unitized architecture), request type (used to distinguish between rpc external call or feign external call), the correspondence between branch transactions and slave resource managers, etc.

[0096] According to one embodiment of the present specification, the step of the primary resource manager rolling back the global transaction includes:

[0097] The master resource manager determines a branch transaction table associated with the global transaction table, and calls a slave resource manager corresponding to each branch transaction according to the branch transaction table to re-execute each branch transaction.

[0098] In the embodiments of this specification, multiple containers can be deployed on each resource manager, and each container has business logic processing capabilities. The main resource manager can execute TC services on an idle container. A branch transaction includes multiple computing tasks, and multiple computing tasks can be executed by multiple containers of the resource manager, which is not limited in the embodiments of this specification.

[0099] Therefore, in addition to executing the TC service of the global transaction, the master resource manager can also serve as a slave resource manager of other global transactions to execute branch transactions of other global transactions.

[0100] According to an embodiment of the present specification, in order to optimize the processing flow of branch transactions, after determining the primary resource manager, the method further includes:

[0101] 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.

[0102] It can be understood that the global transaction ID is bound to the threadlocal context, and the branch transaction processing can obtain the global transaction ID from the context without passing parameters.

[0103] In the embodiments of this specification, the commit mode of the branch transaction may include one-phase commit and two-phase commit. In order to improve the flexibility of the branch transaction commit, according to an embodiment of this specification, Figure 3 As shown, before the master resource manager calls at least one slave resource manager to execute the branch transaction, the method further includes:

[0104] Step 301: The main resource manager determines the commit mode of the branch transaction according to the configuration information, and the commit mode is one-phase commit or two-phase commit;

[0105] The master resource manager calling at least one slave resource manager to execute the branch transaction further comprises:

[0106] Step 302: The resource manager calls the slave resource manager to execute the branch transaction according to the commit mode.

[0107] In the embodiments of this specification, the configuration information can be configured by banking personnel according to actual business, and instruct the submission method (one-phase submission or two-phase submission) of branch transactions under each global transaction.

[0108] On this basis, the embodiment of this specification adds a second-phase method name in the second phase of saga. The default format is {class name.method name}, which is used to locate the method executed in the second phase after the first phase is completed. The branch transaction annotation @ApSagaBranch adds the second-phase method attribute apTwoCommitMethod. At the same time, the second-phase execution type is added to distinguish whether it is a try phase call, a rollback phase call, or a second-phase confirm call.

[0109] The embodiments of this specification modify the server side of the try phase. For the context required to call the second phase method after the try phase is executed, or the context required to call the cancel phase method due to an exception in the try phase, the context can be persisted in the saga registration table record table in the try phase (the saga registration table record table is a server-side table, mainly used for anti-hanging and empty rollback functions and context transfer). Because the second-phase commit and rollback of the saga transaction have a retry function, and the retry is to call the second-phase method or rollback method through the asynchronous thread pool, then at this time, due to the thread switching, the business data in the threadLocal context has been cleared, and the business data needs to be persisted to the database before the thread switching, and then read from the database after the thread switching and put back into the context. For example, if the ID of the operation data is used in the business, it is also used in the second phase and rollback process. The usage example is as follows:

[0110] SagaBusinessActionContextUtil.addContext("business data key", "business data value");

[0111] SagaBusinessActionContextUtil is a saga context operation tool class that puts business data into the context and persists it into the saga registration table record table;

[0112] Use this method to get the business data value from the context using SagaBusinessActionContextUtil.getContext().get("business data key"). Both Saga two-phase method execution and rollback method execution use this method for context transfer.

[0113] The embodiment of this specification enhances and transforms the saga second-stage client model, mainly including the following:

[0114] When the first phase of saga is successfully executed, the second phase of logic is executed.

[0115] After the first phase is successfully executed, the local transaction is committed first. If the local transaction fails to be committed, the global transaction is rolled back. If the local transaction is successfully committed, the global transaction status is changed to the committed status and the second phase transaction is committed. At the same time, the second phase commit is configurable, and whether to commit can be controlled by the business, which increases the flexibility of the framework and can adapt to the first phase saga mode. No changes are required for the original service.

[0116] like Figure 4 As shown, the client execution logic of the second phase of saga is as follows:

[0117] 1. Get the branch transaction list, the branch transaction list registered by the try in the first phase of saga, and the branch transaction list is registered in the branch transaction table.

[0118] 2. Check whether the branch transaction list is empty. If it is empty, it means that this global transaction has not opened a branch transaction, and its logic is all local calls. Then update the global transaction status to the second-stage committed status, indicating that the global transaction has been completed.

[0119] 3. If the branch transaction list is not empty, it indicates that this global transaction has external call logic and needs to call the saga second-phase method in a loop.

[0120] 4. When the second phase of saga reflection call succeeds, the global transaction status in the global transaction table is updated to the second phase committed status, and the global transaction ends. The global transaction commit node is the node that starts the global transaction, that is, the main resource manager.

[0121] 5. When a branch transaction fails to execute in the second phase of saga reflection call, the global transaction status is updated to a failed retry state. At this time, the global transaction is not successful. The asynchronous thread timing task scans the global transaction table for global transactions with a failed retry state.

[0122] 6. The scanning task is executed every 5 seconds. The branch transaction list corresponding to the global transaction that meets the above conditions is queried, and the branch transactions that are not in the second-stage submitted state are filtered out. The external call (rpc / feign external call) saga second-stage method is used.

[0123] 7. If the reflective outbound call method succeeds in the second phase, the global transaction status is updated to the second phase committed status, and the global transaction ends;

[0124] 8. If the second phase of the branch transaction fails to be called successfully after the saga second phase reflective external call is retried 5 times (the number of retries is configurable), the global transaction status is updated to failure and manual access is required.

[0125] The embodiment of this specification enhances and transforms the saga two-stage server model, involves idempotent implementation, that is, when the saga two-stage method is executed asynchronously, the two-stage repeated submission cannot be performed. It also involves nested transaction saga two-stage submission.

[0126] Nested transactions mean that branch transactions also need to execute external call logic. For example, the global transaction is a deposit service. During execution, the main resource manager needs to call the loan service, split out the branch transaction of the loan service, and execute the branch transaction of the loan service from the resource manager. During execution, the comprehensive service also needs to be called. In this case, the comprehensive service is a nested call.

[0127] Specifically, according to one embodiment of this specification, Figure 5 As shown, when the master resource manager calls the slave resource manager to execute the branch transaction, the method further includes:

[0128] Step 501: The slave resource manager determines whether the branch transaction executed by it needs to execute external call logic;

[0129] Step 502: If so, the slave resource manager splits the branch transaction into at least one sub-branch transaction, and calls 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 it called, and returns the execution result of its own branch transaction to the master resource manager according to the execution results of each sub-branch transaction.

[0130] In the embodiment of this specification, when executing a branch transaction from the resource manager, first determine whether there is a global transaction id in the context, and whether a global transaction is opened on the branch transaction external call method, that is, whether there is a global transaction annotation (@ApSagaGlobal). If so, open a nested transaction. If a nested transaction has been opened, then the slave resource manager needs to split the sub-branch transaction and store it in the sub-branch transaction list, and loop the external call to execute the two-stage method. The overall logic is consistent with the above-mentioned saga two-stage client logic. The logical flow is as follows Figure 6 As shown:

[0131] The execution logic of the saga second-stage server is as follows:

[0132] 1. The transaction branch receives the saga second-phase execution request (from the resource manager) and starts a local transaction.

[0133] 2. Check whether nested transactions are enabled by checking whether there is a global transaction id in the context and whether the annotation for enabling global transactions is added.

[0134] 3. If the global transaction is enabled, the branch transaction status in the saga registration table is updated to the second-stage committed status, and this node is called cyclically to enable the branch transaction list. Its logic is the same as the above-mentioned saga second-stage client execution process. After the call is successful, the local transaction is terminated. At this time, the slave resource manager executes the TC service and is responsible for maintaining the status of the global transaction nested in the branch transaction it executes and the branch transaction in the nested global transaction.

[0135] 4. If the global transaction is not opened in the branch transaction, first determine whether it is in the second-stage committed state.

[0136] 5. If the second phase is submitted, the previous second phase execution response result is returned to prevent duplication.

[0137] 6. If the branch transaction is not in the second-phase committed state, the second-phase business logic is executed, and the response result is written into the saga registration table record table to end the local transaction.

[0138] The second phase of saga server adds a business extension interface, which is added before and after the execution of the second phase local transaction, and before and after the local transaction. The business can implement its own logic in the interface. For example, the distributed lock is released after the second phase execution is completed.

[0139] In the embodiments of the present specification, the master resource manager may also fail. Since the global transaction status in the global transaction table is maintained by the master resource manager, if the master resource manager fails, the global transaction status cannot be updated to indicate that the global transaction execution failed due to the failure of the master resource manager. Moreover, the failed master resource manager cannot notify the slave resource managers of its own failure, so the global transaction cannot continue to be processed.

[0140] In view of the above situation, according to an embodiment of this specification, as Figure 7 As shown, the method also includes:

[0141] Step 701: Each slave resource manager executes its own scheduled task to asynchronously query the global transaction status in the global transaction table;

[0142] Step 702: Determine whether the global transaction state has timed out and has not been updated;

[0143] Step 703: If yes, the slave resource manager that determines that the global transaction state has timed out and has not been updated is used as the master resource manager to roll back the global transaction.

[0144] In the embodiments of the present specification, each slave resource manager queries the global transaction status in the global transaction table through an asynchronous timing thread. If the global transaction status times out and is not updated, it is considered that the master resource manager has a fault. Therefore, the slave resource manager whose global transaction status times out and is not updated is determined as the master resource manager, runs the TC service, and rolls back the global transaction, thereby solving the problem of global transaction execution failure.

[0145] In the embodiment of the present specification, a plurality of slave resource managers may negotiate to elect a resource manager as the master resource manager, and each slave resource manager may vote on the load situation to elect the slave resource manager with the lowest load as the master resource manager.

[0146] According to some other embodiments of this specification, such as Figure 8 As shown, each slave resource manager executes its own scheduled task to asynchronously query the global transaction status in the global transaction table, including:

[0147] Step 801: the slave resource manager executes its own scheduled task to obtain a query lock of the global transaction state in the global transaction table;

[0148] Step 802: Determine whether the query lock is acquired;

[0149] Step 803: If the query lock is acquired, the step of querying the global transaction status is executed;

[0150] Step 804: Determine whether the global transaction status has timed out and has not been updated;

[0151] Step 8041: If the global transaction status has not timed out and has not been updated, releasing the query lock;

[0152] Step 8042: If the global transaction state times out and is not updated, then after the resource manager itself is used as the primary resource manager, the query lock is released;

[0153] Step 805: If the query lock is not obtained, then the current scheduled task is terminated, and after the next scheduled time arrives, the next scheduled task is executed to obtain the query lock.

[0154] In the embodiments of the present specification, the global transaction status in the global transaction table only supports asynchronous query, that is, the resource manager needs to first obtain the query lock, then query the global transaction status, and release the query lock after the query, so that other resource managers can obtain the query lock to query the global transaction status. Therefore, in the embodiments of the present specification, each slave resource manager has its own scheduled task. After the scheduled time arrives, the scheduled task executes the script to obtain the query lock of the global transaction status. If the query lock is obtained, the global transaction status is queried, and it is determined whether the global transaction status has timed out and not updated. If the global transaction status has timed out and not updated, the query lock is released after the resource manager is used as the master resource manager. If the query lock is not obtained, the local scheduled task is terminated, and the next scheduled task is executed to obtain the query lock after the next scheduled time arrives.

[0155] Therefore, when the original master resource manager fails, the global transaction status will time out and not be updated. This timeout will be discovered by the scheduled task of the slave resource manager. The slave resource manager that first discovers that the global transaction status has timed out and not been updated will be the master resource manager. Then the newly determined master resource manager rolls back the global transaction. Specifically, the steps of the master resource manager rolling back the global transaction include:

[0156] The master resource manager determines a branch transaction table associated with the global transaction table, and calls a slave resource manager corresponding to each branch transaction according to the branch transaction table to re-execute each branch transaction.

[0157] Based on the same inventive concept, the embodiment of this specification also provides a distributed transaction processing system, the system comprising a plurality of resource managers executing business logic;

[0158] When processing global transactions sent by clients, multiple resource managers execute the method of the embodiments of this specification.

[0159] like Fig. 9 The diagram is a schematic diagram of the structure of a computer device according to an embodiment of the present specification. The method according to the embodiment of the present specification can be applied to the computer device according to the embodiment.

[0160] Specifically, Fig. 9As shown, 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 resource 906, which is used to store any kind of information such as code, settings, data, etc. Without limitation, for example, the storage resource 906 may include any one or more combinations of the following: any type of RAM, any type of ROM, flash memory device, hard disk, optical disk, etc. More generally, any storage resource may use any technology to store information.

[0161] Further, any storage resource may provide volatile or non-volatile retention of information.

[0162] Further, any storage resource may represent a fixed or removable component of the computer device 902. In one case, when the processing device 904 executes the associated instructions stored in any storage resource or combination of storage resources, the computer device 902 may perform any operation of the associated instructions. The computer device 902 also includes one or more drive systems 908 for interacting with any storage resource, such as a hard disk drive system, an optical disk drive system, etc.

[0163] The computer device 902 may also include an input / output module 910 (I / O) for receiving various inputs (via input devices 912) and for providing various outputs (via output devices 914). A specific output mechanism may include a presentation device 916 and an associated graphical user interface (GUI) 918. In other embodiments, the input / output module 910 (I / O), the input device 912, and the output device 914 may not be included, and the computer device 902 may be used 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 components described above together.

[0164] 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. The 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.

[0165] The embodiments of the present specification also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program implements the above method when executed by a processor.

[0166] The embodiments of the present specification also provide a computer-readable instruction, wherein when a processor executes the instruction, the program therein causes the processor to execute the above method.

[0167] It should be understood that in the various embodiments of the present specification, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present specification.

[0168] It should also be understood that in the embodiments of this specification, the term "and / or" is only a description of the association relationship of the associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in the embodiments of this specification generally indicates that the associated objects before and after are in an "or" relationship.

[0169] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the embodiments of this specification can be implemented with electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiments of this specification.

[0170] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

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

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

[0173] In addition, each functional unit in each embodiment of the present specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0174] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of this specification is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the embodiment of this specification. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.

[0175] The embodiments of this specification use specific embodiments to illustrate the principles and implementation methods of the embodiments of this specification. The description of the above embodiments is only used to help understand the methods and core ideas of the embodiments of this specification. At the same time, for those skilled in the art, according to the ideas of the embodiments of this specification, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on the embodiments of this specification.

Claims

1. A distributed transaction processing method, characterized in that: The method comprises: When receiving a global transaction sent by a client, a resource manager is determined from multiple resource managers that execute business logic as the master resource manager of the global transaction, and other resource managers are slave resource managers of the global transaction; When the global transaction needs to execute external call 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; The main resource manager commits or rolls back the global transaction according to the execution results of each branch transaction.

2. The method according to claim 1, characterized in that After the main resource manager splits the global transaction into at least one branch transaction, the method further includes: The master resource manager executes at least one branch transaction.

3. The method according to claim 1, characterized in that Before the master resource manager calls at least one slave resource manager to execute the branch transaction, the method further includes: The main resource manager determines a commit mode of the branch transaction according to the configuration information, wherein the commit mode is a one-phase commit or a two-phase commit; The master resource manager calling at least one slave resource manager to execute the branch transaction further comprises: The resource manager calls the slave resource manager to execute the branch transaction according to the submission mode.

4. The method according to claim 1, characterized in that When the master resource manager calls the slave resource manager to execute the branch transaction, the method further includes: The slave resource manager determines whether the branch transaction executed by it needs to execute external call logic; If so, the slave resource manager splits the branch transaction into at least one sub-branch transaction, and calls 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 it called, and returns the execution result of its own branch transaction to the master resource manager based on the execution results of each sub-branch transaction.

5. The method according to claim 1, characterized in that After determining the primary resource manager, 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 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.

6. The method according to claim 1, characterized in that The method further comprises: 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.

7. The method according to claim 6, characterized in that The global transaction information includes a global transaction state.

8. The method according to claim 7, characterized in that The method further comprises: Each slave resource manager executes its own scheduled task to asynchronously query the global transaction status in the global transaction table, and determines whether the global transaction status has timed out and has not been updated. If so, the slave resource manager whose global transaction status has timed out and has not been updated is determined as the master resource manager to roll back the global transaction.

9. The method according to claim 8, characterized in that Each slave resource manager executes its own scheduled task to asynchronously query the global transaction status in the global transaction table, including: The slave resource manager executes its own scheduled task to obtain a query lock of the global transaction state in the global transaction table; If the query lock is acquired, the steps of querying the global transaction status and determining whether the global transaction status has timed out and has not been updated are executed; If the global transaction status has not timed out and has not been updated, releasing the query lock; If the global transaction state times out and is not updated, the query lock is released after the system is used as the primary resource manager; If the query lock is not obtained, the current scheduled task is terminated, and after the next scheduled time arrives, the next scheduled task is executed to obtain the query lock.

10. The method according to claim 6, characterized in that The branch transaction information includes the corresponding relationship between each branch transaction and the corresponding slave resource manager.

11. The method according to claim 10, characterized in that The step of the primary resource manager rolling back the global transaction comprises: The master resource manager determines a branch transaction table associated with the global transaction table, and calls a slave resource manager corresponding to each branch transaction according to the branch transaction table to re-execute each branch transaction.

12. The method according to claim 1, characterized in that Determining a resource manager as the primary resource manager from multiple resource managers that execute business logic includes: The resource manager that receives the global transaction serves as the master resource manager.

13. The method according to claim 1, characterized in that The main resource manager splits the global transaction into at least one branch transaction, including: The main resource manager splits the global transaction into branch transactions corresponding to at least one service type in the global transaction.

14. A distributed transaction processing system, characterized in that: The system includes a plurality of resource managers that execute business logic; When processing a global transaction sent by a client, multiple resource managers execute the method described in any one of claims 1-13.

15. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 13 is implemented.

16. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 13 is implemented.

17. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 13 is implemented.

Images