CN117311913A - Distributed transaction processing method, device, equipment and storage medium - Google Patents

Abstract

The embodiment of the application provides a distributed transaction processing method, a device, equipment and a storage medium, which can be applied to various scenes such as cloud technology, artificial intelligence, intelligent traffic, auxiliary driving, vehicle-mounted and the like, and the method comprises the following steps: the coordinator node divides the distributed transaction into sub-transactions that execute on different participant nodes. For each sub-transaction, determining the target sending time delay of the coordination node when sending the sub-transaction by taking the negative correlation of the target sending time delay corresponding to the sub-transaction and the network time delay corresponding to the sub-transaction as a reference. For the sub-transaction with shorter network delay, the target sending delay of the coordination node when sending the sub-transaction is longer, so that the execution time of the sub-transaction is later, and the associated data items do not need to be locked before the sub-transaction is executed, so that the data items can be operated by other distributed transactions, thereby reducing the lock contention time of the sub-transaction with shorter network delay to the data items and improving the throughput performance and concurrency of the distributed system.

Description

A distributed transaction processing method, device, equipment and storage medium

Technical Field

The embodiments of the present application relate to the field of database technology, and in particular to a distributed transaction processing method, apparatus, device and storage medium.

Background Art

Driven by data computing and data high availability, the number of data centers is increasing. In the traditional business model, transactions focus on data access in a single data center. As business models change, distributed transactions that operate data items across data centers are becoming more and more common.

In the distributed transaction processing process, the coordinating node divides the distributed transaction into multiple sub-transactions, and then sends the multiple sub-transactions to the corresponding participating nodes. When each participating node receives a sub-transaction, it locks and processes the data items involved in the sub-transaction, and then returns the execution result to the coordinating node. After receiving the execution results of all sub-transactions, the coordinating node returns the final status of the distributed transaction to each participating node. After receiving the processing status, each participating node unlocks the locked data items.

In the above processing, the coordination node needs to receive the execution results corresponding to all subtransactions before it can trigger each participating node to unlock the locked data items. However, the time when the execution results of different subtransactions arrive at the coordination node is different, so the reference node corresponding to the fastest subtransaction (the subtransaction whose execution result arrives at the coordination node earliest) needs to wait for the reference node corresponding to the slowest subtransaction (the subtransaction whose execution result arrives at the coordination node latest) to return the execution result before it can unlock the locked data items. In the locked state, the data items cannot be operated by other distributed transactions, causing other distributed transactions to wait. When the number of distributed transactions is large, it is easy to cause transaction processing blockage, which in turn affects the throughput performance of the distributed database.

Summary of the invention

Embodiments of the present application provide a distributed transaction processing method, apparatus, device, and storage medium for improving the throughput performance of a distributed database.

On the one hand, an embodiment of the present application provides a distributed transaction processing method, including:

Divide the distributed transaction into multiple sub-transactions, each of which corresponds to a participating node;

For the multiple sub-transactions, the following operations are performed respectively: based on the network delay between the participating node and the coordinating node corresponding to the sub-transaction, a target sending delay corresponding to the sub-transaction is obtained, and the target sending delay is negatively correlated with the network delay;

According to the obtained multiple target sending delays, the multiple sub-transactions are respectively sent to corresponding participating nodes for transaction processing;

Based on the sub-transaction processing messages returned by the participating nodes corresponding to each of the multiple sub-transactions, the processing status of the distributed transaction is obtained.

On the one hand, an embodiment of the present application provides a distributed transaction processing device, including:

A partitioning module is used to divide a distributed transaction into multiple sub-transactions, each of which corresponds to a participating node;

The processing module is used to perform the following operations respectively for the multiple sub-transactions: based on the network delay between the participating node corresponding to the sub-transaction and the coordinating node, obtain the target sending delay corresponding to the sub-transaction, wherein the target sending delay is negatively correlated with the network delay;

A sending module, configured to send the plurality of sub-transactions to corresponding participating nodes for transaction processing respectively according to the obtained plurality of target sending delays;

The processing module is further used to obtain the processing status of the distributed transaction based on the sub-transaction processing messages returned by the participating nodes corresponding to each of the multiple sub-transactions.

Optionally, the division module is specifically used for:

Based on participating nodes corresponding to each of the multiple data items associated with the distributed transaction, the distributed transaction is divided into multiple sub-transactions, wherein each sub-transaction corresponds to at least one data item and each sub-transaction corresponds to a participating node.

Optionally, the processing module is specifically used for:

Obtaining network delays between participating nodes corresponding to each of the multiple sub-transactions and the coordinating node;

Obtaining a maximum network delay from the network delays corresponding to the multiple sub-transactions;

Based on the maximum network delay and the network delay corresponding to the subtransaction, a target sending delay corresponding to the subtransaction is obtained, wherein a delay difference between the maximum network delay and the network delay corresponding to the subtransaction is positively correlated with the target sending delay.

Optionally, the processing module is specifically used for:

Based on the network delay corresponding to the subtransaction, obtaining a total execution delay corresponding to the subtransaction;

Based on the maximum network delay, obtaining a total execution delay of the distributed transaction;

The delay difference between the total execution delay of the distributed transaction and the total execution delay corresponding to the sub-transaction is used as the target sending delay corresponding to the sub-transaction.

Optionally, the processing module is specifically used for:

Based on the network delay corresponding to the sub-transaction and the execution delay of the participating node corresponding to the sub-transaction locally executing the sub-transaction, a target sending delay corresponding to the sub-transaction is obtained, wherein the execution delay is negatively correlated with the target sending delay.

Optionally, the processing module is specifically used for:

Receiving sub-transaction processing messages returned by participating nodes corresponding to each of the multiple sub-transactions;

For the multiple subtransactions, the following operations are performed respectively: from a subtransaction processing message corresponding to a subtransaction, a lock contention state of a data item associated with the subtransaction is obtained;

If the lock contention states corresponding to the multiple subtransactions are all: the associated data items have been locked, then the processing state of the distributed transaction is determined to be: committed state.

Optionally, the processing module is specifically used for:

Sending a collection request to each participating node corresponding to each of the multiple subtransactions, wherein the collection request is used to instruct the participating node to return the execution result of the corresponding subtransaction;

Receiving sub-transaction processing messages returned by participating nodes corresponding to the multiple sub-transactions, wherein the sub-transaction processing messages include: execution results of the sub-transactions;

When the execution results corresponding to the multiple sub-transactions are all: successful execution, it is determined that the processing status of the distributed transaction is: committed status.

The sending module is also used for:

After obtaining the processing status of the distributed transaction based on the sub-transaction processing messages returned by the participating nodes corresponding to each of the multiple sub-transactions, the processing status of the distributed transaction is sent to the participating nodes corresponding to each of the multiple sub-transactions, so that each participating node unlocks the corresponding data item.

On the one hand, an embodiment of the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned distributed transaction processing method when executing the program.

On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program executable by a computer device. When the program runs on the computer device, the computer device executes the steps of the above-mentioned distributed transaction processing method.

On the one hand, an embodiment of the present application provides a computer program product, which includes a computer program stored on a computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer device, the computer device performs the above-mentioned distributed transaction processing steps.

In an embodiment of the present application, after receiving a distributed transaction, the coordinating node first divides the distributed transaction into sub-transactions executed on different participating nodes. For each sub-transaction, based on the network delay between the participating node and the coordinating node corresponding to the sub-transaction, the target sending delay of the coordinating node when sending the sub-transaction is determined. Since the target sending delay corresponding to the sub-transaction is negatively correlated with the network delay corresponding to the sub-transaction, the longer the corresponding network delay of the sub-transaction, the shorter the corresponding target sending delay, that is, the earlier the coordinating node will send the sub-transaction to the corresponding participating node for transaction processing; for the shorter the network delay of the sub-transaction, the longer the corresponding target sending delay, that is, the later the coordinating node will send the sub-transaction to the corresponding participating node for transaction processing.

For subtransactions with shorter network delays, since the target sending delay of the coordinating node when sending the subtransaction is longer, the execution time of the subtransaction is later. Therefore, before the subtransaction is executed, there is no need to lock the data items corresponding to the subtransaction, so these data items can be operated by other distributed transactions, thereby reducing the lock contention time of the subtransactions with shorter network delays for the data items.

At the same time, since the network delay of this sub-transaction is relatively short, the time when the corresponding execution result arrives at the coordination node is not much different from the time when the execution result of the sub-transaction with a longer network delay arrives at the coordination node. This reduces the lock contention time of hot data without affecting the execution of distributed transactions, thereby improving the throughput performance and concurrency of the distributed system.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

FIG1A is a schematic diagram of a flow chart of a distributed transaction processing method provided in an embodiment of the present application;

