A distributed transaction implementation method and a distributed system

Abstract

Embodiments of the present application provide a distributed transaction implementation method and a distributed system. The distributed system comprises a client, a first transaction coordinator and a first database server located in a first region, and a second transaction coordinator and a second database server located in a second region. When the client calls the first database server to execute a first branch transaction, the first database server performs a locking operation on data involved in the first branch transaction through the first transaction coordinator. After the first database server executes the first branch transaction, the first database server calls the second database server to execute a second branch transaction. When the second database server executes the second branch transaction, the second database server performs a locking operation on data involved in the second branch transaction through the second transaction coordinator. The distributed transaction implementation method can reduce mutual calls between devices in different regions and improve the efficiency of distributed transaction processing.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a distributed transaction implementation method and a distributed system. Background Technology

[0002] With the rapid development of network technology, distributed systems have become increasingly common. Distributed systems are based on a microservice architecture, deploying multiple services in different regions or on different nodes. These services can collaborate remotely to complete a transaction. For example, when transferring 100 yuan from account a in Bank A to account b in Bank B, the first service needs to be called to deduct 100 yuan from the balance of account a in Bank A's database, and the second service needs to be called to increase the balance of account b in Bank B's database by 100 yuan. This type of transaction, where multiple independent databases work together to complete a task, is called a distributed transaction, also known as a global transaction. A distributed transaction includes multiple branch transactions; for example, the database operation required by calling the first service in the above transfer transaction is one branch transaction, and the database operation required by calling the second service is another branch transaction. When a distributed transaction begins, a transaction coordinator is selected first. All execution devices of the global transaction's branches will interact with the transaction coordinator, such as branch transaction start, branch transaction end, and locking and unlocking requests between the transaction coordinator and the lock server. When the service instance implementing the branch transaction and the transaction coordinator are not in the same region, the above interactions need to be called across regions, which will increase network latency and reduce transaction processing efficiency. Summary of the Invention

[0003] This application discloses a distributed transaction implementation method and a distributed system, which can reduce mutual calls between devices in different regions during the execution of distributed transactions and improve the processing efficiency of distributed transactions.

[0004] In a first aspect, embodiments of this application provide a distributed transaction implementation method. This method is applied to a distributed system, which includes a client, a first database server, and a first transaction coordinator deployed in a first region, and a second database server and a second transaction coordinator deployed in a second region. The first database server is used to run a first service, and the second database server is used to run a second service. The method includes:

[0005] The client initiates a distributed transaction request to the first transaction coordinator;

[0006] Based on the distributed transaction response returned by the first transaction coordinator, the client calls the first database server to execute the first branch transaction, wherein the first branch transaction is a database transaction related to the first service;

[0007] After completing the first branch transaction through the first transaction coordinator, the first database server calls the second database server to execute the second branch transaction, which is a database transaction related to the second service.

[0008] The second database server executes the second branch transaction through the second transaction coordinator. Executing the second branch transaction includes locking the data involved in the second branch transaction through the second transaction coordinator.

[0009] When a distributed transaction needs to call services deployed in different regions, each service corresponds to a branch transaction. When the database server executes the corresponding branch transaction and needs to lock the data operated on by the branch transaction, the database server will perform data locking operations through the transaction coordinator deployed in the same region, instead of needing to perform locking operations through the transaction coordinator in the region where the client that initiated the distributed transaction is located. This can reduce mutual calls between devices located in different regions during the execution of the distributed transaction, reduce latency, and improve the execution efficiency of the distributed transaction.

[0010] In one specific implementation, before the second database server executes the second branch transaction through the second transaction coordinator, it further includes: the second database server determining that it is located in a different region from the first transaction coordinator, and the second database server determining that it is located in the same region as the second transaction coordinator.

[0011] In one specific implementation, the aforementioned distributed system further includes a second lock server deployed in a second region. The second database server executes the second branch transaction through a second transaction coordinator, including:

[0012] The second database server sends a start request for the second branch transaction to the second transaction coordinator. The start request for the second branch transaction includes the location information of the data involved in the second branch transaction in the second database.

[0013] The second transaction coordinator sends a second locking request to the second lock server. The second locking request includes the location information of the data involved in the second branch transaction in the second database.

[0014] The second lock server performs locking operations on the data involved in the second branch transaction based on the second locking request, and sends the locking result to the second transaction coordinator;

[0015] The second transaction coordinator sends the locking result back to the second database server;

[0016] The second database server executes the second branch transaction based on the locking result, and then sends the execution result of the second branch transaction back to the client through the first database server.

[0017] When a database server executes a corresponding branch transaction and needs to register the branch transaction with the transaction coordinator, the database server sends a branch transaction start request to the transaction coordinator deployed in the same region to register the branch transaction. This is done without having to register through the transaction coordinator in the region where the client initiating the distributed transaction is located. At the same time, the transaction coordinator that receives the branch transaction start request acquires the lock through the lock server in the same region. The transaction coordinator in the client's region does not need to call the lock server in the region where the database server executing the branch transaction is located. Therefore, it can reduce the mutual calls between devices in different regions during the execution of distributed transactions, reduce latency, and improve the execution efficiency of distributed transactions.

[0018] In one specific implementation, the second database server executes the second branch transaction based on the locking result, and then feeds back the execution result of the second branch transaction to the client through the first database server. The client then determines the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server. The execution result of the distributed transaction includes successful execution and execution failure.

[0019] In one specific implementation, after the client determines the execution result of the distributed transaction based on the execution result of the second branch transaction returned by the second database server, it includes:

[0020] The client sends a global operation request to the first transaction coordinator based on the execution result of the distributed transaction. When the execution result of the distributed transaction is successful, the global operation request is a global transaction commit request; when the execution result of the distributed transaction is failure, the global operation request is a global transaction rollback request.

[0021] The first transaction coordinator sends a two-phase operation request for the global transaction to the second transaction coordinator based on the global operation request. The two-phase operation request is either a two-phase commit request or a two-phase rollback request. When the global operation request is a global transaction commit request, the two-phase operation request is a two-phase commit request. When the global operation request is a global transaction rollback request, the two-phase operation request is a two-phase rollback request.

[0022] The second transaction coordinator schedules the second database server to execute the two-phase operation request.

[0023] In one specific implementation, the second database server executes the second branch transaction based on the locking result and feeds back the execution result of the second branch transaction to the client. This includes: when the locking result is successful and the second database server successfully completes the second branch transaction, the second database server feeds back the execution result of the successful execution of the second branch transaction to the client; or, when the locking result is unsuccessful or the second database server has not completed the second branch transaction, the second database server feeds back the execution result of the failed execution of the second branch transaction to the client.

[0024] In one specific implementation, the client determines the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server. This includes: when the execution result of the second branch transaction is successful and the execution results of other branch transactions included in the distributed transaction are all successful, the client determines that the execution result of the distributed transaction is successful; or, when the execution result of the second branch transaction is unsuccessful, the client determines that the execution result of the distributed transaction is unsuccessful.