FIG1B is a schematic diagram of a system architecture provided in an embodiment of the present application;

FIG2 is a schematic diagram of the structure of a server provided in an embodiment of the present application;

FIG3 is a system architecture diagram of an enterprise-level distributed database provided in an embodiment of the present application;

FIG4 is a schematic diagram of a flow chart of a distributed transaction processing method provided in an embodiment of the present application;

FIG5 is a schematic diagram of a locking process of a distributed transaction provided in an embodiment of the present application;

FIG6 is a schematic diagram of an unlocking process of a distributed transaction provided in an embodiment of the present application;

FIG7 is a schematic diagram of a flow chart of a distributed transaction processing method provided in an embodiment of the present application;

FIG8 is a schematic diagram of the structure of a distributed transaction processing device provided in an embodiment of the present application;

FIG. 9 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and beneficial effects of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

For ease of understanding, the terms involved in the embodiments of the present invention are explained below.

Cloud technology refers to a hosting technology that unifies hardware, software, network and other resources within a wide area network or local area network to achieve data computing, storage, processing and sharing.

Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model. It can form a resource pool, which can be used on demand and is flexible and convenient. Cloud computing technology will become an important support. The background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture websites and more portal websites. With the rapid development and application of the Internet industry, each item may have its own identification mark in the future, and all of them need to be transmitted to the background system for logical processing. Data of different levels will be processed separately, and all kinds of industry data require strong system backing support, which can only be achieved through cloud computing. The embodiment of the present application can process distributed transactions with cloud technology.

In short, a database can be seen as an electronic filing cabinet, that is, a place where electronic files are stored, and users can add, query, update, delete, and other operations on the data in the files. The so-called "database" is a collection of data that is stored together in a certain way, can be shared with multiple users, has as little redundancy as possible, and is independent of the application.

Database Management System (DBMS): A computer software system designed to manage databases, generally with basic functions such as storage, retrieval, security, and backup. Database management systems can be classified according to the database model they support, such as relational, XML (Extensible Markup Language); or according to the type of computer they support, such as server clusters, mobile phones; or according to the query language used, such as Structured Query Language (SQL), XQuery; or according to performance focus, such as maximum scale, maximum operating speed; or other classification methods. Regardless of the classification method used, some DBMS can cross categories, for example, supporting multiple query languages at the same time.

Distributed transaction: refers to the transaction participants, servers supporting the transaction, resource servers and transaction managers located on different nodes of different distributed systems. In the implementation of this application, the distributed transaction includes: transactions that operate on data items on different nodes.

Lock contention duration: the duration from when a transaction acquires a lock on a data item to when it releases the lock during the execution phase, that is, the difference between the time when the transaction unlocks the data item and the time when the transaction locks the data item.

Database Schema Definition Language: (Data Definition Language, referred to as DDL), is a language used to describe real-world entities to be stored in a database.

Database operation statements: (Data Manipulation Language, referred to as DML), are used to update data records in the database table. The basic operation keywords include: insert, delete, and update.

2PL: Two-phase locking protocol, including shared lock (S-Lock) and exclusive lock (X-Lock). Read operations add shared locks to data items, and write operations add exclusive locks to data items.

The design concept of the embodiments of the present application is introduced below.

In the traditional business model, transactions focus on data access in a single data center. As business models change, distributed transactions that operate on data items across data centers are becoming more and more common.

Referring to FIG. 1A , the distributed transaction processing process includes: an execution phase, a preparation phase, and a submission phase.

In the execution phase, database node N1 (coordinating node) divides distributed transaction _T1 into multiple subtransactions (subtransaction _T11 , subtransaction _T12 , subtransaction _T13 ). Database node N1 executes subtransaction _T11 locally, sends subtransaction _T12 to database node N2 (participating node), and sends subtransaction _T13 to database node N3 (participating node). Participating nodes execute subtransactions according to the concurrency control protocol; if 2PL is used as the concurrency control protocol, participating nodes will lock the data items corresponding to the subtransactions in the execution phase.

After the execution phase, a two-phase commit protocol (2PC) is used to ensure database consistency. The two-phase commit protocol divides transaction commit into two phases: preparation phase and commit phase.

In the preparation phase, database node N1 sends a collection request to database node N2 and database node N3. Database node N1 receives the execution results of the sub-transactions returned by database node N2 and database node N3 respectively.

In the commit phase, if the execution result of the sub-transaction returned by at least one of database node N2 and database node N3 is: execution failure, the final state of the distributed transaction is set to: rollback state, and database node N2 and database node N3 are notified to perform a rollback operation on the sub-transaction.

If the execution results returned by database node N2 and database node N3 received by database node N1 are both: execution successful, the final state of the distributed transaction is set to: committed state.

Database node N1 sends the final status of the distributed transaction to database node N2 and database node N3, and database node N2 and database node N3 unlock the data items corresponding to the sub-transactions respectively.

From the above distributed transaction processing process, it can be seen that in the execution phase, subtransaction T ₁₂ and subtransaction T ₁₃ need to go through a round trip time (RTT) to complete execution. In the preparation phase, subtransaction T ₁₂ and subtransaction T ₁₃ also go through a round trip time. In the submission phase, database node N1 (coordinating node) determines the final state (committed state or rollback state) of the distributed transaction according to the execution state of each subtransaction. The coordinating node sends the final state of the distributed transaction to each participating node, and each participating node unlocks the corresponding data item (i.e. releases the lock) only after receiving the final state.

That is to say, without changing the distributed transaction execution logic, the main reasons affecting the performance of distributed transaction processing include: network delays in multiple rounds of TCP/IP network communications and local execution delays of sub-transactions in high-contention scenarios. In cross-space domain scenarios, distributed transactions may involve different participating nodes, and the network delays between different participating nodes and the coordination node cannot be ignored and vary greatly (for example, the round-trip delay between database node N1 and database node N2 is much smaller than the round-trip delay between database node N1 and database node N3).

When a transaction is committed using the two-phase commit protocol, the reference node corresponding to the fastest subtransaction (such as subtransaction T ₁₁ in FIG. 1A ) needs to wait for the reference node corresponding to the slowest subtransaction (such as subtransaction T ₁₃ in FIG. 1A ) to return the execution result before unlocking the locked data item. This introduces unnecessary lock contention time to the fastest subtransaction due to waiting for the slowest subtransaction; and during the period when the fastest subtransaction locks the data item, other distributed transaction operations cannot operate on the data item, causing other distributed transactions to wait. When the number of distributed transactions is large (i.e., in a high contention scenario), the number of blocked or rolled back distributed transactions will also increase, thereby affecting the throughput performance of the distributed database.

By analyzing the distributed transaction processing process, it can be seen that premature execution of subtransactions with shorter network delays increases the lock contention time of these subtransactions on data items. Therefore, if the execution time of subtransactions with shorter network delays is appropriately delayed without increasing the total execution time of distributed transactions, the lock contention time of these delayed subtransactions on data items can be effectively reduced, thereby reducing the number of blocked or rolled back distributed transactions and improving the throughput performance of distributed databases.

In view of this, an embodiment of the present application provides a distributed transaction processing method, which is executed by a coordination node and includes the following steps: dividing a distributed transaction into multiple sub-transactions, each sub-transaction corresponds to a participating node; for multiple sub-transactions, performing the following operations respectively: based on the network delay between a participating node corresponding to a sub-transaction and the coordination node, obtaining the target sending delay corresponding to the sub-transaction, and the target sending delay is negatively correlated with the network delay. Then, according to the obtained multiple target sending delays, the multiple sub-transactions are respectively sent to the corresponding participating nodes for transaction processing. Finally, based on the sub-transaction processing messages returned by the participating nodes corresponding to each of the multiple sub-transactions, the processing status of the distributed transaction is obtained.

In an embodiment of the present application, after receiving a distributed transaction, the coordinating node first divides the distributed transaction into sub-transactions executed on different participating nodes. For each sub-transaction, based on the network delay between the participating node and the coordinating node corresponding to the sub-transaction, the target sending delay of the coordinating node when sending the sub-transaction is determined. Since the target sending delay corresponding to the sub-transaction is negatively correlated with the network delay corresponding to the sub-transaction, the longer the corresponding network delay of the sub-transaction, the shorter the corresponding target sending delay, that is, the earlier the coordinating node will send the sub-transaction to the corresponding participating node for transaction processing; for the shorter the network delay of the sub-transaction, the longer the corresponding target sending delay, that is, the later the coordinating node will send the sub-transaction to the corresponding participating node for transaction processing.

For subtransactions with shorter network delays, since the target sending delay of the coordinating node when sending the subtransaction is longer, the execution time of the subtransaction is later. Therefore, before the subtransaction is executed, there is no need to lock the data items corresponding to the subtransaction, so these data items can be operated by other distributed transactions, thereby reducing the lock contention time of the subtransactions with shorter network delays for the data items.

At the same time, since the network delay of this sub-transaction is relatively short, the time when the corresponding execution result arrives at the coordination node is not much different from the time when the execution result of the sub-transaction with a longer network delay arrives at the coordination node. This reduces the lock contention time of hot data without affecting the execution of distributed transactions, thereby improving the throughput performance and concurrency of the distributed system.

Refer to Figure 1B, which is a system architecture diagram applicable to an embodiment of the present application. The system architecture at least includes a client 101 and a server 102. The number of clients 101 can be one or more, and the number of servers 102 can also be one or more. The present application does not specifically limit the number of clients 101 and servers 102.

Applications are pre-installed in the client 101, where the applications are client applications, web applications, mini-program applications, etc. The client 101 includes but is not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc.

The server 102 may be an independent physical server, or a server cluster or distributed system or distributed database composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. The client 101 and the server 102 may be directly or indirectly connected via wired or wireless communications, which is not limited in this application.

The distributed transaction processing method in the embodiment of the present application can be executed by the client 101, or by the server 102, or by the client 101 and the server 102 interacting with each other, and this application does not make specific limitations on this. The embodiment of the present invention can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc.

In some embodiments, the server 102 includes multiple database nodes, and the multiple database nodes include a coordination node 201 and multiple participating nodes 202. It should be noted that the coordination node 201 can also be a participating node.

In addition, the coordination node may be obtained through election from multiple database nodes, or may be pre-set. Any two database nodes may be directly or indirectly connected via wired or wireless means, and this application does not limit this.

The coordination node 201 receives the distributed transaction sent by the client 101, divides the distributed transaction into multiple sub-transactions, and then distributes the multiple sub-transactions to each participating node 202 for transaction processing. The coordination node 201 receives the execution results returned by each participating node 202, determines the execution result of the distributed transaction based on the returned execution results, and returns the execution result of the distributed transaction to the client 101.

In practical applications, the distributed transaction processing method in the embodiment of the present application is applicable to cross-space domain transaction processing under any system architecture.

For example, referring to FIG. 3 , a system architecture diagram of an enterprise-level distributed database provided in an embodiment of the present application is shown. The system architecture includes:

Front-end application interface 301, gateway system 302, scheduling service 303, decision service 304, multiple database nodes 305, each database node 305 includes a host and at least one backup. The host or backup in the database node 305 can refer to a MySQL instance for storing business data.

The enterprise-level distributed database is a distributed database implemented through a sub-library and sub-table architecture. A large table is divided into each database node 305 for storage through the primary key. Each database node 305 horizontally divides the logical large table, so that the data on each database node 305 is independent and has no relationship with other database nodes 305. If there is a cross-database node transaction, it is supported by XA/2PC technology to ensure the atomicity and consistency of data during write operations.

In an enterprise-level distributed database, the decision service 304 is a management and scheduling center, which mainly includes the following functions: scheduling DDL operations, controlling database node master-slave switching, controlling database node capacity expansion and contraction, controlling data migration, and solving its own faults.

The function of scheduling DDL operations is specifically as follows: the gateway system 302 receives the operation request sent by the client through the front-end application interface 301. When the gateway system 302 identifies the DDL operation from the operation request, it saves the DDL operation in the scheduling service 303 in the form of a DDL task. The decision service 304 pulls the DDL task from the scheduling service 303 and sends the DDL task to the MySQL instance (host or backup) of the database node 305 for execution. After the MySQL instance in the database node 305 is executed, the corresponding response message is sent to the gateway system 302. The gateway system 302 collects the response messages fed back by the MySQL instance, and after combining and processing the collected response messages, returns them to the client through the front-end application interface 301.

The function of controlling the active/standby switching of the database node is specifically as follows: the database node 305 reports the status information of the master and standby machines to the scheduling service 303. The decision service 304 pulls the status information of the master and standby machines from the scheduling service 303. Based on the acquired status information, the decision service 304 determines that when the master in the database node 305 fails, selects the standby machine as the new master, and notifies the new master and other standby machines.

The function of controlling the capacity expansion and contraction of the database node is specifically as follows: when the decision service 304 detects a MySQL instance failure in the database node 305, the database node 305 is automatically expanded. In addition, the decision service 304 detects the resource utilization of each MySQL instance in the database node 305, and determines whether to expand or reduce the capacity of the MySQL instance based on the resource utilization.

The control data migration function is specifically as follows: the decision service 304 sends the data migration task to the database node 305 through the scheduling service 303. The original instance in the database node 305 copies the backup image to the target instance and returns a response message to the decision service 304. The decision service 304 notifies the gateway system 302 to modify the route to the target instance, and sends an instruction to delete the old data to the database node 305, and the original instance in the database node 305 deletes the old data.

The fault resolution function thereof is specifically as follows: when the decision service 304 fails, the coordination service 303 elects a new decision service 304 as the management and scheduling center to achieve disaster recovery.

Next, the functions of the scheduling service 303, the gateway system 302 and the database node 305 are introduced:

The scheduling service 303 is a resource management center of an enterprise-level distributed database, and is used to store data such as DDL tasks reported by the gateway system 302, status information of the master and backup machines reported by the database node 305, and data migration tasks. In actual applications, the scheduling service 303 is a single distributed application coordination service (ZooKeeper), or a ZooKeeper cluster.

The gateway system 302 is the middleware for database node access, which specifically includes: routing function, user authentication function, detection function, etc.

In addition to the aforementioned storage of DDL operations in the form of DDL tasks in the scheduling service 303, the routing function also includes a routing function for DML operations. Specifically, when the gateway system 302 identifies a DML operation from an operation request, it performs a sql conversion on the DML operation to obtain a conversion operation. The gateway system 303 pulls real-time routing information, and based on the real-time routing information, sends the conversion operation to the corresponding MySQL instance in the database node 305 for execution. After the MySQL instance in the database node 305 is executed, the corresponding response message is sent to the gateway system 302. The gateway system 302 collects the response messages fed back by the MySQL instance in the database node 305, and after combining and processing the collected response messages, returns them to the client through the front-end application interface 301.

The user authentication function is specifically as follows: relevant authority information is obtained in advance, and when the gateway system 302 establishes a connection with the client, the user name and password for establishing the connection are verified based on the authority information.

Detection function: detect the status of the dispatch service 303 in real time, and trigger an alarm when an abnormality is detected in the dispatch service 303.

Each MySQL instance in the database node 305 includes the following functions: detecting its own status information and reporting the status information to the scheduling service 303, participating in the data migration process and the master-slave switching process described above, etc. The relevant functions of the database node 305 have been introduced in detail in the above description of the functions of the gateway system 302, the scheduling service 303, and the decision service 304, and will not be repeated here.

In the above-mentioned enterprise-level distributed database, there are a large number of distributed transactions across database nodes. When the distributed transaction processing method in the embodiment of the present application is used for scheduling and processing, the distributed transaction performance of distributed databases such as enterprise-level distributed databases can be improved, so that distributed databases such as enterprise-level distributed databases can meet the performance requirements of current Internet applications for databases, thereby improving product competitiveness.

The following is a detailed description of a process of a distributed transaction processing method provided by an embodiment of the present application. As shown in FIG4 , the process of the method is executed by a computer device, which may be the coordination node 201 shown in FIG2 or the database node 305 shown in FIG3 , and includes the following steps:

Step S401, divide the distributed transaction into multiple sub-transactions, each sub-transaction corresponds to a participating node.

Specifically, a distributed transaction includes multiple transaction operations, which are performed on data items on different database nodes. Therefore, after the server receives the distributed transaction sent by the client, the coordination node in the server divides the distributed transaction into multiple sub-transactions and distributes the multiple sub-transactions to the corresponding participating nodes.

In some embodiments, the coordinating node divides the distributed transaction into multiple sub-transactions based on the participating nodes corresponding to each of the multiple data items associated with the distributed transaction, wherein each sub-transaction corresponds to at least one data item and each sub-transaction corresponds to a participating node.

Specifically, the data items corresponding to multiple transaction operations in the distributed transaction are located at different participating nodes. In order to facilitate transaction operations, the transaction operations corresponding to the data items located at the same participating node can be merged into a sub-transaction to achieve the division of the distributed transaction.

For example, it is assumed that the server includes three database nodes, namely database node N1, database node N2 and database node N3, wherein database node N1 is a coordination node and also a participating node, and database node N2 and database node N3 are both participating nodes.

Data item x and data item y are located at database node N1, data item z is located at database node N2, and data item v and data item u are located at database node N3.