[0025] In one specific implementation, before the second transaction coordinator schedules the second database server to execute the two-phase operation request after the second lock server successfully locks the data involved in the second branch transaction, the process includes: the second transaction coordinator sending a lock release request to the second lock server; the second lock server releasing the lock acquired when performing the locking operation on the data involved in the second branch transaction and sending a lock release success message to the second transaction coordinator.

[0026] Because the database server performs data locking operations through a transaction coordinator deployed in the same region, and the transaction coordinator implements locking through a lock server in the same region, the transaction coordinator does not need to perform lock release operations through cross-region calls when locks need to be released. This reduces mutual calls between devices located in different regions during the execution of distributed transactions, lowers latency, and improves the execution efficiency of distributed transactions.

[0027] In one specific implementation, before the first database server calls the second database server to execute the second branch transaction, the process further includes: the first database server sending a start request for the first branch transaction to the first transaction coordinator; the first transaction coordinator creating a first branch transaction identifier based on the start request for the first branch transaction and sending the first branch transaction identifier to the first database server; and the first database server successfully executing the first branch transaction after receiving the first branch transaction identifier.

[0028] In one specific implementation, the distributed system also includes a first lock server, and before the first transaction coordinator creates the first branch transaction identifier, it also includes:

[0029] The first transaction coordinator receives the start request for the first branch transaction sent by the first database server. The start request for the first branch transaction includes the location information of the data involved in the first branch transaction in the first database.

[0030] The first transaction coordinator sends a first locking request to the first lock server. The first locking request includes the location information of the data involved in the first branch transaction in the first database.

[0031] The first lock server performs a locking operation on the data involved in the first branch transaction based on the first locking request, and sends a message of successful locking to the second transaction coordinator;

[0032] The first transaction coordinator receives a message from the first lock server indicating that the lock acquisition was successful.

[0033] Secondly, embodiments of this application provide a distributed system, which includes a client, a first database server, and a first transaction coordinator deployed in a first region, and a second database server and a second transaction coordinator deployed in a second region, wherein the first database server is used to run a first service, and the second database server is used to run a second service.

[0034] The client is used to initiate a distributed transaction request to the first transaction coordinator;

[0035] Based on the distributed transaction response returned by the first transaction coordinator, the first database server is invoked to execute the first branch transaction, wherein the first branch transaction is a database transaction related to the first service;

[0036] After completing the first branch transaction through the first transaction coordinator, the first database server calls the second database server to execute the second branch transaction, which is a database transaction related to the second service.

[0037] The second database server is used to execute the second branch transaction through the second transaction coordinator, wherein executing the second branch transaction includes locking the data involved in the second branch transaction through the second transaction coordinator.

[0038] In one specific implementation, the second database server is used before the second branch transaction is executed through the second transaction coordinator.

[0039] The second database server is also used to determine that it is located in a different region from the first transaction coordinator, and the second database server determines that it is located in the same region as the second transaction coordinator.

[0040] In one specific implementation, the distributed system also includes a second lock server deployed in a second region.

[0041] The second database server executes the second branch transaction through the second transaction coordinator, including:

[0042] The second database server is also used to send a start request for the second branch transaction to the second transaction coordinator. The start request for the second branch transaction includes the location information of the data involved in the second branch transaction in the second database.

[0043] The second transaction coordinator is also used to send a second locking request to the second lock server. The second locking request includes the location information of the data involved in the second branch transaction in the second database.

[0044] The second lock server is used to perform locking operations on the data involved in the second branch transaction according to the second locking request, and send the locking result to the second transaction coordinator.

[0045] The second transaction coordinator is also used to feed back the locking results to the second database server;

[0046] The second database server is also used to execute the second branch transaction based on the locking result and to feed back the execution result of the second branch transaction to the client.

[0047] In one specific implementation, the client is also used to determine the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server;

[0048] In one specific implementation, the client is also used to send a global operation request to the first transaction coordinator based on the execution result of the distributed transaction. When the execution result of the distributed transaction is successful, the global operation request is a global transaction commit request, and when the execution result of the distributed transaction is failure, the global operation request is a global transaction rollback request.

[0049] The first transaction coordinator is also used to send a two-phase operation request for the global transaction to the second transaction coordinator according to the global operation request. The two-phase operation request is either a two-phase commit request or a two-phase rollback request. When the global operation request is a global transaction commit request, the two-phase operation request is a two-phase commit request. When the global operation request is a global transaction rollback request, the two-phase operation request is a two-phase rollback request.

[0050] The second transaction coordinator is also used to schedule the second database server to execute two-phase operation requests.

[0051] In one specific implementation, the second database server is also used to execute a second branch transaction based on the locking result, and to feed back the execution result of the second branch transaction to the client, specifically including:

[0052] If the locking result is successful and the second database server successfully completes the second branch transaction, the second database server will send the execution result of the successful execution of the second branch transaction back to the client; or, if the locking result is unsuccessful or the second database server has not completed the second branch transaction, the second database server will send the execution result of the unsuccessful execution of the second branch transaction back to the client.

[0053] In one specific implementation, the client is further configured to determine the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server. Specifically, the client determines the execution result of the distributed transaction as successful when the execution result of the second branch transaction is successful and the execution results of other branch transactions included in the distributed transaction are all successful; or, if the execution result of the second branch transaction is unsuccessful, the client determines the execution result of the distributed transaction as unsuccessful.

[0054] In one specific implementation, when the second lock server successfully locks the data involved in the second branch transaction, before the second transaction coordinator schedules the second database server to execute the two-phase operation request, the second transaction coordinator also sends a lock release request to the second lock server; the second lock server also releases the lock acquired when performing the locking operation on the data involved in the second branch transaction and sends a lock release success message to the second transaction coordinator.

[0055] In one specific implementation, before the first database server calls the second database server to execute the second branch transaction, it also includes:

[0056] The first database server is also used to send the start request of the first branch transaction to the first transaction coordinator;

[0057] The first transaction coordinator is also used to create a first branch transaction identifier based on the start request of the first branch transaction, and send the first branch transaction identifier to the first database server;

[0058] The first database server is also used to successfully execute the first branch transaction after receiving the first branch transaction identifier.

[0059] In one specific implementation, the distributed system also includes a first lock server.

[0060] Before the first transaction coordinator is used to create the first branch transaction identifier, it also includes:

[0061] The first transaction coordinator is also used to receive a first branch transaction start request sent by the first database server. The first branch transaction start request includes the location information of the data involved in the first branch transaction in the first database.

[0062] Send a first locking request to the first lock server. The first locking request includes the location information of the data involved in the first branch transaction in the first database.

[0063] The first lock server is used to perform locking operations on the data involved in the first branch transaction according to the first locking request, and send a message of successful locking to the second transaction coordinator;

[0064] The first transaction coordinator is also used to receive a message from the first lock server indicating that the lock has been successfully acquired. Attached Figure Description