The transaction operation sequence in distributed transaction T1 is: R ₁ (x) W ₁ (y) W ₁ (z) R ₁ (v) W ₁ (u), where R ₁ (x) means reading data item x, W ₁ (y) means modifying data item y, W ₁ (z) means modifying data item z, R ₁ (v) means reading data item v, and W ₁ (u) means modifying data item u.

Since data item x and data item y are located in database node N1, the transaction operation for data item x and data item y is regarded as a sub-transaction _T11 , and the transaction operation sequence in sub-transaction _T11 is: _R1 (x) _W1 (y).

Since the data item z is located in the database node N2, the transaction operation for the data item z is taken as a sub-transaction T _12. The transaction operation in the sub-transaction T ₁₂ includes: W ₁ (z).

Since data item v and data item u are located in database node N3, the transaction operation for data item v and data item u is regarded as a sub-transaction T ₁₃ , and the transaction operation sequence in sub-transaction T ₁₃ is: R ₁ (v) W ₁ (u).

In an embodiment of the present application, a distributed transaction is divided into multiple sub-transactions, and the multiple sub-transactions are respectively sent to different participating nodes for transaction processing, so that multiple sub-transactions can be processed in parallel, thereby effectively improving the processing efficiency of distributed transactions.

Step S402, for multiple sub-transactions, respectively perform the following operations: based on the network delay between the participating node and the coordinating node corresponding to a sub-transaction, obtain the target sending delay corresponding to the sub-transaction.

Specifically, due to the premature execution of subtransactions with shorter network delays, the lock contention duration of these subtransactions on data items is increased. Therefore, under the premise that the execution delay of subtransactions executed locally by participating nodes is much less than the network delay between database nodes across spatial domains, by delaying the execution of subtransactions with shorter network delays, the lock contention duration of these subtransactions with shorter network delays on data items can be effectively reduced. In view of this, in the embodiment of the present application, the target sending delay is negatively correlated with the network delay, and the target sending delay corresponding to the subtransaction is obtained based on the network delay between the participating nodes and the coordinating node corresponding to the subtransaction.

In some embodiments, among the multiple subtransactions corresponding to the distributed transaction, the network delay corresponding to the slowest subtransaction is greater than the network delays of other subtransactions, and the network delay corresponding to the slowest subtransaction is substantially the maximum network delay in the distributed transaction. The maximum network delays in different distributed transactions are different.

For the same starting time, the larger the maximum network delay in a distributed transaction, the later the execution result of the corresponding slowest subtransaction arrives at the coordination node, and the execution results of other subtransactions can also arrive at the coordination node later; that is, the target sending delay of other subtransactions can also be set larger. On the contrary, the smaller the maximum network delay in a distributed transaction, the earlier the execution result of the corresponding slowest subtransaction arrives at the coordination node, and the execution results of other subtransactions need to arrive at the coordination node earlier; that is, the target sending delay of other subtransactions needs to be set smaller.

In view of this, in an embodiment of the present application, the network delays between the participating nodes corresponding to each of the multiple sub-transactions and the coordinating node are obtained, and then the maximum network delay is obtained from the network delays corresponding to each of the multiple sub-transactions. Based on the maximum network delay and the network delay corresponding to a sub-transaction, the target sending delay corresponding to the sub-transaction is obtained, wherein the delay difference between the maximum network delay and the network delay corresponding to a sub-transaction is positively correlated with the target sending delay of the sub-transaction.

In the embodiment of the present application, the delay difference between the maximum network delay of the distributed transaction and the network delay corresponding to the subtransaction is obtained, and the target sending delay corresponding to each subtransaction in the distributed transaction is determined based on the obtained delay difference being positively correlated with the target sending delay of the subtransaction. Then, for a distributed transaction with a longer maximum network delay, the sending delay of other subtransactions except the slowest subtransaction is longer, and the corresponding lock contention time for the associated data item is shorter, thereby reducing the number of distributed transactions that are blocked or rolled back and improving the throughput performance of the distributed database.

In some embodiments, when delaying the execution of a sub-transaction with a shorter network delay, relevant constraints also need to be set. For example, the time when the execution result of the delayed sub-transaction arrives at the coordination node cannot be later than the time when the execution result of the slowest sub-transaction arrives at the coordination node.

In order to minimize the lock contention duration of distributed transactions and satisfy relevant constraints, the embodiment of the present application adopts the following method to determine the target sending delay corresponding to the sub-transaction:

First, the lock contention duration of distributed transaction T is expressed by the following formula (1):

Wherein, W represents the lock contention duration of distributed transaction T, _ki represents the data item that distributed transaction T needs to operate, T.ws represents the set of data items on which distributed transaction T performs write operations (modification operations), T.rs represents the set of data items on which distributed transaction T performs read operations, UnLock( _ki ) represents the moment when distributed transaction T unlocks data item _ki , and Lock( _ki ) represents the moment when distributed transaction T locks data item _ki .

Since the coordinating node needs to receive the execution results corresponding to all sub-transactions before triggering each participating node to unlock the locked data items respectively, and the execution delay of the participating node executing the sub-transaction locally is much smaller than the network delay between database nodes across the spatial domain (that is, the execution delay of the participating node executing the sub-transaction locally is negligible), the total execution delay of the distributed transaction T is expressed as the following formula (2):

D(T)＝2·max{τ _c,j }......(2)

Where D(T) represents the total execution delay of distributed transaction T, and τc _,j represents the network delay between the coordinating node _Nc and the participating nodes _Nj .

Lock(k _i ) can be further expressed as the following formula (3):

Wherein, DelayTime(k _i ) represents the sending delay corresponding to the subtransaction where the data item k _i is located, and node(k _i ) represents the participating node that executes the subtransaction where the data item k _i is located.

UnLock(k _i ) can be further expressed as the following formula (4):

Wherein, node(k _i ) represents the participating node that executes the subtransaction where data item k _i is located.

Based on the above formula (3) and formula (4), the above formula (1) is rewritten as the following formula (5):

Taking minimizing the lock contention time W of distributed transaction T as the optimization goal, and taking the time when the execution result of each sub-transaction arrives at the coordination node before the total execution delay D(T) of distributed transaction T as the constraint condition, the following formula (6) is constructed:

Since 2·max{τ _c,j } is a constant, formula (6) can be further rewritten as the following formula (7):

Combining the optimization objective and constraint conditions in formula (7) yields the following formula (8):

It can be seen from the above formula (8) that when the formula (8) takes the equal sign, the optimization target obtains the maximum value. Assuming that the data item k _i belongs to the subtransaction _ti , the calculation formula for the target sending delay of the subtransaction _ti can be obtained as shown in the following formula (9):

Wherein, DelayTime(t _i ) represents the target sending delay of subtransaction t _i .

It can be seen from the above formula (9) that in the distributed transaction processing process, the execution delay of the local execution of the sub-transaction by the participating node is negligible. The coordinating node obtains the total execution delay corresponding to a sub-transaction based on the network delay between the participating node and the coordinating node corresponding to the sub-transaction. The total execution delay of the distributed transaction is obtained based on the maximum network delay in the distributed transaction. The delay difference between the total execution delay of the distributed transaction and the total execution delay corresponding to the sub-transaction is then used as the target sending delay corresponding to the sub-transaction.

Specifically, when the execution delay of the subtransaction executed locally by the participating nodes is ignored, the total execution delay corresponding to the subtransaction refers to: the round-trip delay between the coordinating node and the participating nodes processing the subtransaction, that is, twice the network delay between the coordinating node and the participating nodes; the total execution delay of the distributed transaction refers to: the round-trip delay between the coordinating node and the participating node processing the slowest subtransaction, that is, twice the maximum network delay in the distributed transaction. The delay difference between the total execution time of the distributed transaction and the total execution delay corresponding to the subtransaction is used as the target sending delay corresponding to the subtransaction.

For example, assume that the server includes three database nodes, namely database node N1, database node N2 and database node N3, where database node N1 is a coordination node and also a participating node, and database node N2 and database node N3 are participating nodes. The network delay between database node N1 and database node N2 is 10ms, and the network delay between database node N1 and database node N3 is 30ms.

Database node N1 receives the distributed transaction T1 sent by the client. The transaction operations in the distributed transaction T1 include: R ₁ (x) W ₁ (y) W ₁ (z) R ₁ (v) W ₁ (u), where R ₁ (x) represents reading data item x, W ₁ (y) represents modifying data item y, W ₁ (z) represents modifying data item z, R ₁ (v) represents reading data item v, and W ₁ (u) represents modifying data item u.

Distributed transaction T1 is divided into subtransaction _T11 , subtransaction _T12 , and subtransaction _T13 , wherein the transaction operation in subtransaction _T11 includes: _R1 (x) _W1 (y), the transaction operation in subtransaction _T12 includes: _W1 (z), and the transaction operation in subtransaction _T13 includes: _R1 (v) _W1 (u). Subtransaction _T11 is executed locally by database node N1, subtransaction _T12 is executed by database node N2, and subtransaction _T13 is executed by database node N3.

When the execution delay of the subtransaction executed locally on the database node is ignored, the total execution delay of the distributed transaction T1 is: 2·max{τ _c,j }=60ms. Then, based on the above formula (9), it can be known that the target sending delay of subtransaction _T11 is DelayTime( _T11 )=60-0=60ms; the target sending delay of subtransaction _T12 is DelayTime( _T12 )=60-20=40ms; the target sending delay of subtransaction _T13 is DelayTime( _T13 )=60-60=0ms.

That is, database node N1 sends subtransaction _T13 to database node N1 for transaction processing at 0 ms. Database node N1 sends subtransaction _T12 to database node N2 for transaction processing at 40 ms. Database node N1 executes subtransaction _T11 locally at 60 ms.

In an embodiment of the present application, the delay difference between the total execution time of a distributed transaction and the total execution delay corresponding to a subtransaction is used as the target sending delay corresponding to the subtransaction, so that the lock contention duration of the distributed transaction is minimized when the execution result of each subtransaction arrives at the coordination node before the total execution delay of the distributed transaction, thereby effectively reducing the lock contention duration of related data items and improving the throughput performance and concurrency of the distributed system.

In some embodiments, in a scenario with a high conflict rate, the execution delay of the participating node executing the subtransaction locally will be correspondingly longer. Therefore, in this scenario, the execution delay of the participating node executing the subtransaction locally cannot be ignored. In order to improve the accuracy of determining the target sending delay of the subtransaction, in an embodiment of the present application, based on the network delay corresponding to a subtransaction and the execution delay of the participating node executing the subtransaction locally corresponding to the subtransaction, the target sending delay corresponding to the subtransaction is obtained.

Specifically, the network delay corresponding to the subtransaction is summed with the local execution delay of the subtransaction to obtain the total execution delay corresponding to the subtransaction. Then, based on the negative correlation between the total execution delay corresponding to the subtransaction and the target sending delay corresponding to the subtransaction, the target sending delay corresponding to the subtransaction is determined.

In the embodiment of the present application, by postponing the sub-transactions with shorter total execution time and executing the sub-transactions with longer total execution time in advance, the sub-transactions with shorter total execution time are reduced without affecting the total execution time of the distributed transaction, and the lock contention time for the data item is reduced, thereby reducing the number of times other sub-transactions are blocked, and improving the throughput performance and concurrency of the distributed system.

Step S403: according to the obtained multiple target sending delays, the multiple sub-transactions are respectively sent to the corresponding participating nodes for transaction processing.

Specifically, for each participating node, the participating node receives a sub-transaction sent by the coordinating node, wherein the sub-transaction includes: transaction operations on data items in the participating node, and the types of transaction operations include but are not limited to: read operations (Read), modification or write operations (Write).

When the transaction operation is a read operation, the participating node accesses the local lock table and adds a shared lock SH to the data item corresponding to the read operation. When the transaction operation is a modification operation, the participating node accesses the local lock table and adds an exclusive lock EX to the data item corresponding to the modification operation.

Before adding an exclusive lock EX to a data item, if the data item has been locked by other transactions, the distributed transaction is added to the waiting queue of the data item. When other transactions release the lock, an exclusive lock EX is added to the data item.

After the participating nodes complete the transaction operations in the subtransaction on the data items, they return the subtransaction execution results and the lock success message to the coordinating node.

For example, referring to FIG5 , it is assumed that the server includes three database nodes, namely database node N1, database node N2 and database node N3, wherein database node N1 is a coordination node and also a participating node, and database node N2 and database node N3 are participating nodes.

Database node N1 receives distributed transaction T1 sent by the client. The transaction operations in distributed transaction T1 include: Read(X) and Write(Y), where Read(X) represents reading data item X and Write(Y) represents modifying data item Y. Database node N1 divides distributed transaction T1 into: subtransaction _T11 and subtransaction _T12 .

The locking process of distributed transaction T1 is shown in Figure 5, which includes the following steps:

①. Database node N1 sends subtransaction _T11 to database node N2.

②. Database node N1 sends subtransaction _T12 to database node N3.

③ After receiving subtransaction _T11 , database node N2 accesses the local lock table and locks data item X (the version of data item X in database node N2 is _X0 at this time), changes the lock type of data item X in the local lock table to shared lock SH, and changes the lock owner in the local lock table to distributed transaction T1.

④. After database node N3 receives subtransaction _T12 , since data item Y is currently locked with shared lock SH by distributed transaction T0 (the version of data item Y in database node N3 is _Y0 at this time), distributed transaction T1 is added to the waiting queue of data item Y as a waiter.

⑤. After distributed transaction T0 releases the lock of data item Y, database node N3 performs the following operations on the local lock table: changes the lock type of data item Y from shared lock SH to exclusive lock EX, changes the lock owner from distributed transaction T0 to distributed transaction T1, and changes the waiter from distributed transaction T1 to 0.

⑥ After executing subtransaction _T11 , database node N2 returns data item X and a lock success message to the coordinating node.

⑦. After executing subtransaction _T12 , database node N3 returns the modification success message and the locking success message to the coordination node.

Step S404: obtaining the processing status of the distributed transaction based on the sub-transaction processing messages returned by the participating nodes corresponding to the multiple sub-transactions.

Specifically, the processing status of a distributed transaction includes: a commit status and a rollback status.

The coordinating node combines the execution results of multiple sub-transactions to determine the execution result of the distributed transaction and returns the execution result of the distributed transaction to the client.

Taking the system architecture shown in FIG3 as an example, the gateway system 302 receives an operation request sent by the client through the front-end application interface 301. When the gateway system 302 identifies a DML operation from the operation request, it performs sql conversion on the DML operation to obtain a conversion operation. The gateway system 303 pulls real-time routing information and sends the conversion operation to the corresponding database node 305 (i.e., the coordination node) based on the real-time routing information. Since the conversion operation includes transaction operations for data items on different database nodes, the database node 305 (i.e., the coordination node) that receives the conversion operation divides the conversion operation into multiple sub-transactions, and then uses any one of the embodiments described above to determine the target sending delay of each sub-transaction. According to the obtained multiple target sending delays, the multiple sub-transactions are sent to the corresponding database node 305 (i.e., the participating node) for transaction processing. The database node 305 (i.e., the coordination node) collects the execution results of the multiple sub-transactions, determines the execution results of the conversion operation based on the execution results of the multiple sub-transactions, and then sends the execution results of the conversion operation to the gateway system 302. The gateway system 302 returns the execution result to the client through the front-end application interface 301 .

In an embodiment of the present application, after receiving a distributed transaction, the coordinating node first divides the distributed transaction into sub-transactions executed on different participating nodes. For each sub-transaction, based on the network delay between the participating node and the coordinating node corresponding to the sub-transaction, the target sending delay of the coordinating node when sending the sub-transaction is determined. Since the target sending delay corresponding to the sub-transaction is negatively correlated with the network delay corresponding to the sub-transaction, the longer the corresponding network delay of the sub-transaction, the shorter the corresponding target sending delay, that is, the earlier the coordinating node will send the sub-transaction to the corresponding participating node for transaction processing; for the shorter the network delay of the sub-transaction, the longer the corresponding target sending delay, that is, the later the coordinating node will send the sub-transaction to the corresponding participating node for transaction processing.

For subtransactions with shorter network delays, since the target sending delay of the coordinating node when sending the subtransaction is longer, the execution time of the subtransaction is later. Therefore, before the subtransaction is executed, there is no need to lock the data items corresponding to the subtransaction, so these data items can be operated by other distributed transactions, thereby reducing the lock contention time of the subtransactions with shorter network delays for the data items.

At the same time, since the network delay of this sub-transaction is relatively short, the time when the corresponding execution result arrives at the coordination node is not much different from the time when the execution result of the sub-transaction with a longer network delay arrives at the coordination node. This reduces the lock contention time of hot data without affecting the execution of distributed transactions, thereby improving the throughput performance and concurrency of the distributed system.

In some embodiments, the coordinating node sends multiple sub-transactions to corresponding participating nodes for transaction processing according to the obtained multiple target sending delays, and then sends collection requests to the participating nodes corresponding to each of the multiple sub-transactions. The collection requests are used to instruct the participating nodes to return the execution results of the corresponding sub-transactions.