[0065] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] Figure 1 This is a schematic diagram of a distributed system provided in an embodiment of this application;

[0067] Figure 2 This is an interactive diagram illustrating a distributed transaction implementation method provided in an embodiment of this application;

[0068] Figure 3 This is an interactive diagram illustrating another distributed transaction implementation method provided in this application embodiment;

[0069] Figure 4 This is an interactive diagram illustrating another distributed transaction implementation method provided in this application embodiment;

[0070] Figure 5 This is a schematic diagram of the structure of a second transaction coordination device provided in an embodiment of this application. Detailed Implementation

[0071] The distributed transaction implementation method and distributed system provided in this application are described below with reference to the accompanying drawings. A transaction is an operation task that accesses or updates data in a database. In traditional centralized applications, transactions are limited to accessing a single database resource; such transactions are called local transactions. In microservice-based distributed applications, a business application typically needs to call multiple microservices, and these calls usually correspond to multiple local database transactions. When a business application needs to call multiple microservices to implement multiple local database transactions, distributed transactions are required to ensure the data consistency of these multiple local database transactions.

[0072] A distributed transaction refers to a transaction that requires operations on multiple independent databases to complete a business operation. A distributed transaction can include multiple branch transactions. The responsibility of a distributed transaction is to coordinate the branch transactions under its jurisdiction to reach a consensus, either committing successfully together or rolling back together if they fail. Typically, each branch transaction is itself a local transaction within a relational database. For example, a user initiates a transfer transaction through a terminal to transfer 100 yuan from account a in bank A to account b in bank B. This transaction requires operations on data in the databases of bank A and bank B respectively. The transaction needs to call a first service to deduct 100 yuan from account a in bank A's database and call a second service to add 100 yuan to account b in bank B's database. The database operation required by calling the first service is one branch transaction, and the database operation required by calling the second service is another branch transaction. Since distributed transactions are usually global transactions spanning multiple regions or multiple databases, distributed transactions are also referred to as global transactions in this application. In the description of the embodiments of this application, a global transaction refers to a distributed transaction.

[0073] The distributed system provided in this application includes multiple regions, each region including one or more user terminals with clients deployed, one or more transaction coordinators (TCs), one or more database servers for providing services (e.g., microservices), one or more lock servers, and one or more databases. Figure 1 As shown, Figure 1 This is a diagram of a distributed system. Figure 1 The distributed system includes Region 1 and Region 2. Region 1 includes user terminal A, a first database server, a first transaction coordinator, a first lock server, and database A. User terminal A deploys client A, and the first database server deploys a first service. Region 2 includes user terminal B, a second database server, a second transaction coordinator, a second lock server, and database B. User terminal B deploys client B, and the second database server deploys a second service. Taking client A in Region 1 initiating a distributed transaction with the first transaction coordinator, which includes a first branch transaction and a second branch transaction, as an example, the execution process of this distributed transaction (taking successful commit as an example) in relevant technical implementations includes:

[0074] (1) Client A initiates a distributed transaction request to the first transaction coordinator. The first transaction coordinator creates a global transaction identifier (identity, ID) and returns the global transaction ID to client A. The global transaction ID is used to uniquely identify a distributed transaction. The client has a transaction manager (TM) embedded in it. The TM is responsible for initiating a distributed transaction request to start a distributed transaction and sending a global commit or global rollback instruction to the transaction coordinator. The transaction coordinator is used to maintain the running state of the distributed transaction, receive the instructions from the transaction manager to initiate the commit and rollback of the distributed transaction, and is responsible for communicating with the resource manager to coordinate the commit or rollback of each branch transaction.

[0075] (2) Client A calls the first service located in the first database server in the first region 1. The first service registers the first branch transaction with the first transaction coordinator. The database server has a resource manager (RM) embedded in it, which is responsible for branch registration, status reporting, and receiving instructions from the transaction coordinator to operate on the database and drive the commit and rollback of the branch (local) transaction.

[0076] (3) The first transaction coordinator determines that the locked data of the first branch transaction belongs to the first lock server, and initiates a lock request to the first lock server. After the first lock server successfully locks the data, it returns a lock success message to the first transaction coordinator. In this process, locking the data involved in the first branch transaction is used to prevent other concurrent transactions from operating on the data and causing conflicts or errors.

[0077] (4) The first transaction coordinator creates the first branch transaction ID and sends it to the first RM of the first service. After receiving the first branch transaction ID, the first RM performs the corresponding operation on the data that the first branch transaction needs to operate on in database A, commits the local transaction (i.e. the first branch transaction), and returns a message to the first transaction coordinator that the first branch transaction was successfully executed.

[0078] (5) The first service calls the second service in the second database server located in zone 2, and the second RM of the second service registers the second branch transaction with the first transaction coordinator;

[0079] (6) The first transaction coordinator determines that the locked data of the second branch transaction belongs to the second lock server of region 2, initiates a lock request to the second lock server, and after the second lock server successfully locks, it returns a lock success message to the first transaction coordinator.

[0080] (7) The first transaction coordinator creates a second branch transaction ID and sends it to the second RM of the second service. After receiving the second branch transaction ID, the second RM performs the corresponding operation on the data that the second branch transaction needs to operate on in database B, commits the local transaction (i.e. the second branch transaction), and returns a message to the first transaction coordinator that the second branch transaction was successfully executed.

[0081] (8) After the second service completes the second branch transaction, it returns a message to the first service indicating that the second service is complete. The first service returns a message to client A indicating that the first service and the second service are complete. After the client confirms that the call is complete, it initiates a distributed transaction commit request to the transaction coordinator.

[0082] (9) After receiving the distributed transaction commit request, the first transaction coordinator sends a lock release request to the first lock server and the second lock server respectively. The first lock server and the second lock server send a lock release success message to the first transaction coordinator.

[0083] (10) After receiving the message that the lock was released successfully, the first transaction coordinator sends a two-phase commit request to the first RM and the second RM respectively. After the first RM and the second RM complete the two-phase commit, they send a message that the commit was successful to the transaction coordinator respectively.

[0084] During the execution of the aforementioned distributed transaction, multiple calls are involved between devices in Region 1 and Region 2, including: in step (5), the first service calls the second service; in step (5), the second service registers the second branch transaction with the first transaction coordinator; in step (6), the first transaction coordinator initiates a lock request to the second server; in step (7), the second service returns a message to the first transaction coordinator indicating that the second branch transaction has been successfully executed; in step (9), the first transaction coordinator sends a lock release request to the second lock server; and in step (10), the first transaction coordinator calls the second service to perform a two-phase commit. That is, a distributed transaction includes at least the above six cross-region calls. A distributed transaction that needs to be completed across regions requires multiple cross-region calls, which increases network latency, increases the time to complete the transaction, and affects the efficiency of distributed transaction processing.