The coordinating node receives the sub-transaction processing messages returned by the participating nodes corresponding to the multiple sub-transactions, and the sub-transaction processing messages include: the execution results of the sub-transactions. When the execution results corresponding to the multiple sub-transactions are all: execution success, the processing state of the distributed transaction is determined to be: commit state.

Specifically, when the server receives the commit request sent by the client, it enters the preparation phase. In the preparation phase, the coordinating node sends a collection request to the participating nodes corresponding to each of the multiple sub-transactions. The coordinating node receives the execution results of the sub-transactions returned by each participating node.

In the commit phase, when the execution results of each sub-transaction are all successful, the processing state of the distributed transaction is set to the commit state. When the execution result of the sub-transaction returned by at least one participating node is execution failure, the processing state of the distributed transaction is set to the rollback state.

In some embodiments, in a distributed database, different data items will be mapped to different partitions, and high availability is ensured between partitions through multiple copies. If the database node uses a two-phase commit protocol for concurrency control, the two-phase commit protocol includes two stages: a preparation stage and a commit stage. However, in the execution stage, the participating nodes will send the situation of the sub-transaction acquiring the lock to the coordination node, and when the sub-transaction successfully obtains the lock of the corresponding data item, the participating node can perform the data operation in the sub-transaction on the data item to obtain the execution result. Therefore, the coordination node can actually determine the processing status of the transaction based on the situation of each sub-transaction acquiring the lock, that is, merge the execution stage and the preparation stage into one stage.

In view of this, the coordinating node receives the sub-transaction processing messages returned by the participating nodes corresponding to each of the multiple sub-transactions; for the multiple sub-transactions, the following operations are performed respectively: from the sub-transaction processing message corresponding to a sub-transaction, the lock contention status of the data item associated with the sub-transaction is obtained. If the lock contention status corresponding to each of the multiple sub-transactions is: the associated data item has been locked, then the processing status of the distributed transaction is determined to be: committed status.

If the lock contention state of at least one sub-transaction among the lock contention states corresponding to the plurality of sub-transactions is: waiting state, then the processing state of the distributed transaction is determined to be: rollback state.

In an embodiment of the present application, after the execution phase ends, the coordinating node directly determines the processing status of the distributed transaction based on the lock contention status of the data items associated with the sub-transactions reported by all participating nodes. Compared with the two-phase commit protocol, a round-trip delay is reduced between the coordinating node and each participating node, thereby improving the distributed transaction processing efficiency, while reducing the lock contention duration of the distributed transaction and improving the performance of the distributed database.

In some embodiments, using any of the above implementations, after determining the processing status of the distributed transaction, the processing status of the distributed transaction is sent to the participating nodes corresponding to each of the multiple sub-transactions, so that each participating node unlocks the corresponding data item.

Specifically, the coordinating node sends an unlocking request to each participating node. After receiving the unlocking request, the participating node unlocks the corresponding data item and returns the unlocking message to the coordinating node.

For example, the unlocking process of distributed transaction T1 is shown in Figure 6, which includes the following steps:

①. Database node N1 sends an unlock request to database node N2.

②. Database node N1 sends the unlock request to database node N3.

③. Database node N2 accesses the local lock table and unlocks data item X.

Specifically, the following operations are performed on the local lock table: the lock type of the data item X is changed from the shared lock SH to 0, and the lock owner is changed from the distributed transaction T1 to 0.

④. Database node N3 accesses the local lock table and unlocks data item Y.

Specifically, the following operations are performed on the local lock table: the lock type of the data item Y is changed from the exclusive lock EX to the shared lock SH, the lock owner is changed from the distributed transaction T1 to the distributed transaction Tx, and the waiter is changed from the distributed transaction Tx to 0.

⑤. Database node N2 returns the unlock success message to the coordination node.

⑥. Database node N3 returns the unlock success message to the coordination node.

In an embodiment of the present application, without additionally increasing the total execution time of the distributed transaction, the execution time of the sub-transaction with shorter network delay (fast sub-transaction) is appropriately delayed, so that the fast sub-transaction and the sub-transaction with longer network delay (slow sub-transaction) can return the execution results to the coordination node at basically the same time, thereby triggering the unlocking of the data items corresponding to the fast sub-transaction and the slow sub-transaction, which effectively reduces the unnecessary lock contention time caused by the fast sub-transaction waiting for the slow sub-transaction, thereby improving the processing performance of the distributed transaction.

In order to better explain the embodiments of the present application, a distributed transaction processing method provided by the embodiments of the present application is introduced below in combination with a specific implementation scenario. The process of the method can be interactively executed by the client 101 and the server 102 shown in Figure 1B.

The server includes three database nodes, namely database node N1, database node N2 and database node N3, among which database node N1 is a coordination node and also a participating node; database node N2 and database node N3 are participating nodes. The network delay between database node N1 and database node N2 is 10ms, and the network delay between database node N1 and database node N3 is 30ms.

Database node N1 receives four transaction requests sent by the client, namely distributed transaction T1, distributed transaction T2, distributed transaction T3 and single-machine transaction T4.

The transaction operations in the distributed transaction T1 include: R ₁ (x) W ₁ (y) W ₁ (z) R ₁ (v) W ₁ (u), where R ₁ (x) represents reading data item x, W ₁ (y) represents modifying data item y, W ₁ (z) represents modifying data item z, R ₁ (v) represents reading data item v, and W ₁ (u) represents modifying data item u.

The transaction operations in the distributed transaction T2 include: R ₂ (x) W ₂ (y) W ₂ (z), where R ₂ (x) represents reading data item x, W ₂ (y) represents modifying data item y, and W ₂ (z) represents modifying data item z.

The transaction operations in the distributed transaction T3 include: R ₃ (x)R ₃ (z), where R ₃ (x) represents reading data item x, and R ₃ (z) represents reading data item z.

The transaction operations in the stand-alone transaction T4 include: W ₄ (x), where W ₄ (x) represents modifying the data item x.

For distributed transaction T1, distributed transaction T1 is divided into subtransaction _T11 , subtransaction _T12 , and subtransaction _T13 , wherein the transaction operation in subtransaction _T11 includes: _R1 (x) _W1 (y), the transaction operation in subtransaction _T12 includes: _W1 (z), and the transaction operation in subtransaction _T13 includes: _R1 (v) _W1 (u).

Subtransaction _T11 is executed locally by database node N1, subtransaction _T12 is executed by database node N2, and subtransaction _T13 is executed by database node N3.

When the execution delay of the subtransaction executed locally on the database node is ignored, the total execution delay of the distributed transaction T1 is: 2·max{τ _c,j }=60ms. Then, based on the above formula (9), the target sending delay of subtransaction _T11 is DelayTime( _T11 )=60-0=60ms; the target sending delay of subtransaction _T12 is DelayTime( _T12 )=60-20=40ms; the target sending delay of subtransaction _T13 is DelayTime( _T13 )=60-60=0ms.

For the distributed transaction T2, the distributed transaction T2 is divided into: sub-transaction T ₂₁ and sub-transaction T ₂₂ , wherein the transaction operation in the sub-transaction T ₂₁ includes: R ₂ (x) W ₂ (y), and the transaction operation in the sub-transaction T ₂₂ includes: W ₂ (z).

Subtransaction _T21 is executed locally by database node N1, and subtransaction _T22 is executed by database node N2.

When the execution delay of the subtransaction executed locally on the database node is ignored, the total execution delay of the distributed transaction T2 is: 2·max{τ _c,j }=20ms. Then, based on the above formula (9), the target sending delay of subtransaction T ₂₁ is DelayTime(T ₂₁ )=20-0=20ms; the target sending delay of subtransaction T ₂₂ is DelayTime(T ₂₂ )=20-20=0ms.

With respect to the distributed transaction T3, the distributed transaction T2 is divided into: sub-transaction _T31 and sub-transaction _T32 , wherein the transaction operation in the sub-transaction _T31 includes: _R3 (x), and the transaction operation in the sub-transaction _T32 includes: _R3 (z).

Subtransaction _T31 is executed locally by database node N1, and subtransaction _T32 is executed by database node N2.

When the execution delay of the subtransaction executed locally on the database node is ignored, the total execution delay of the distributed transaction T3 is: 2·max{τ _c,j }=20ms. Then, based on the above formula (9), the target sending delay of subtransaction T ₃₁ is DelayTime(T ₃₁ )=20-0=20ms; the target sending delay of subtransaction T ₃₂ is DelayTime(T ₃₂ )=20-20=0ms.

For the stand-alone transaction T4, the stand-alone transaction T4 is executed locally by the database node N1, and the target sending delay DelayTime( _T4 )=0ms.

After obtaining the target sending delay of each of the above transactions, the following execution process is used to execute each transaction, see FIG7 , including the following steps:

①. Database node N1 sends subtransaction _T13 to database node N3 at time 0ms.

Database node N3 changes the lock owner of data item u and data item v in the local lock table to distributed transaction T1, and then executes the transaction operation in subtransaction _T13 on data item u and data item v to obtain the execution result of subtransaction _T13 . Then, the execution result of subtransaction _T13 is returned to database node N1.

In addition, database node N1 executes stand-alone transaction T4 at time 0 ms.

At this time, data item x is not locked, so the lock owner of data item x in the local lock table is changed to stand-alone transaction T4, and then the transaction operation in stand-alone transaction T4 is executed on data item x to obtain the execution result of stand-alone transaction T4. Since stand-alone transaction T4 does not need to wait for other database nodes to return the execution result, database node N1 can immediately submit the execution result of stand-alone transaction T4 and release the lock of data item x.

②. Database node N1 sends subtransaction T ₂₂ and subtransaction T ₃₂ to database node N2 at time 0 ms.

After receiving subtransaction T ₂₂ and subtransaction T ₃₂ , database node N2 selects one of them for transaction processing. Assume that subtransaction T ₂₂ is processed first, and subtransaction T ₃₂ is put into the waiting queue.

Database node N2 changes the lock owner of data item z in the local lock table to distributed transaction T2, and then executes the transaction operation in subtransaction _T22 on data item z to obtain the execution result of subtransaction _T22 .

③. Database node N2 returns the execution result of subtransaction T ₂₂ to database node N1.

The database node N1 receives the execution result of the subtransaction _T22 returned by the database node N2 at 20 ms.

Database node N1 performs transaction processing on subtransaction T ₂₁ at 20ms. Specifically, database node N1 locks data item x and data item y at 20ms (that is, changes the lock owner of data item x and data item y in the local lock table to distributed transaction T2), and then executes the transaction operation in subtransaction T ₂₁ on data item x and data item y to obtain the execution result of subtransaction T _21. Combined with the execution result of subtransaction T ₂₂ and the execution result of subtransaction T ₂₁ , the processing status of distributed transaction T2 is determined.

Database node N1 changes the lock owner of data item x in the local lock table from distributed transaction T2 to distributed transaction T3, and then executes the transaction operation in subtransaction _T31 on data item x to obtain the execution result of subtransaction _T31 .

④. Database node N1 sends an unlock request to database node N2 at 20ms.

After receiving the unlock request, database node N2 releases the lock of data item z. The lock owner of data item z in the local lock table is changed from distributed transaction T2 to distributed transaction T3, and then the transaction operation in subtransaction _T32 is executed on data item z to obtain the execution result of subtransaction _T32 .

⑤. Database node N2 returns the execution result of subtransaction _T32 to database node N1.

At 40 ms, database node N1 receives the returned execution result of subtransaction _T32 . Based on the execution result of subtransaction _T32 and the execution result of subtransaction _T31 , the processing status of distributed transaction T3 is determined.

⑥. Database node N1 sends an unlock request and subtransaction _T12 to database node N2 at 40ms.

Database node N2 releases the lock of data item z, changes the lock owner of data item z in the local lock table from distributed transaction T3 to distributed transaction T1, and then executes the transaction operation in subtransaction _T12 on data item z to obtain the execution result of subtransaction _T12 .

⑦. Database node N2 returns the execution result of subtransaction _T12 to database node N1.

Database node N1 receives the execution result of subtransaction _T12 returned by database node N2 at 60 ms.

At 60 ms, database node N1 changes the lock owner of data item x and data item y in the local lock table to distributed transaction T1, and then executes the transaction operation in subtransaction _T11 on data item x and data item y to obtain the execution result of subtransaction _T11 .

⑧. Database node N1 receives the execution result of subtransaction _T13 returned by database node N3 at 60ms.

The processing status of distributed transaction T1 is determined based on the execution results of subtransaction _T11 , subtransaction _T12 , and subtransaction _T13 .

Database node N1 sends an unlock request to database node N2 and database node N3, database node N2 releases the lock of data item z, database node N3 releases the locks of data item u and data item v, and database node N1 locally releases the locks of data item x and data item y.

In order to further verify the performance of the technical solution in this application, the following is a comparison of the execution performance of the technical solution in this application (after optimization) and the existing technical solution (before optimization), as shown in Table 1 below:

Table 1

It can be seen from Table 1 above that in the prior art solution (before optimization), distributed transactions T ₂ to T ₄ need to be blocked until distributed transaction T ₁ is executed. In the technical solution (after optimization) in the present application, subtransactions T ₁₁ and T ₁₂ of distributed transaction T ₁ are delayed for execution, so that distributed transactions T ₂ to T ₄ can be executed in advance, and the lock contention duration of distributed transaction T ₁ on data item x, data item y and data item z is reduced without affecting the total execution delay of distributed transaction T ₁ , so that distributed transactions T ₁ to T ₄ can be executed within a shorter delay.

From the perspective of availability, in cross-space domain scenarios, the network latency and differences between database nodes are relatively large. This application delays the execution of some sub-transactions based on the distribution of data items and network latency differences without affecting the total execution latency of distributed transactions, thereby reducing the lock contention duration of hot data and improving the concurrency of the system. It is worth noting that this application does not assume deterministic execution because transactions do not need to be batched. Secondly, for stored procedures that do not have logical predicates, single-statement interactive transactions, and the first statement of multi-statement interactive transactions, the technology proposed in this application can be used for optimization.

In addition, the Distributed Transaction Processing Reference Model (DTP) is also a method for processing cross-domain transactions in current database applications. In the DTP model, the client application connects to each database through the middleware and completes XA/2PC through the transaction manager (TM) to ensure the atomicity and isolation of the transaction. In the DTP model, the middleware is responsible for coordinating the transactions in each database. Based on the perception of the network delay differences of each target node, the middleware uses this application to determine the delay time of the sub-transaction and delay the sending of the sub-transaction, which can also achieve the effect of reducing the lock contention duration and improving the system concurrency. Therefore, this application is still valid in the DTP model.

Based on the same technical concept, an embodiment of the present application provides a structural diagram of a distributed transaction processing device, as shown in FIG8 , the device 800 includes:

A division module 801 is used to divide a distributed transaction into multiple sub-transactions, each sub-transaction corresponds to a participating node;

The processing module 802 is used to perform the following operations respectively for the multiple sub-transactions: based on the network delay between the participating node corresponding to the sub-transaction and the coordinating node, obtain the target sending delay corresponding to the sub-transaction, wherein the target sending delay is negatively correlated with the network delay;

A sending module 803, configured to send the plurality of sub-transactions to corresponding participating nodes for transaction processing respectively according to the obtained plurality of target sending delays;

The processing module 802 is further configured to obtain the processing status of the distributed transaction based on the sub-transaction processing messages returned by the participating nodes corresponding to each of the multiple sub-transactions.

Optionally, the division module 801 is specifically used for:

Based on participating nodes corresponding to each of the multiple data items associated with the distributed transaction, the distributed transaction is divided into multiple sub-transactions, wherein each sub-transaction corresponds to at least one data item and each sub-transaction corresponds to a participating node.

Optionally, the processing module 802 is specifically configured to:

Obtaining network delays between participating nodes corresponding to each of the multiple sub-transactions and the coordinating node;

Obtaining a maximum network delay from the network delays corresponding to the multiple sub-transactions;

Based on the maximum network delay and the network delay corresponding to the subtransaction, a target sending delay corresponding to the subtransaction is obtained, wherein a delay difference between the maximum network delay and the network delay corresponding to the subtransaction is positively correlated with the target sending delay.

Optionally, the processing module 802 is specifically configured to:

Based on the network delay corresponding to the subtransaction, obtaining a total execution delay corresponding to the subtransaction;

Based on the maximum network delay, obtaining a total execution delay of the distributed transaction;

The delay difference between the total execution delay of the distributed transaction and the total execution delay corresponding to the sub-transaction is used as the target sending delay corresponding to the sub-transaction.

Optionally, the processing module 802 is specifically configured to:

Based on the network delay corresponding to the sub-transaction and the execution delay of the participating node corresponding to the sub-transaction locally executing the sub-transaction, a target sending delay corresponding to the sub-transaction is obtained, wherein the execution delay is negatively correlated with the target sending delay.

Optionally, the processing module 802 is specifically configured to:

Receiving sub-transaction processing messages returned by participating nodes corresponding to each of the multiple sub-transactions;

For the multiple subtransactions, the following operations are performed respectively: from a subtransaction processing message corresponding to a subtransaction, a lock contention state of a data item associated with the subtransaction is obtained;

If the lock contention states corresponding to the multiple subtransactions are all: the associated data items have been locked, then the processing state of the distributed transaction is determined to be: committed state.

Optionally, the processing module 802 is specifically configured to:

Sending a collection request to each participating node corresponding to each of the multiple sub-transactions, wherein the collection request is used to instruct the participating node to return the execution result of the corresponding sub-transaction;

Receiving sub-transaction processing messages returned by participating nodes corresponding to the multiple sub-transactions, wherein the sub-transaction processing messages include: execution results of the sub-transactions;

When the execution results corresponding to the multiple sub-transactions are all: successful execution, it is determined that the processing status of the distributed transaction is: committed status.

The sending module 803 is also used for:

After obtaining the processing status of the distributed transaction based on the sub-transaction processing messages returned by the participating nodes corresponding to each of the multiple sub-transactions, the processing status of the distributed transaction is sent to the participating nodes corresponding to each of the multiple sub-transactions, so that each participating node unlocks the corresponding data item.

In an embodiment of the present application, the sub-transaction with a shorter network delay is executed delayed, thereby reducing the lock contention duration of the sub-transaction with a shorter network delay on the data item. At the same time, since the network delay of the sub-transaction is shorter, the time when the corresponding execution result arrives at the coordination node is not much different from the time when the execution result of the sub-transaction with a longer network delay arrives at the coordination node. This reduces the lock contention duration of hot data without affecting the execution of distributed transactions, thereby improving the throughput performance and concurrency of the distributed system.

Based on the same technical concept, the embodiment of the present application provides a computer device, which may be the server and/or client shown in FIG1B , as shown in FIG9 , including at least one processor 901, and a memory 902 connected to at least one processor. The embodiment of the present application does not limit the specific connection medium between the processor 901 and the memory 902. FIG9 takes the example of the processor 901 and the memory 902 being connected via a bus. The bus can be divided into an address bus, a data bus, a control bus, etc.

In the embodiment of the present application, the memory 902 stores instructions that can be executed by at least one processor 901, and the at least one processor 901 can execute the steps of the above-mentioned distributed transaction processing method by executing the instructions stored in the memory 902.

Among them, the processor 901 is the control center of the computer device, and can use various interfaces and lines to connect various parts of the computer device, and realize distributed transaction processing by running or executing instructions stored in the memory 902 and calling data stored in the memory 902. Optionally, the processor 901 may include one or more processing units, and the processor 901 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 901. In some embodiments, the processor 901 and the memory 902 may be implemented on the same chip, and in some embodiments, they may also be implemented separately on independent chips.

Processor 901 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, and can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware processor for execution, or can be executed by a combination of hardware and software modules in the processor.

The memory 902 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 902 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 902 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer device, but is not limited thereto. The memory 902 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and/or data.

Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program that can be executed by a computer device. When the program runs on the computer device, the computer device executes the steps of the above-mentioned distributed transaction processing method.

Based on the same inventive concept, an embodiment of the present application provides a computer program product, which includes a computer program stored on a computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer device, the computer device executes the steps of the above-mentioned distributed transaction processing method.

Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present invention is described with reference to the flowchart and/or block diagram of the method, device (system), and computer program product according to the embodiment of the present invention. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of the process and/or box in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer device or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer device or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be loaded onto a computer device or other programmable data processing device so that a series of operating steps are executed on the computer device or other programmable device to produce a process implemented by the computer device, thereby the instructions executed on the computer device or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims (12)

1. A method of distributed transaction processing, comprising:

Dividing the distributed transaction into a plurality of sub-transactions, wherein each sub-transaction corresponds to one participating node;

for the plurality of sub-transactions, performing the following operations respectively: based on network time delay between a participating node corresponding to one sub-transaction and a coordinating node, obtaining target sending time delay corresponding to the one sub-transaction, wherein the target sending time delay and the network time delay are in negative correlation;

according to the obtained multiple target sending delays, the multiple sub-transactions are respectively sent to corresponding participating nodes for transaction processing;

and obtaining the processing state of the distributed transaction based on the sub-transaction processing information returned by the participating nodes corresponding to the sub-transactions.

2. The method of claim 1, wherein the dividing the distributed transaction into a plurality of sub-transactions comprises:

the distributed transaction is divided into a plurality of sub-transactions based on the participating nodes corresponding to the data items associated with the distributed transaction, wherein each sub-transaction corresponds to at least one data item and each sub-transaction corresponds to one participating node.

3. The method of claim 1, wherein the obtaining the target transmission delay corresponding to one sub-transaction based on the network delay between the participating node corresponding to the one sub-transaction and the coordinating node comprises:

Acquiring network time delay between each participating node corresponding to each sub-transaction and the coordinating node;

obtaining the maximum network delay from the network delays corresponding to the sub-transactions respectively;

and obtaining a target sending delay corresponding to the sub-transaction based on the maximum network delay and the network delay corresponding to the sub-transaction, wherein a delay difference value between the maximum network delay and the network delay corresponding to the sub-transaction is positively correlated with the target sending delay.

4. The method of claim 3, wherein the obtaining the target transmission delay for the one sub-transaction based on the maximum network delay and the network delay for the one sub-transaction comprises:

based on the network time delay corresponding to the sub-transaction, obtaining the total execution time delay corresponding to the sub-transaction;

based on the maximum network delay, obtaining the total execution delay of the distributed transaction;

and taking the time delay difference between the total execution time delay of the distributed transaction and the total execution time delay corresponding to one sub-transaction as the target sending time delay corresponding to the one sub-transaction.

5. The method of claim 1, wherein the obtaining the target transmission delay corresponding to one sub-transaction based on the network delay between the participating node corresponding to the one sub-transaction and the coordinating node comprises:

and obtaining a target sending delay corresponding to the sub-transaction based on the network delay corresponding to the sub-transaction and the execution delay of the sub-transaction locally executed by the participating node corresponding to the sub-transaction, wherein the execution delay is inversely related to the target sending delay.

6. The method according to any one of claims 1-5, wherein the obtaining the processing state of the distributed transaction based on the sub-transaction messages returned by the participating nodes to which the plurality of sub-transactions correspond respectively, comprises:

receiving sub-transaction processing information returned by the participating nodes corresponding to the sub-transactions respectively;

for the plurality of sub-transactions, performing the following operations respectively: acquiring the lock contention state of a data item associated with one sub-transaction from a sub-transaction processing message corresponding to the sub-transaction;

if the lock contention states corresponding to the plurality of sub-transactions are: having locked the associated data item, determining the processing state of the distributed transaction is: a commit status.

7. The method according to any one of claims 1-5, wherein the obtaining the processing state of the distributed transaction based on the sub-transaction messages returned by the participating nodes to which the plurality of sub-transactions correspond respectively, comprises:

respectively sending a collection request to each corresponding participating node of the plurality of sub-transactions, wherein the collection request is used for indicating the participating node to return the execution result of the corresponding sub-transaction;

receiving a sub-transaction processing message returned by a participating node corresponding to each of the plurality of sub-transactions, wherein the sub-transaction processing message comprises: the execution result of the sub-transaction;

when the execution results corresponding to the plurality of sub-transactions are all: and when the execution is successful, determining the processing state of the distributed transaction as follows: a commit status.

8. The method according to any one of claims 1-5, wherein after obtaining the processing state of the distributed transaction based on the sub-transaction messages returned by the participating nodes corresponding to the plurality of sub-transactions, further comprises:

and respectively sending the processing states of the distributed transactions to the participating nodes corresponding to the plurality of sub-transactions so as to unlock the corresponding data items by each participating node.

9. A distributed transaction processing apparatus, comprising:

the division module is used for dividing the distributed transaction into a plurality of sub-transactions, and each sub-transaction corresponds to one participation node;

the processing module is used for respectively executing the following operations for the plurality of sub-transactions: based on network time delay between a participating node corresponding to one sub-transaction and the coordination node, obtaining target sending time delay corresponding to the one sub-transaction, wherein the target sending time delay is in negative correlation with the network time delay;

the sending module is used for respectively sending the plurality of sub-transactions to corresponding participating nodes for transaction processing according to the obtained target sending delays;

the processing module is further configured to obtain a processing state of the distributed transaction based on sub-transaction processing messages returned by the participating nodes corresponding to the plurality of sub-transactions.

10. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the steps of the method of any of claims 1-8 when the program is executed.

11. A computer readable storage medium, characterized in that it stores a computer program executable by a computer device, which program, when run on the computer device, causes the computer device to perform the steps of the method according to any one of claims 1-8.

12. A computer program product comprising a computer program stored on a computer readable storage medium, the computer program comprising program instructions which, when executed by a computer device, cause the computer device to carry out the steps of the method according to any one of claims 1 to 8.