[0085] To address the aforementioned problems, this application provides a distributed transaction implementation method to reduce cross-region calls during the distributed transaction implementation process and improve the processing efficiency of distributed transactions. This method is applied to the aforementioned distributed system to... Figure 1 The distributed system implementation shown includes a first branch transaction and a second branch transaction as an example to introduce the distributed transaction implementation method provided in this application. For example... Figure 2 As shown, Figure 2 This is an interactive diagram illustrating an implementation of distributed transactions according to an embodiment of this application. The method includes the following steps S201 to S214.

[0086] S201. Client A sends a distributed transaction request to the first transaction coordinator.

[0087] A user initiates a distributed transaction through client A in user terminal A in region 1. Client A sends a distributed transaction request to the first transaction coordinator in region 1. The distributed transaction includes a first branch transaction and a second branch transaction.

[0088] S202. After receiving the distributed transaction request, the first transaction coordinator returns a distributed transaction response to client A.

[0089] After receiving a distributed transaction request, the first transaction coordinator creates and records a global transaction ID, and then returns a distributed transaction response including the global transaction ID to client A of user terminal A.

[0090] S203. After receiving the distributed transaction response, client A calls the first database server to execute the first branch transaction.

[0091] In this embodiment of the application, the distributed transaction initiated by client A needs to call a first service to complete a first branch transaction and a second service to complete a second branch transaction. The first branch transaction is a database transaction related to the first service, which is deployed on a first database server in region 1. The second branch transaction is a database transaction related to the second service, which is deployed on a second database server in region 2. The data to be operated on by the first branch transaction is located in database A, and the data to be operated on by the second branch transaction is located in database B.

[0092] S204. The first database server sends a first branch start request to the first transaction coordinator.

[0093] When the first database server executes the first branch transaction, it needs to execute the first branch transaction through the first transaction coordinator. This includes the first transaction coordinator registering the first branch transaction and completing the locking operation on the data involved in the first branch transaction through the first branch transaction, and sending a first branch start request to the first transaction coordinator.

[0094] S205. The first transaction coordinator sends the first lock request to the first lock server.

[0095] The first lock request indicates that the data involved in the first branch transaction be locked.

[0096] S206. The first lock server performs the locking operation on the data involved in the first branch transaction and returns a message indicating successful locking to the first transaction coordinator.

[0097] S207. The first transaction coordinator returns a response message to the first database server in response to the request to start the first branch. After receiving the response message, the first database server successfully executes the first branch transaction.

[0098] S208. The first database server calls the second database server to execute the second branch transaction.

[0099] S209. The second database server sends a second branch start request to the second transaction coordinator.

[0100] When the second database server determines that it is located in a different region from the first transaction coordinator, and when it determines that it is located in the same region as the second transaction coordinator, the second database server sends a second branch start request to the second transaction coordinator. When executing the second branch transaction, the second database server needs to do so through the second transaction coordinator, including the coordinator registering the second branch transaction and locking the data involved in the second branch transaction. The second branch start request includes the location information of the data involved in the second branch transaction within the second database.

[0101] S210. The second transaction coordinator sends a second locking request to the second lock server.

[0102] The second locking request indicates that the data involved in the second branch transaction be locked, and the second locking request includes the location information of the data involved in the second branch transaction in the second database.

[0103] S211. The second lock server performs locking operations on the data involved in the second branch transaction based on the second locking request, and returns the locking result to the second transaction coordinator.

[0104] The locking result includes successful locking and failed locking.

[0105] S212. The second transaction coordinator sends the locking result back to the second database server.

[0106] S213. The second database server executes the two-branch transaction based on the locking result and feeds back the execution result of the second-branch transaction to the client.

[0107] Specifically, if the locking result is a locking failure, the second database server cannot operate on the data involved in the second branch transaction, and the execution result of the second branch transaction is execution failure; if the locking result is a locking success, the second database server can operate on the data involved in the second branch transaction. If the second database server can successfully execute a local commit, the execution result of the second branch transaction is execution success; if the second database server cannot successfully execute a local commit, the execution result of the second branch transaction is execution failure.

[0108] In one possible implementation, the second database server sends the execution result of the second branch transaction to the first database server.

[0109] S214. The client determines the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server.

[0110] The client determines the execution result of the distributed transaction to be successful if the execution result of the second branch transaction is successful and the execution results of other branch transactions included in the distributed transaction are also successful; if the execution result of the second branch transaction is unsuccessful, the client determines the execution result of the distributed transaction to be unsuccessful.

[0111] The following is combined with Figure 3 and Figure 4 The distributed transaction implementation method in the embodiments of this application will be described in detail, such as... Figure 3 As shown, Figure 3 This is another interactive diagram illustrating the implementation of distributed transactions provided in this application embodiment. The method includes steps S1 to S30.

[0112] S1. Client A sends a distributed transaction request to the first transaction coordinator.

[0113] A user initiates a distributed transaction through client A in user terminal A in region 1. The first TM of client A sends a distributed transaction request to the first transaction coordinator in region 1. This distributed transaction includes a first branch transaction and a second branch transaction, which require calling a first service to complete the first branch transaction and a second service to complete the second branch transaction. The first service is deployed on the first database server in region 1, and the second service is deployed on the second database server in region 2. The data to be operated on by the first branch transaction is located in database A, and the data to be operated on by the second branch transaction is located in database B.

[0114] S2. The first transaction coordinator creates a global transaction ID based on the distributed transaction request and sends it to client A.

[0115] After receiving a distributed transaction request, the first transaction coordinator creates and records a global transaction ID, and then returns the global transaction ID to client A of user terminal A. The global transaction ID is used to uniquely identify a distributed transaction.

[0116] S3. Client A constructs the transaction context corresponding to the distributed transaction based on the global transaction ID and sends it to the first RM.

[0117] After obtaining the global transaction ID, client A constructs the transaction context corresponding to the distributed transaction and calls the first service deployed in the first database server to send the transaction context to the first database server. The transaction context is an association between transactional operations on resources and the components of the invoked operations. During the execution of a transaction, all threads participating in the transaction share the transaction context. Logically, the transaction context encapsulates all operations completed on transactional resources during a transaction. The transaction context includes the global transaction ID and the address information of the first transaction coordinator. The global transaction ID indicates the distributed transaction to which the branch transaction currently being executed by the first database server belongs, and the address information is used to instruct the first database server to interact with the first transaction coordinator when executing the transaction corresponding to the global transaction ID.

[0118] S4. The first RM constructs the first mirror data and the first locking information based on the transaction context, and sends the first branch start request and the first locking information to the first transaction coordinator.

[0119] The first mirror data includes a first pre-mirror record and a second post-mirror record. After the first Resource Manager (RM) of the first service obtains the transaction context, it parses the Structured Query Language (SQL) executed by the first service, constructs the first pre-mirror record corresponding to the first transaction branch based on the input parameters from the client or the caller of the first service, executes the SQL, constructs the first post-mirror record based on the execution result, and constructs the first locking information for the transaction. The input parameters include information about the data to be operated on by the first branch transaction. For example, if the distributed transaction is a transfer operation from account a to account b, and the first branch transaction deducts 100 yuan from the balance in account a, then the first service is a transfer service, and the input parameters include the ID of account a, the ID of account b, and the amount to be transferred. The first pre-mirror record records the first target data of the first branch transaction operation before the SQL is executed, such as the amount in account a before the transfer. The first post-mirror record records the second target data obtained after modifying the first target data using the SQL statement, such as the amount in account a before the transfer. The first locking information includes the name of the database where the first target data is located, the name of the table where the first target data is located, and the primary key of the row where the first target data is located.

[0120] After the first RM constructs the locking information, it determines that the first transaction coordinator and the first database server are located in the same region based on the address information of the first transaction coordinator. It then sends a first branch start request to the first transaction coordinator. The first branch start request includes a global transaction ID and first locking information. The global transaction ID is used by the first transaction coordinator to associate the first branch transaction with the distributed transaction, and the first locking information indicates the data that the first branch transaction needs to lock.

[0121] S5. After receiving the first locking information, the first transaction coordinator sends the first locking request to the first lock server.

[0122] After receiving the first locking information, the first transaction coordinator determines that the data indicating locking in the first locking information belongs to the management of the first lock server. The first transaction coordinator sends a first locking request to the first lock server. The first locking request includes the first locking information, which is used to indicate that the data row containing the first target data in the first locking information should be locked.

[0123] S6. The first lock server performs the locking operation based on the first locking request and returns a message indicating successful locking to the first transaction coordinator.

[0124] S7. The first transaction coordinator creates the first branch transaction ID and sends it to the first RM.

[0125] After receiving the lock acquisition success message, the first transaction coordinator creates a first branch transaction ID corresponding to the first branch transaction, associates the global transaction ID with the first branch transaction ID, and sends the first branch transaction ID to the first database server. The first branch transaction ID is used to uniquely identify the first branch transaction.

[0126] S8. The first RM executes the local commit of the first branch transaction.

[0127] After receiving the first branch transaction ID, the first RM of the first service performs a local commit, that is, executes the commit of the first branch transaction.

[0128] S9. The first RM sends a message to the first transaction coordinator that the first branch transaction has been successfully committed.

[0129] The message indicating that the first branch transaction was successfully committed includes the first branch transaction ID of the first branch transaction.

[0130] S10. The first transaction coordinator records that the first branch transaction has been successfully committed and returns a confirmation message to notify the first RM that it has received the message that the first branch transaction has been successfully committed.

[0131] S11. The first service calls the second service, and the first RM sends the aforementioned transaction context to the second RM of the second service.

[0132] The first service calls the second service, and the first database server sends the transaction context to the second database server through the first RM.

[0133] S12. The second RM constructs the second mirror data and the second locking information based on the transaction context, and sends the second branch start request and the second locking information to the second transaction coordinator.

[0134] The second mirror data includes a second pre-mirror record and a second post-mirror record. After the second RM of the second service obtains the transaction context, it parses the structured query language executed by the second service, constructs the second pre-mirror record corresponding to the second transaction branch based on the input parameters of the first service, executes the SQL, constructs the second post-mirror record based on the execution result, and constructs the second locking information for the transaction. The input parameters of the first service include information about the data to be operated on by the second branch transaction. For example, in the above transfer operation from account a to account b, the second branch transaction increases the balance in account b by 100 yuan. Therefore, the second service is the inflow service, and the input parameters of the first service include the ID of account b and the amount transferred. The second pre-mirror record records the third target data of the second branch transaction operation before the SQL is executed, such as the amount in account b before the transfer. The second post-mirror record records the fourth target data obtained after modifying the third target data using the SQL statement, such as the amount in account b after the transfer. The second locking information includes the name of the database where the third target data is located, the name of the table where the third target data is located, and the primary key of the row where the third target data is located.

[0135] After constructing the second locking information, the second RM determines that the first transaction coordinator and the second database server are located in different regions based on the address information of the first transaction coordinator. The second RM determines that the second transaction coordinator is the transaction coordinator associated with the first transaction coordinator in region 2 based on the configuration information. The second RM sends a second branch start request to the second transaction coordinator. The second branch start request includes a global transaction ID and second locking information. The global transaction ID is used by the second transaction coordinator to associate the second branch transaction with the distributed transaction. The second locking information indicates the data that the second branch transaction needs to lock.

[0136] S13. After receiving the second locking information, the second transaction coordinator sends a second locking request to the second lock server.

[0137] After receiving the second locking information, the second transaction coordinator determines that the data indicated for locking in the second locking information belongs to the management of the second lock server. The second transaction coordinator then sends a second locking request to the second lock server. The second locking request includes the second locking information, which is used to indicate that the data row containing the third target data in the second locking information should be locked.

[0138] It should be understood that the execution result of a distributed transaction includes both global transaction commit and global transaction rollback. Client A needs to determine whether the distributed transaction ultimately executes a global transaction commit or a global transaction rollback based on the execution results of all branch transactions included in the distributed transaction. If the execution results of all branch transactions included in the distributed transaction are successful (local commit successful), client A determines to execute a global transaction commit; if the execution result of any branch transaction included in the distributed transaction is a failure, client A determines to execute a global transaction rollback. In S1 to S12 above, the execution result of the first branch transaction is successful. The following example, using the first service calling the second service to execute the second branch transaction, illustrates the execution process of the distributed transaction implementation method in the two cases of successful and failed execution of the second branch transaction.

[0139] The following section first introduces the distributed transaction implementation method, assuming the second branch transaction executes successfully. After the second RM sends the start request for the second branch transaction and the second locking information to the second transaction coordinator, the above distributed transaction implementation method also includes the following steps S14 to S30.

[0140] S14. The second lock server performs the locking operation according to the second locking request and returns a message indicating successful locking to the second transaction coordinator.

[0141] S15. The second transaction coordinator creates a second branch transaction ID and sends the second branch transaction ID to the second RM.

[0142] After receiving the message that the lock was successfully acquired, the second transaction coordinator creates a second branch transaction ID corresponding to the second branch transaction, associates the global transaction ID with the second branch transaction ID, and sends the second branch transaction ID to the second RM.

[0143] S16. The second RM executes the local commit of the second branch transaction.

[0144] After receiving the aforementioned second branch transaction ID, the second RM of the second service commits the local transaction, that is, executes the commit of the second branch transaction.

[0145] S17. The second RM sends a message to the second transaction coordinator that the second branch transaction has been successfully committed.

[0146] The message indicating a successful commit of the second branch transaction includes the second branch transaction ID.

[0147] S18. The second transaction coordinator records the successful commit of the second branch transaction and returns a confirmation message to notify the second RM that it has received the message that the second branch transaction has been successfully committed.

[0148] S19. After receiving the confirmation message sent by the second transaction coordinator, the second RM returns a message indicating successful call to the first RM.

[0149] S20. After receiving the successful call message from the second RM, the first RM returns a successful call message to client A.

[0150] S21. Client A sends a global commit request to the first transaction coordinator.

[0151] The global commit request includes the aforementioned global transaction ID. After receiving the successful call message from the first RM, client A determines that all branch transactions of the distributed transaction have been executed successfully. Client A, having determined that the distributed transaction has been executed successfully, sends a global commit request to the first transaction coordinator. The global commit request instructs the database server executing the branch transactions to perform a two-phase commit operation.

[0152] S22. The first transaction coordinator sends the first release request to the first lock server.

[0153] After receiving the global commit request, the first transaction coordinator determines, based on the first branch transaction ID associated with the global transaction ID, that a lock release operation needs to be performed on the locks acquired by the first branch transaction. The first transaction coordinator then sends a first lock release request to the first lock server. This first lock release request includes the aforementioned first locking information, indicating to the first lock server the data that needs to be released.

[0154] S23. The first lock server performs the lock release operation and sends a message indicating successful lock release to the first transaction coordinator.

[0155] After receiving the first lock release request, the first lock server releases the lock it acquired for the first branch transaction, and sends a lock release success message to the first transaction coordinator after successful lock release.

[0156] S24. The first transaction coordinator sends a two-phase commit request for the distributed transaction to the second transaction coordinator.

[0157] The two-phase commit request includes a global transaction ID and a second branch transaction ID, which are used to indicate the branch transaction that needs to be committed.

[0158] S25. The second transaction coordinator sends a second release request to the second lock server.

[0159] The second unlock request includes the second locking information, which indicates the data that the second lock server needs to unlock.

[0160] S26. The second lock server performs the lock release operation and sends a message indicating successful lock release to the second transaction coordinator.

[0161] After receiving the second lock release request, the second lock server releases the lock it acquired for the second branch transaction. After successfully releasing the lock, the second lock server sends a message of successful lock release to the second transaction coordinator.

[0162] S27. The second transaction coordinator returns a message to the first transaction coordinator indicating that the two-phase commit is complete.

[0163] S28. The first transaction coordinator returns a message to client A indicating that the distributed transaction is complete.

[0164] It should be noted that after the first lock server and the second lock server successfully release the locks, and the first transaction coordinator returns a message indicating that the distributed transaction is complete to client A, the distributed transaction is considered complete for client A.

[0165] S29. The first transaction coordinator initiates a two-phase commit request for the first branch transaction to the first RM. After receiving the request, the first RM clears the first mirror data created for the first branch transaction and returns a message to the first transaction coordinator that the two-phase commit is complete.

[0166] S30. The second transaction coordinator initiates a two-phase commit request for the second branch transaction to the second RM. After receiving the request, the second RM clears the second mirror data created for the second branch transaction and returns a message to the second transaction coordinator indicating that the two-phase commit is complete.

[0167] The above example illustrates the distributed transaction implementation method provided in this application, using the successful commit of a distributed transaction as an example. It should be understood that if any branch of the distributed transaction encounters an anomaly, such as a second lock server failing to acquire a lock or a second RM failing to commit locally, the distributed transaction will perform a global transaction rollback operation. Figure 4 As shown, Figure 4 This is another interactive diagram illustrating the implementation of distributed transactions provided in this application embodiment. Taking the failure of the second lock server to acquire the lock as an example, during the execution of this distributed transaction implementation method, the process before S14 is as described in S1 to S13 above. After the second transaction coordinator receives the second locking information and sends a second locking request to the second lock server, the execution process of this distributed transaction further includes S14 to S24.

[0168] S14'. The second lock server performs the locking operation based on the second locking request and returns a locking failure message to the second transaction coordinator.

[0169] After receiving the second locking request, the second locking server finds that there is already a locking information for the row containing the third target data, meaning that other branch transactions are operating on the data in that row. Therefore, the second locking server fails to acquire the lock and sends a locking failure message to the second transaction coordinator.

[0170] S15'. The second transaction coordinator returns a message to the second RM indicating that locking failed.

[0171] S16'. After receiving the locking failure message sent by the second transaction coordinator, the second RM returns a call failure message to the first RM.

[0172] S17'. After receiving the call failure message sent by the second RM, the first RM returns the call failure message to client A.

[0173] S18'. Client A sends a global rollback request to the first transaction coordinator.

[0174] The global rollback request includes the aforementioned global transaction ID, which indicates the data that the first transaction coordinator needs to perform a rollback operation on. After receiving a call failure message from the first RM, client A determines that the distributed transaction has failed and sends a global rollback request to the first transaction coordinator. The global rollback request instructs the database server executing the branch transaction to perform a two-phase rollback operation.

[0175] S19'. The first transaction coordinator sends the first release request to the first lock server.

[0176] The first unlock request includes the first locking information, which indicates that the first lock server needs to release the data.

[0177] S20'. The first lock server performs the lock release operation and sends a message indicating successful lock release to the first transaction coordinator.

[0178] After receiving the first lock release request, the first lock server releases the lock it acquired for the first branch transaction, and sends a lock release success message to the first transaction coordinator after successful lock release.

[0179] S21'. The first transaction coordinator returns a message to client A indicating that the distributed transaction is complete.

[0180] S22'. The first transaction coordinator sends a two-phase rollback request to the second transaction coordinator.

[0181] S23'. The first transaction coordinator initiates a two-phase rollback request for the first branch transaction to the first RM. After receiving the request, the first RM performs the rollback operation, restores the second target data to the first target data according to the mirror data, and then clears the first mirror data created for the first branch transaction.

[0182] S24'. The second transaction coordinator initiates a two-phase rollback request for the second branch transaction to the second RM. After receiving the request, the second RM clears the second mirror data created for the second branch transaction.

[0183] Based on the above description of the distributed transaction implementation method provided in the embodiments of this application, and Figure 3 and Figure 4 It can be seen that when the database server executes a corresponding branch transaction, requiring branch transaction registration and locking or unlocking operations on the data operated on by the branch transaction, the database server can achieve branch transaction registration and data locking or unlocking operations through a transaction coordinator deployed in the same region, without needing to rely on the transaction coordinator in the region where the client initiating the distributed transaction is located. This reduces mutual calls between devices in different regions during the execution of the distributed transaction. Taking the successful execution of the distributed transaction as an example, a single distributed transaction only involves two cross-regional calls: the first service calling the second service in S11 and the first transaction coordinator sending a two-phase commit request for the distributed transaction to the second transaction coordinator in S241. Therefore, implementing the distributed transaction implementation method provided in this application embodiment can reduce network latency during the execution of distributed transactions, improve the efficiency of distributed transaction processing, reduce the holding time of a transaction lock in a distributed transaction, and reduce the probability of data conflicts in high-concurrency scenarios.

[0184] It should be noted that, for the sake of simplicity, the above method embodiments are described as a series of actions. However, those skilled in the art should know that the present invention is not limited to the described order of actions. Furthermore, those skilled in the art should also know that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily required by the present invention.

[0185] Other reasonable combinations of steps that can be conceived by those skilled in the art based on the above description also fall within the scope of protection of this invention. Furthermore, those skilled in the art should also be aware that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to this invention.

[0186] The above text combines Figures 1 to 4 The distributed system and distributed transaction implementation method provided in the embodiments of this application have been described in detail. The computing device provided in the embodiments of this application is described below.

[0187] See Figure 5 , Figure 5This is a schematic diagram of a second transaction coordination device 500 provided in an embodiment of this application. The second transaction coordination device 500 includes one or more processors 510, a communication interface 520, and a memory 530. The processors 510, the communication interface 520, and the memory 530 are interconnected via a bus 540. The second transaction coordinator may be a software module running in the second transaction coordination device 500, or the second transaction coordinator itself may be the second transaction coordination device 500. The second transaction coordination device 500 can be used to implement the above-mentioned... Figure 3 or Figure 4 The operations performed by the second transaction coordinator will not be described in detail here.

[0188] In this embodiment, the processor 510 can have various specific implementations. For example, the processor 510 can be a central processing unit (CPU) or a graphics processing unit (GPU), and it can also be a single-core processor or a multi-core processor. The processor 510 can be a combination of a CPU and a hardware chip. The hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 510 can also be implemented using a logic device with built-in processing logic, such as an FPGA or a digital signal processor (DSP).

[0189] The communication interface 520 can be a wired interface or a wireless interface, used for communicating with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., while the wireless interface can be a cellular network interface or a wireless LAN interface, etc. For example, in this embodiment, the communication interface 520 can be used to perform the above-described... Figure 3 The process includes receiving the second locking information sent by the second database server and returning the second branch transaction ID to the second database server.

[0190] Memory 530 may be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 830 may also be volatile memory, which may be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DRRAM).

[0191] The memory 530 can be used to store program code and data, so that the processor 510 can call the program code stored in the memory 530 to execute the operation steps of the second transaction coordinator in the above method embodiment. Furthermore, the second transaction coordination device 500 may include, compared to... Figure 5 The number of components displayed may be more or less, or there may be different component configurations.

[0192] Bus 540 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 540 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0193] Specifically, the specific implementation of various operations performed by the second transaction coordination device 500 can be referred to the specific operation of the second transaction coordinator in the above method embodiment, and will not be repeated here.

[0194] This application embodiment also provides a first transaction coordination device, the structure of which is the same as the structure of the second transaction coordinator described above. The first transaction coordinator may be a software module running within the first transaction coordination device, or the first transaction coordinator itself may be the first transaction coordination device. The first transaction coordination device can be used to implement the above-described... Figure 3 or Figure 4 The operations performed by the first transaction coordinator will not be described in detail here.

[0195] This application embodiment also provides a first database server, the structure of which is the same as that of the second transaction coordinator 500 described above. The first database server can be used to implement the above... Figure 3 or Figure 4 The operations performed by the first database server will not be described in detail here.

[0196] This application embodiment also provides a second database server, the structure of which is the same as that of the second transaction coordinator 500 described above. The second database server can be used to implement the above... Figure 3 or Figure 4 The operations performed by the second database server will not be described in detail here.

[0197] This application embodiment also provides a first lock server, the structure of which is the same as that of the second transaction coordinator 500 described above. The first lock server can be used to implement the above... Figure 3 or Figure 4 The operations performed by the first lock server will not be described in detail here.

[0198] This application embodiment also provides a second lock server, the structure of which is the same as that of the second transaction coordinator 500 described above. The second lock server can be used to implement the above... Figure 3 or Figure 4 The operations performed by the second lock server will not be described in detail here.

[0199] This application embodiment also provides a user terminal, the structure of which is the same as that of the second transaction coordinator 500 described above. The user terminal can be used to implement the above... Figure 3 or Figure 4 The operations performed by user terminal A will not be described in detail here.

[0200] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0201] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer program instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium, where a semiconductor medium can be a solid-state drive.

[0202] The above description is merely a specific embodiment of this application. Any variations or substitutions conceived by those skilled in the art based on the specific embodiments provided in this application should be covered within the protection scope of this application.

Claims

1. A method for implementing distributed transactions, characterized in that, The method is applied to a distributed system, which includes a client, a first database server, and a first transaction coordinator deployed in a first region, and a second database server and a second transaction coordinator deployed in a second region. The first database server is used to run a first service, and the second database server is used to run a second service. The method includes: The client initiates a distributed transaction request to the first transaction coordinator; The client invokes the first database server to execute a first branch transaction based on the distributed transaction response returned by the first transaction coordinator, wherein the first branch transaction is a database transaction related to the first service; After the first database server completes the first branch transaction through the first transaction coordinator, the first database server calls the second database server to execute the second branch transaction, which is a database transaction related to the second service. The second database server executes the second branch transaction through the second transaction coordinator, wherein executing the second branch transaction includes locking the data involved in the second branch transaction through the second transaction coordinator.

2. The method according to claim 1, characterized in that, Before the second database server executes the second branch transaction through the second transaction coordinator, it also includes: The second database server determines that it is located in a different region from the first transaction coordinator, and the second database server determines that it is located in the same region as the second transaction coordinator.

3. The method according to claim 1, characterized in that, The distributed system also includes a second lock server deployed in the second region. The second database server executes the second branch transaction through the second transaction coordinator, including: The second database server sends a start request for the second branch transaction to the second transaction coordinator. The start request for the second branch transaction includes the location information of the data involved in the second branch transaction in the second database. The second transaction coordinator sends a second locking request to the second lock server, the second locking request including the location information of the data involved in the second branch transaction in the second database; The second lock server performs a locking operation on the data involved in the second branch transaction according to the second locking request, and sends the locking result to the second transaction coordinator; The second transaction coordinator feeds back the locking result to the second database server; The second database server executes the second branch transaction based on the locking result and feeds back the execution result of the second branch transaction to the client.

4. The method according to claim 3, characterized in that, The method further includes: The client determines the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server.

5. The method according to claim 4, characterized in that, After determining the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server, the client further includes: The client sends a global operation request to the first transaction coordinator based on the execution result of the distributed transaction. When the execution result of the distributed transaction is successful, the global operation request is a global transaction commit request. When the execution result of the distributed transaction is unsuccessful, the global operation request is a global transaction rollback request. The first transaction coordinator sends a two-phase operation request for the global transaction to the second transaction coordinator according to the global operation request. The two-phase operation request is either a two-phase commit request or a two-phase rollback request. When the global operation request is a global transaction commit request, the two-phase operation request is a two-phase commit request. When the global operation request is a global transaction rollback request, the two-phase operation request is a two-phase rollback request. The second transaction coordinator schedules the second database server to execute the two-phase operation request.

6. The method according to claim 4, characterized in that, The second database server executes the second branch transaction based on the locking result and feeds back the execution result of the second branch transaction to the client, including: When the locking result is successful and the second database server successfully completes the second branch transaction, the second database server will send the execution result of the successful execution of the second branch transaction back to the client; or, If the locking result is a locking failure or the second database server has not completed the second branch transaction, the second database server will send the execution result of the second branch transaction failure back to the client.

7. The method according to claim 6, characterized in that, The client determines the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server, including: The client determines that the execution result of the distributed transaction is successful when the execution result of the second branch transaction is successful and the execution results of other branch transactions included in the distributed transaction are all successful; or, the client determines that the execution result of the distributed transaction is unsuccessful when the execution result of the second branch transaction is unsuccessful.

8. The method according to claim 5, characterized in that, When the second lock server successfully locks the data involved in the second branch transaction. Before the second transaction coordinator schedules the second database server to execute the two-phase operation request, it also includes: The second transaction coordinator sends a lock release request to the second lock server; The second lock server releases the locks acquired when performing locking operations on the data involved in the second branch transaction and sends a message to the second transaction coordinator indicating that the lock release was successful.

9. The method according to any one of claims 1 to 7, characterized in that, Before the first database server calls the second database server to execute the second branch transaction, it also includes: The first database server sends a request to start the first branch transaction to the first transaction coordinator; The first transaction coordinator creates a first branch transaction identifier based on the start request of the first branch transaction and sends the first branch transaction identifier to the first database server. After receiving the first branch transaction identifier, the first database server successfully executes the first branch transaction.

10. The method according to claim 8, characterized in that, The distributed system also includes a first lock server. Before the first transaction coordinator creates the first branch transaction identifier, the following steps are also included: The first transaction coordinator receives the start request of the first branch transaction sent by the first database server. The start request of the first branch transaction includes the location information of the data involved in the first branch transaction in the first database. The first transaction coordinator sends a first locking request to the first lock server, the first locking request including the location information of the data involved in the first branch transaction in the first database; The first lock server performs a locking operation on the data involved in the first branch transaction according to the first locking request, and sends a message of successful locking to the second transaction coordinator; The first transaction coordinator receives a message from the first lock server indicating that the lock acquisition was successful.

11. A distributed system, characterized in that, The distributed system includes a client, a first database server, and a first transaction coordinator deployed in a first region, and a second database server and a second transaction coordinator deployed in a second region. The first database server runs a first service, and the second database server runs a second service. The client is configured to initiate a distributed transaction request to the first transaction coordinator, and, based on the distributed transaction response returned by the first transaction coordinator, call the first database server to execute a first branch transaction, wherein the first branch transaction is a database transaction related to the first service. The first database server is configured to call the second database server to execute a second branch transaction after completing the first branch transaction through the first transaction coordinator, wherein the second branch transaction is a database transaction related to the second service; The second database server is used to execute the second branch transaction through the second transaction coordinator, wherein executing the second branch transaction includes locking the data involved in the second branch transaction through the second transaction coordinator.

12. The system according to claim 11, characterized in that, The second database server is used before executing the second branch transaction through the second transaction coordinator. The second database server is further configured to determine that it is located in a different region from the first transaction coordinator, and the second database server determines that it is located in the same region as the second transaction coordinator.

13. The system according to claim 11, characterized in that, The distributed system also includes a second lock server deployed in the second region. The second database server executes the second branch transaction through the second transaction coordinator, including: The second database server is further configured to send a start request for a second branch transaction to the second transaction coordinator, the start request for the second branch transaction including the location information of the data involved in the second branch transaction in the second database; The second transaction coordinator is further configured to send a second locking request to the second lock server, the second locking request including the location information of the data involved in the second branch transaction in the second database; The second lock server is used to perform locking operations on the data involved in the second branch transaction according to the second locking request, and send the locking result to the second transaction coordinator; The second transaction coordinator is also used to feed back the locking result to the second database server; The second database server is also configured to execute the second branch transaction based on the locking result, and to feed back the execution result of the second branch transaction to the client.

14. The system according to claim 13, characterized in that, The client is also used to determine the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server.

15. The system according to claim 14, characterized in that, The client is further configured to send a global operation request to the first transaction coordinator based on the execution result of the distributed transaction, wherein when the execution result of the distributed transaction is successful, the global operation request is a global transaction commit request, and when the execution result of the distributed transaction is unsuccessful, the global operation request is a global transaction rollback request. The first transaction coordinator is further configured to send a two-phase operation request for the global transaction to the second transaction coordinator according to the global operation request. The two-phase operation request is a two-phase commit request or a two-phase rollback request. When the global operation request is a global transaction commit request, the two-phase operation request is a two-phase commit request. When the global operation request is a global transaction rollback request, the two-phase operation request is a two-phase rollback request. The second transaction coordinator is also used to schedule the second database server to execute the two-phase operation request.

16. The system according to claim 14, characterized in that, The second database server is also configured to execute the second branch transaction based on the locking result, and to feed back the execution result of the second branch transaction to the client, specifically including: When the locking result is successful and the second database server successfully completes the second branch transaction, the second database server will send the execution result of the successful execution of the second branch transaction back to the client; or, If the locking result is a locking failure or the second database server has not completed the second branch transaction, the second database server will send the execution result of the second branch transaction failure back to the client.

17. The system according to claim 16, characterized in that, The client is also used to determine the execution result of the distributed transaction based on the execution result of the second branch transaction fed back by the second database server, specifically including: The client determines that the execution result of the distributed transaction is successful when the execution result of the second branch transaction is successful and the execution results of other branch transactions included in the distributed transaction are all successful; or, the client determines that the execution result of the distributed transaction is unsuccessful when the execution result of the second branch transaction is unsuccessful.

18. The system according to claim 15, characterized in that, When the second lock server successfully locks the data involved in the second branch transaction. The second transaction coordinator is also used to schedule the second database server to execute the two-phase operation request beforehand. The second transaction coordinator is also used to send a lock release request to the second lock server; The second lock server is also used to release the locks acquired when performing locking operations on the data involved in the second branch transaction, and to send a message to the second transaction coordinator that the lock release was successful.

19. The system according to any one of claims 11 to 17, characterized in that, Before the first database server calls the second database server to execute the second branch transaction, it also includes: The first database server is further configured to send a request to start the first branch transaction to the first transaction coordinator; The first transaction coordinator is further configured to create a first branch transaction identifier based on the start request of the first branch transaction, and send the first branch transaction identifier to the first database server; The first database server is also configured to successfully execute the first branch transaction after receiving the first branch transaction identifier.

20. The system according to claim 18, characterized in that, The distributed system also includes a first lock server. Before the first transaction coordinator creates the first branch transaction identifier, it also includes: The first transaction coordinator is further configured to receive a start request for the first branch transaction sent by the first database server, wherein the start request for the first branch transaction includes the location information of the data involved in the first branch transaction in the first database. Send a first locking request to the first lock server, the first locking request including the location information of the data involved in the first branch transaction in the first database; The first lock server is configured to perform a locking operation on the data involved in the first branch transaction according to the first locking request, and send a message of successful locking to the second transaction coordinator; The first transaction coordinator is also used to receive a message from the first lock server indicating that the lock has been successfully acquired.

Images