A distributed transaction processing method, system and related equipment

Abstract

An embodiment of the present application provides a distributed transaction processing method, system, and related equipment. The method is used in a distributed system including a lock server cluster and a transaction coordinator cluster. The transaction coordinator in the transaction coordinator cluster is used to control the processing process of the distributed transaction, and the processing process includes a lock operation on the database involved in the distributed transaction. The method includes: a first lock server in the lock server cluster sends a lock data acquisition request to each transaction coordinator in the transaction coordinator list based on the transaction coordinator list; if the first lock server obtains the lock data sent by each transaction coordinator in the transaction coordinator list, the first lock server processes the lock request sent by the transaction coordinator in the transaction coordinator cluster. By executing the above method, the performance overhead of the distributed transaction processing process can be reduced and the efficiency of distributed transaction processing can be improved.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a distributed transaction processing method, system, and related equipment. Background Art

[0002] With the rapid development of network technology, distributed systems are becoming increasingly common. Based on a microservices architecture, distributed systems deploy multiple services in different regions or nodes. Services can collaborate remotely to complete a transaction. For example, to transfer 100 yuan from account a at Bank A to account b at Bank B, a first service is called to deduct 100 yuan from the balance of account a in Bank A's database, and a second service is called to increase the balance of account b in Bank B's database by 100 yuan. This type of transaction, where a distributed system operates across multiple independent databases to complete a task, is called a distributed transaction, also known as a global transaction.

[0003] During distributed transaction processing, data involved in the transaction is locked or released to prevent conflicts when concurrent distributed transactions modify the same row of data. For example, when performing the aforementioned transfer operation, the data for both account A and account B must be locked, and then released after the transfer is complete. Therefore, locking and releasing data is a very frequent operation in distributed transactions. Lock data in distributed transactions can be stored in a database. To prevent lock data loss and improve reliability, this lock data must be backed up and synchronously replicated from the primary node to the backup node. In the event of a primary node failure, the lock data is retrieved from the backup node. However, synchronous replication of lock data incurs significant performance overhead. Summary of the Invention

[0004] The embodiments of the present application disclose a distributed transaction processing method, system and related equipment, which can reduce the performance overhead in the distributed transaction processing process and improve the efficiency of distributed transaction processing.

[0005] In a first aspect, an embodiment of the present application provides a distributed transaction processing method, which is applied to a distributed system. The distributed system includes a lock server cluster and a transaction coordinator cluster. The transaction coordinator in the transaction coordinator cluster is used to control the processing process of the distributed transaction. The processing process of the distributed transaction includes a lock operation of the database involved in the distributed transaction. The method includes:

[0006] The first lock server in the lock server cluster sends a lock data acquisition request to each transaction coordinator in the transaction coordinator list according to the transaction coordinator list; when the first lock server obtains the lock data sent by each transaction coordinator in the transaction coordinator list, the first lock server processes the lock request sent by the transaction coordinator in the transaction coordinator cluster.

[0007] By adopting the method in the embodiment of the present application, a lock server cluster is used in a distributed system to process lock requests, lock release requests, etc. in distributed transactions. Each lock server in the lock server cluster can send an acquisition request to the lock server in the transaction coordinator list according to the transaction coordinator list to obtain the lock data included in each transaction coordinator in the transaction coordinator list, thereby eliminating the need to back up the lock data. Therefore, there is no need to update the lock data in the backup node each time a lock operation or a lock release operation is performed, which can reduce the performance consumption in the distributed transaction processing process. At the same time, since there is no need to return the lock result or the lock release result to the database server after updating the lock data in the primary node and the backup node each time a lock is acquired or released, the delay in the distributed transaction processing process can be reduced, the holding time of the transaction lock can be reduced, and the transaction processing efficiency can be improved.

[0008] In a specific implementation, the transaction coordinator list is synchronized to the first lock server by the second lock server. The transaction coordinator list records the transaction coordinators that are active in performing lock operations. The second lock server is the master lock server that processes the lock requests sent by the transaction coordinators in the transaction coordinator cluster before the first lock server sends a lock data acquisition request to each transaction coordinator in the transaction coordinator list.

[0009] The master lock server maintains a transaction coordinator list, which records the transaction coordinator to which the lock data saved by the master lock server belongs. After the master lock server updates the transaction coordinator list each time, it synchronizes the updated transaction coordinator list to the standby lock server, so that when the master lock server fails, the newly elected master lock server in the lock server cluster can obtain lock data from the transaction coordinator according to the transaction coordinator list, and quickly restore the full lock data in the master lock server when the failure occurs.

[0010] In a specific implementation method, the above-mentioned first lock server processes the lock request sent by the transaction coordinator in the transaction coordinator cluster, including: the first lock server receives the lock request sent by the first transaction coordinator in the transaction coordinator cluster; when the transaction coordinator list does not include the identifier of the first transaction coordinator, the first lock server adds the identifier of the first transaction coordinator to the transaction coordinator list to obtain an updated transaction coordinator list; the first lock server synchronizes the updated transaction coordinator list to other lock servers in the lock server cluster; the first lock server executes the locking operation according to the locking request when confirming that the updated transaction coordinator list is successfully synchronized to a preset proportion of lock servers in other lock servers, and saves the lock data after executing the locking operation to the storage area of ​​the first lock server.

[0011] The master lock server maintains a transaction coordinator list, which records the transaction coordinators to which the lock data stored by the master lock server belongs. Each time the master lock server receives lock data sent by the transaction coordinator, if the transaction coordinator is not included in the transaction coordinator list, the transaction coordinator's identifier is added to the transaction coordinator list to update the transaction coordinator list. After each update of the transaction coordinator list, the updated transaction coordinator list is synchronized to the standby lock server, so that when the master lock server fails, the newly elected master lock server in the lock server cluster can obtain lock data from the transaction coordinator according to the transaction coordinator list, and quickly restore the full lock data in the master lock server when the failure occurs. It should be understood that when the master lock server confirms that the updated transaction coordinator list is successfully synchronized to a preset proportion of lock servers among other lock servers, for example, the preset proportion is greater than 0.5, it can be considered that the updated transaction coordinator list is synchronized successfully.

[0012] In a specific implementation, the above method also includes: when the first lock server confirms that the updated transaction coordinator list has not been synchronized to a preset proportion of lock servers among other lock servers, it sends a lock failure message to the first transaction coordinator and deletes the identifier of the first transaction coordinator in the updated transaction coordinator list.

[0013] In a specific implementation, when the transaction coordinator list includes the identifier of the first transaction coordinator, the first lock server performs a locking operation according to the locking request, and saves the lock data after the locking operation to a storage area of ​​the first lock server.

[0014] In a specific implementation, before the first lock server processes the lock request sent by the transaction coordinator in the transaction coordinator cluster, it also includes: the first lock server sends a first indication message to the transaction coordinator in the transaction coordinator cluster, and the first indication message instructs the transaction coordinator in the transaction coordinator cluster to send the lock request to the first lock server.

[0015] In one specific implementation, before sending a lock data acquisition request to each transaction coordinator in the transaction coordinator list, the method further includes: if the first lock server fails to receive a heartbeat packet sent by the second lock server within a preset time period, the first lock server can promptly obtain lock data from the transaction coordinator cluster based on the transaction coordinator list, become the new master lock server, and then receive and process lock requests from transaction coordinators in the transaction coordinator cluster. This prevents the inability to process lock requests for distributed transactions after a master lock server failure, thereby improving the performance of the distributed system.

[0016] In a specific implementation, the first lock server is a candidate master lock server selected from the lock server cluster according to a preset algorithm. The preset algorithm may be any consensus algorithm such as a raft algorithm or a paxos algorithm.

[0017] In a specific implementation, the method also includes: when the first lock server does not receive the lock data sent by the second transaction coordinator in the transaction coordinator list, the first lock server sends an acquisition request to the third transaction coordinator in the transaction coordinator list, and the third transaction coordinator includes a backup of the lock data in the second transaction coordinator; the first lock server receives the lock data included in the second transaction coordinator sent by the third transaction coordinator.

[0018] Each transaction coordinator in the transaction coordinator cluster backs up the lock data in other transaction coordinators to prevent the lock server from becoming the primary lock server after failing to obtain data from a transaction coordinator cluster. The lock server cluster will repeatedly obtain the lock data from the transaction coordinator, which will reduce the performance of the distributed system.

[0019] In a second aspect, an embodiment of the present application provides a distributed transaction processing system, the distributed system including a lock server cluster and a transaction coordinator cluster, the transaction coordinator in the transaction coordinator cluster is used to control the processing process of the distributed transaction, the processing process of the distributed transaction includes the lock operation of the database involved in the distributed transaction, wherein,

[0020] The first lock server in the lock server cluster is configured to send a lock data acquisition request to each transaction coordinator in the transaction coordinator list according to the transaction coordinator list;

[0021] Each transaction coordinator in the transaction coordinator list is configured to send its stored lock data to the first lock server;

[0022] The first lock server is further configured to process the lock request sent by the transaction coordinator in the transaction coordinator cluster after acquiring the lock data sent by each transaction coordinator in the transaction coordinator list.

[0023] In a specific implementation, the above-mentioned transaction coordinator list is synchronized to the first lock server by the second lock server. The transaction coordinator list records the transaction coordinators that are active in performing lock operations. The second lock server is the master lock server that processes the lock requests sent by the transaction coordinators in the transaction coordinator cluster before the first lock server sends a lock data acquisition request to each transaction coordinator in the transaction coordinator list.

[0024] In a specific implementation method, the above-mentioned first lock server is also used to process the lock request sent by the transaction coordinator in the transaction coordinator cluster after obtaining the lock data sent by each transaction coordinator in the transaction coordinator list, specifically including: receiving the lock request sent by the first transaction coordinator in the transaction coordinator cluster; when the transaction coordinator list does not include the identifier of the first transaction coordinator, adding the identifier of the first transaction coordinator to the transaction coordinator list to obtain an updated transaction coordinator list; synchronizing the updated transaction coordinator list to other lock servers in the lock server cluster; when it is confirmed that the updated transaction coordinator list is successfully synchronized to a preset proportion of lock servers in other lock servers, performing a locking operation according to the locking request, and saving the lock data after the locking operation to the storage area of ​​the first lock server.

[0025] In a specific implementation, the first lock server is also used to: when it is confirmed that the updated transaction coordinator list has not been synchronized to a preset proportion of lock servers in other lock servers, send a lock failure message to the first transaction coordinator and delete the identifier of the first transaction coordinator in the updated transaction coordinator list.

[0026] In a specific implementation, the first lock server is further configured to execute a lock operation according to a lock request when the transaction coordinator list includes the identifier of the first transaction coordinator, and save the lock data after the lock operation to a storage area of ​​the first lock server.

[0027] In a specific implementation, before processing the lock request sent by the transaction coordinator in the transaction coordinator cluster, the first lock server is also used to: send a first indication message to the transaction coordinator in the transaction coordinator cluster, and the first indication message instructs the transaction coordinator to send the lock request to the first lock server.

[0028] In a specific implementation, before the first lock server sends a lock data acquisition request to each transaction coordinator in the transaction coordinator list, the process further includes: the first lock server does not receive a heartbeat packet sent by the second lock server within a preset time period.

[0029] In a specific implementation, the first lock server is a candidate master lock server selected from the lock server cluster according to a preset algorithm.

[0030] In a specific implementation, the above-mentioned first lock server is also used to: when the lock data sent by the second transaction coordinator in the above-mentioned transaction coordinator list is not received, send the above-mentioned acquisition request to the third transaction coordinator in the transaction coordinator list, wherein the third transaction coordinator includes a backup of the lock data in the second transaction coordinator; and receive the lock data included in the second transaction coordinator sent by the third transaction coordinator.

[0031] In a third aspect, an embodiment of the present application provides a distributed transaction processing device, which includes a unit for executing the method described in the above-mentioned first aspect or any specific implementation of the first aspect.

[0032] In a fourth aspect, an embodiment of the present application provides a computing device comprising a processor and a memory; the memory is used to store instructions, and the processor is used to execute the instructions. When the processor executes the instructions, it executes the method described in the first aspect or any specific implementation of the first aspect.

[0033] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores computer program instructions. When the computer program instructions are run on a device, the method described in the first aspect or any specific implementation of the first aspect is executed.

[0034] In a sixth aspect, embodiments of the present application provide a computer program product, comprising computer instructions. When executed by a computing device, the computing device performs the method of the aforementioned first aspect or any specific implementation of the first aspect. The computer program product may be a software installation package. When the method of the aforementioned first aspect or any specific implementation of the first aspect is required, the computer program product may be downloaded and executed on the computing device.

[0035] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0037] Figure 1 It is a schematic diagram of a distributed system;

[0038] Figure 2 This is a schematic diagram of a distributed system provided by an embodiment of the present application;

[0039] Figure 3 This is another distributed system diagram provided by an embodiment of the present application;

[0040] Figure 4 This is a schematic diagram of a process for determining a master lock server provided in an embodiment of the present application;

[0041] Figure 5 This is a flowchart of a lock request processing method provided by an embodiment of the present application;

[0042] Figure 6 is a schematic diagram of a distributed transaction processing device provided in an embodiment of the present application;

[0043] Figure 7 This is a schematic diagram of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] The following describes the distributed transaction implementation method and distributed system provided by the embodiments of the present application in conjunction with the accompanying drawings. A transaction refers to an operational task that accesses or updates data in a database. In traditional centralized applications, transactions are limited to accessing a single database resource. Such transactions are called local transactions. In microservice-based distributed applications, a business usually needs to call multiple microservices, and multiple microservice calls usually correspond to multiple database local transactions. When a business needs to call multiple microservices to implement multiple database local transactions, a distributed transaction is required to ensure the data consistency of these multiple database local transactions.

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

[0046] A distributed system for implementing distributed transactions includes one or more user terminals with clients deployed, one or more transaction coordinators (TCs), and one or more database servers that provide services (such as microservices). Figure 1 As shown, Figure 1This is a schematic diagram of a distributed system. The distributed system includes a user terminal, a first database server, a second database server, a transaction coordinator, database A, and database B. During distributed transaction processing, when a client needs to initiate a distributed transaction, it selects a transaction coordinator based on the load balancing policy. The client initiates a distributed transaction request to the transaction coordinator, which then creates a global transaction identity (ID) and returns it to the client. The global transaction ID uniquely identifies a distributed transaction. The client completes its corresponding branch transaction by invoking services located in different database servers. For example, to perform the aforementioned transfer operation, the first service in the first database is invoked to deduct 100 yuan from the balance of account a in database A, and the second service in the second database is invoked to increase the balance of account b in database B by 100 yuan. For each branch transaction, when executing the branch transaction, the database server sends the lock data for the database resource being operated (i.e., the data in the database) to the transaction coordinator. The transaction coordinator locks one or more rows of data in the database based on the lock data to prevent multiple distributed transactions from concurrently modifying the same row of data in the same database. The transaction coordinator then sends a message indicating that the lock was successfully obtained to the database server. Currently, locks are performed using a remote dictionary server (Redis) or a relational database. Lock data is stored in Redis or a relational database. The lock data consists of a set of key-value pairs, where the key is the identifier of the row containing the data to be locked, the name of the table containing the row, and the name of the database containing the table. The value is the global transaction ID of the distributed transaction. To prevent lock data loss and improve reliability, lock data must be backed up and synchronously replicated from the primary node to the backup node. This means that lock data is synchronously replicated from one database to another. However, this synchronous replication of lock data incurs significant performance overhead, impacting the efficiency of distributed transaction processing.

[0047] An embodiment of the present application provides a distributed system, which includes one or more user terminals deployed with clients, one or more database servers providing services (such as microservices), a transaction coordinator cluster including multiple transaction coordinators, and a lock server cluster including multiple lock servers. The transaction coordinator in the transaction coordinator cluster is used to control the processing process of distributed transactions, and the processing process of distributed transactions includes the lock operations of the database involved in the distributed transactions. The lock server in the lock server cluster is used to process the lock request sent by the transaction coordinator in the transaction coordinator cluster. For example, a lock request and a lock release request. For example Figure 2 As shown, Figure 2This is a schematic diagram of a distributed system provided by an embodiment of the present application. In this distributed system, the lock server cluster includes a master lock server and multiple backup lock servers. When the transaction coordinator receives the lock data sent by the database server, it sends the lock data to the master lock server. The master lock server locks the resources operated by the database server (that is, the data in the database) according to the lock data and stores the lock data in the storage area. Then, a message of successful locking is sent to the transaction coordinator, and the transaction coordinator that sent the lock data is recorded in the transaction coordinator list in the master lock server. The transaction coordinator list is further synchronized to other backup lock servers so that when the master lock server fails, the new master lock server elected from the backup lock server can obtain lock data from the transaction coordinator according to the transaction coordinator list. Among them, the transaction coordinator list records the transaction coordinators that are active in performing lock operations. The transaction coordinator that is active in performing lock operations means that the transaction coordinator has sent lock data to the master lock server and the sent lock data still exists in the master lock server. The storage area of ​​the lock server refers to a component in the lock server that stores programs and data, and is a storage space that can be directly addressed by a processor of the lock server, such as a memory.

[0048] like Figure 3 As shown, Figure 3 This is a schematic diagram of another distributed system provided by an embodiment of the present application. In this distributed system schematic diagram, in order to improve the efficiency of the lock server in processing lock requests, multiple lock servers are divided into multiple partitions, each partition includes a master lock server and multiple backup lock servers. After receiving the lock data, the transaction coordinator selects one of the partitions according to the load balancing strategy and sends the lock data to the master lock server of the partition to implement locking.

[0049] The following describes the distributed system provided by the embodiment of the present application and the method for implementing locking based on the distributed system in conjunction with the accompanying drawings. First, a method for determining a master lock server among multiple lock servers in a partition is described. Figure 4 As shown, Figure 4 The present invention provides a flowchart for determining a master lock server, which includes steps S401 to S406. It should be noted that when all lock servers in a lock server cluster are restarted, or when the original master lock server in the lock server cluster fails, the operations of determining the master lock server in steps S401 to S406 are performed.

[0050] S401. The first lock server obtains a transaction coordinator list.

[0051] The first lock server is a candidate master lock server selected by the lock server cluster using a preset algorithm (e.g., a consensus algorithm such as the Raft algorithm or the Paxos algorithm). After being selected as the candidate master lock server, the first lock server obtains the transaction coordinator list of the lock server cluster before the first lock server was selected as the candidate master lock server, and obtains the transaction coordinator data of the transaction coordinators included in the transaction coordinator list. The transaction coordinator list is synchronized to the first lock server by the second lock server, which is the master lock server of the first lock server before it was selected as the candidate master lock server. The transaction coordinator data includes the address information of each transaction coordinator in the transaction coordinator list, and the transaction coordinator list includes some or all transaction coordinators in the transaction coordinator cluster. The preset algorithm can be a Raft algorithm or a consensus algorithm such as the Paxos algorithm, which is not limited in the embodiments of the present application.

[0052] S402. The first lock server sends an acquisition request to each transaction coordinator in the transaction coordinator list.

[0053] After obtaining the address information of each transaction coordinator in the transaction coordinator list, the first lock server sends a request to each transaction coordinator in the transaction coordinator list. The request is used to obtain the lock data of each transaction coordinator that received the request. The lock data in each transaction coordinator includes the lock data of one or more distributed transactions processed by the transaction coordinator.

[0054] S403. Each transaction coordinator that receives the acquisition request sends its own lock data to the first lock server.

[0055] After receiving the acquisition request from the first lock server, the first transaction coordinator acquires the lock data in the first transaction coordinator and sends the lock data to the first lock server, wherein the first transaction coordinator is any transaction coordinator in the transaction coordinator list.

[0056] In one possible implementation, Figure 3 As shown in , to improve the efficiency of lock servers in processing lock requests, multiple lock servers are divided into multiple partitions. Each partition includes a primary lock server and multiple backup lock servers. After receiving lock data, the transaction coordinator selects one of the partitions based on the load balancing strategy and sends the lock data to the primary lock server in that partition to implement the lock. After receiving the acquire request, the first transaction coordinator sends the lock data previously sent to the first lock server to the first lock server.

[0057] S404. The first lock server determines whether it has obtained the lock data returned by each transaction coordinator in the transaction coordinator list. If not, execute S405; if yes, execute S406.

[0058] S405. When the first lock server fails to obtain the lock data from the second transaction coordinator, it sends an acquisition request to the third transaction coordinator. After the first lock server receives the lock data of the second transaction coordinator sent by the third transaction coordinator, it executes S406.

[0059] The third transaction coordinator is a backup node for the second transaction coordinator. The third transaction coordinator includes the lock data of the second transaction coordinator. When the first lock server does not receive the lock data returned by the second transaction coordinator, it sends an acquisition request to the third transaction coordinator that has a backup of the lock data of the second transaction coordinator to obtain the lock data included in the second transaction coordinator. After receiving the lock data sent by the third transaction coordinator, the first lock server executes S406. The second transaction coordinator is any transaction coordinator in the transaction coordinator list.

[0060] S406. After obtaining the lock data of each transaction coordinator in the transaction coordinator list, the first lock server notifies each transaction coordinator in the transaction coordinator cluster that it is the master lock server.

[0061] After obtaining the lock data sent by each transaction coordinator in the transaction coordinator list, the first lock server constructs full lock data in the memory of the first lock server, where the full lock data includes the lock data included by each transaction coordinator in the transaction coordinator list.

[0062] After obtaining the lock data for each transaction coordinator in the transaction coordinator list, the first lock server sends a first indication message to each transaction coordinator in the transaction coordinator cluster. This first indication message is used to notify each transaction coordinator that the first lock server is the master lock server in the lock server cluster. The master lock server is used to process lock requests, lock release requests, and lock query requests from each transaction coordinator in the transaction coordinator cluster. When each transaction coordinator in the coordination server cluster needs to lock, release, or query a lock, it sends the lock request, lock release request, or lock query request to the master lock server.

[0063] It should be noted that if the above-mentioned first lock server fails to successfully obtain the lock data in each transaction coordinator in the transaction coordinator list, the first lock server cannot obtain the above-mentioned full lock data. In order to prevent the first lock server from making an error when receiving a lock request, a lock release request or a lock query request sent by the transaction coordinator, the lock server cluster will re-elect and re-elect the candidate master lock server of the lock server cluster according to the above-mentioned preset algorithm. For example, the second lock server in the lock server cluster is elected as the candidate master lock server, and the candidate master lock server then obtains the lock data according to the above-mentioned methods in S401 to S406 to determine whether it can become the master lock server.

[0064] In one possible implementation, after the first lock server becomes the master lock server, the first lock server will send heartbeat packets to other lock servers at a preset time interval. If any lock server does not receive the heartbeat packet sent by the first lock server within the first preset time period, the any lock server will send an election request to other lock servers to re-initiate the election, and multiple lock servers in the lock server cluster will re-elect the candidate master lock server of the partitioned lock server cluster according to the above-mentioned preset algorithm. For example, the second lock server in the lock server cluster will be elected as the candidate master lock server, and the second lock server will obtain lock data according to the above-mentioned methods in S401 to S406 to determine whether it can become the master lock server, wherein the above-mentioned first preset time period is greater than the preset time interval.

[0065] By adopting the method in the embodiment of the present application, a lock server cluster is used instead of Redis or a database in a distributed system, and each lock server cluster includes a main lock server and multiple backup lock servers. In each lock server cluster, the main lock server processes lock requests, lock release requests, and lock query requests in the system, and stores the lock data after locking or releasing in the storage area of ​​the main lock server, such as the memory. There is no need to back up the lock data, so there is no need to update the lock data in the backup node after each locking operation or releasing operation, which can reduce the performance consumption in the distributed transaction processing process. At the same time, since there is no need to update the lock data in the backup node after each locking or releasing operation before returning the locking result or releasing result to the database server, it can reduce the delay in the distributed transaction processing process, reduce the holding time of the transaction lock, and improve the transaction processing efficiency. In addition, a transaction coordinator list is maintained in the master lock server, which records the transaction coordinator to which the lock data saved by the master lock server belongs. After the master lock server updates the transaction coordinator list each time, the updated transaction coordinator list is synchronized to the standby lock server, so that when the master lock server fails, the newly elected master lock server in the lock server cluster can obtain lock data from the transaction coordinator according to the transaction coordinator list, and quickly restore the full lock data in the master lock server when the failure occurs.

[0066] After determining the master lock server in a lock server cluster according to the above method, the master lock server processes the lock request, lock release request and lock query request sent by the transaction coordinator. Taking the first lock server as the master lock server in the partition as an example, the lock request processing method provided by the embodiment of the present application is introduced. Figure 5 As shown, Figure 5 This is a flowchart of a lock request processing method provided in an embodiment of the present application.

[0067] S501. The first lock server obtains the lock request sent by the first transaction coordinator and determines the type of the lock request. If it is a lock request, execute S502; if it is a lock release request, execute S506; if it is a lock check request, execute S507.

[0068] Among them, the types of lock requests include lock requests, lock release requests, and lock query requests. Lock requests include the above-mentioned lock data. Lock requests are used to instruct the first lock server to perform a lock operation. Locking operations refer to saving the lock data in the lock request. When other transactions need to operate on the data in the database indicated by the lock data, the data will also be locked. If the lock data already exists in the lock server, other transactions will fail to lock and cannot operate on the data, thereby preventing conflicts when concurrent transactions operate on the same row of data. Lock release requests are used to instruct the first lock server to perform a lock release operation. Lock release operations refer to deleting the lock data in the lock server.

[0069] S502. When the lock request is a lock request, the first lock server obtains the transaction coordinator list and determines whether the first transaction coordinator is in the transaction coordinator list. If the first transaction coordinator is not in the transaction coordinator list, execute S503; if the first transaction coordinator is in the transaction coordinator list, execute S505.

[0070] The transaction coordinator list includes identifiers of each transaction coordinator, such as the Internet Protocol (IP) address of the transaction coordinator. The first lock server matches the identifiers in the transaction coordinator list with the identifiers in the transaction coordinator list based on the identifier of the first transaction coordinator that sent the lock request. If the identifier of the first transaction coordinator is not in the transaction coordinator list, it is determined that the first transaction coordinator is not in the transaction coordinator list, and the operation in S503 is executed. If the identifier of the first transaction coordinator is in the transaction coordinator list, it is determined that the first transaction coordinator is in the transaction coordinator list, and the operation in S505 is executed.

[0071] S503. The first lock server adds the identifier of the first transaction coordinator to the transaction coordinator list to obtain an updated transaction coordinator list, and synchronizes the updated transaction coordinator list to other lock servers in the lock server cluster. If the updated transaction coordinator list is not successfully synchronized to a preset proportion of lock servers in other lock servers, execute S504. If the updated transaction coordinator list is successfully synchronized to a preset proportion of lock servers in other lock servers in the partition, execute S505.

[0072] After the first lock server adds the identifier of the first transaction coordinator to the transaction coordinator list to obtain an updated transaction coordinator list, it sends the updated transaction coordinator list to the other lock servers. If the first lock server does not receive confirmation messages returned by a preset proportion of the other lock servers, the first lock server determines that the updated transaction coordinator list has not been successfully synchronized with the other lock servers, and the first lock server performs the operation in S504. If the first lock server receives confirmation messages returned by a preset proportion or greater of the other lock servers, the first lock server confirms that the updated transaction coordinator list has been successfully synchronized with the other lock servers, and the first lock server performs the operation in S505.

[0073] S504. The first lock server confirms that the updated transaction coordinator list has not been successfully synchronized to a preset proportion of other lock servers, determines that the result of the lock request is a lock failure, and executes S508 to return the execution result of the lock request.

[0074] If the first lock server receives a lock request but fails to successfully synchronize the updated transaction coordinator list with other lock servers, the lock operation is not performed and a lock failure return message is sent to the transaction coordinator that sent the lock request. The identifier of the first transaction coordinator in the updated transaction coordinator list is also deleted.

[0075] In one possible implementation, the above-mentioned preset ratio can be 1. At this time, if the first lock server fails to successfully synchronize the updated transaction coordinator list to all other lock servers, it is determined that the lock has failed, thereby avoiding the situation where the transaction coordinator list in the newly elected master lock server is not updated when the first lock server fails, resulting in incomplete lock data obtained.

[0076] S505. The first lock server executes the locking operation. If the locking is successful, the result of the lock request is determined to be a successful locking. If the locking fails, the result of the lock request is determined to be a failed locking. S508 is executed to return the execution result of the lock request.

[0077] After the first lock server determines that the updated transaction coordinator list will be synchronized to a preset proportion of lock servers in the partition, it searches the full lock data for the key in the lock request. If not, it executes the lock request and saves the lock data in the lock request to the storage area of ​​the lock server. If the key in the lock request exists, it means that the lock data corresponding to the key exists. Then it compares the value of the lock data in the lock request with the value of the key in the first lock server. If the values ​​are the same, it means that the lock requested by the lock request already exists. If the values ​​are different, it means that another transaction has locked the data and the lock request has failed.

[0078] S506. In the case that the lock request is a lock release request, the first lock server deletes the lock data corresponding to the key from the storage area, executes S508 and returns the execution result of the lock request.

[0079] S507. In the case that the lock request is a lock query request, the first lock server queries whether there is lock data corresponding to the key in the storage area, and executes S508 to return the execution result of the lock request.

[0080] S508. The first lock server returns the execution result of the lock request to the first transaction coordinator.

[0081] In one possible implementation, if all locks applied for by a transaction coordinator have been released and the transaction coordinator has not sent a new lock request to the master lock server within a second preset time period, the first lock server deletes the identifier of the transaction coordinator from the transaction coordinator list.

[0082] It should be noted that, for the above method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should know that the present invention is not limited to the order of the actions described. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the present invention.

[0083] Other reasonable step combinations that can be thought of by those skilled in the art based on the above description also fall within the scope of protection of the present invention. Secondly, those skilled in the art should also be familiar with that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the present invention.

[0084] Combined with the above Figures 1 to 5 The lock request processing method provided by the embodiment of the present application is described in detail. Figure 6 and Figure 7 , describing the distributed transaction processing apparatus and computing device provided in the embodiments of the present application.

[0085] Figure 6 : is a schematic diagram of a distributed transaction processing device provided in an embodiment of the present application. The distributed transaction processing device 600 is used for any lock server in the lock server cluster in the above-mentioned distributed system. The distributed system includes a lock server cluster and a transaction coordinator cluster. The transaction coordinator in the transaction coordinator cluster is used to control the processing process of the distributed transaction. The processing process of the distributed transaction includes the lock operation of the database involved in the distributed transaction. The device includes a communication unit 610 and a processing unit 620, wherein:

[0086] A communication unit 610 is configured to send a lock data acquisition request to each transaction coordinator in the transaction coordinator list;

[0087] The processing unit 620 is configured to process the lock request sent by the transaction coordinator in the transaction coordinator cluster after the first lock server obtains the lock data sent by each transaction coordinator in the transaction coordinator list.

[0088] It should be understood that the processing unit 620 of the embodiment of the present application can be implemented by a central processing unit (CPU), or by an application-specific integrated circuit (ASIC), or by a programmable logic device (PLD), wherein the PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof. It can also be implemented by software. Figure 4 and Figure 5 When using the distributed transaction processing method shown in , the distributed transaction processing apparatus 600 and its various units may also be software modules.

[0089] Specifically, the distributed transaction processing apparatus 600 can implement distributed transaction processing operations by referring to the above method embodiment. Figure 4 and Figure 5 The operation steps of the method executed by the first lock server are not described in detail here.

[0090] Figure 77 is a schematic diagram of a computing device provided in an embodiment of the present application. The computing device 700 includes: a processor 710, a communication interface 720, and a memory 730. The processor 710, the communication interface 720, and the memory 730 are interconnected via a bus 740. The processor 710 is used to call the program code stored in the memory 730 to execute the above Figure 4 and Figure 5 Regarding the operations performed by the first lock server.

[0091] The processor 710 can have a variety of specific implementation forms. For example, the processor 710 can be a combination of any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), and a tensor processing unit (TPU). The processor 710 can also be a single-core processor or a multi-core processor. The processor 710 can be a combination of a CPU and a hardware chip. The above-mentioned hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above-mentioned PLD is a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 710 can also be implemented solely using a logic device with built-in processing logic, such as an FPGA or a digital signal processor (DSP).

[0092] The communication interface 720 may be a wired interface or a wireless interface, and is used to communicate with other modules or devices, such as obtaining a lock request from the transaction coordinator, synchronizing the transaction coordinator list, etc. The wired interface may be an Ethernet interface, a controller area network (CAN) interface, or a local interconnect network (LIN) interface, and the wireless interface may be a cellular network interface or a wireless local area network interface.

[0093] The memory 730 includes non-volatile memory and volatile memory, such as non-volatile memory read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be a random access memory (RAM). The memory 730 can be used to store program code and data, so that the processor 710 calls the program code stored in the memory 730 to execute the above method embodiment to implement the above Figure 4 or Figure 5 In addition, the computing device 700 may include a computer program product that is different from the computer program product of FIG. Figure 7 Show more or fewer components, or configure components differently.

[0094] The bus 740 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0095] Optionally, the computing device 700 may further include an input / output interface 750 , to which an input / output device is connected for receiving input information and outputting operation results.

[0096] It should be understood that the computing device 700 of the embodiment of the present application may correspond to the distributed transaction processing apparatus 600 in the above embodiment, and may execute the operations performed by the distributed transaction processing apparatus or the first lock server in the above method embodiment, which will not be described in detail here.

[0097] An embodiment of the present application also provides a non-volatile computer storage medium, which stores computer program instructions. When the computer storage medium is run on a processor, the method steps in the above method embodiment can be implemented. The specific implementation of the processor of the computer storage medium in executing the above method steps can refer to the specific operations of the above method embodiment, which will not be repeated here.

[0098] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

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

[0100] The above is only a specific embodiment of the present application. Those skilled in the art may conceive of changes or substitutions based on the specific embodiment provided in this application, and all such changes or substitutions shall fall within the scope of protection of this application.

Claims

1. A distributed transaction processing method, characterized in that: The method is applied to a distributed system, the distributed system including a lock server cluster and a transaction coordinator cluster, the transaction coordinator in the transaction coordinator cluster is used to control the processing of distributed transactions, the processing of the distributed transactions including lock operations on databases involved in the distributed transactions, and the method includes: The first lock server in the lock server cluster sends a lock data acquisition request to each transaction coordinator in the transaction coordinator list according to the transaction coordinator list; the transaction coordinator list is synchronized to the first lock server by the second lock server, and the transaction coordinator list records the transaction coordinators that are active in performing lock operations. The second lock server is the master lock server that processes the lock requests sent by the transaction coordinators in the transaction coordinator cluster before the first lock server sends the lock data acquisition request to each transaction coordinator in the transaction coordinator list; If the first lock server obtains the lock data sent by each transaction coordinator in the transaction coordinator list, the first lock server processes the lock request sent by the transaction coordinator in the transaction coordinator cluster.

2. The method according to claim 1, characterized in that The first lock server processes a lock request sent by a transaction coordinator in the transaction coordinator cluster, including: The first lock server receives a lock request sent by a first transaction coordinator in the transaction coordinator cluster; When the transaction coordinator list does not include the identifier of the first transaction coordinator, the first lock server adds the identifier of the first transaction coordinator to the transaction coordinator list to obtain an updated transaction coordinator list; The first lock server synchronizes the updated transaction coordinator list to other lock servers in the lock server cluster; The first lock server executes a locking operation according to the locking request when confirming that the updated transaction coordinator list is successfully synchronized to a preset proportion of lock servers among the other lock servers, and saves the lock data after the locking operation to a storage area of ​​the first lock server.

3. The method according to claim 2, characterized in that The method further comprises: When confirming that the updated transaction coordinator list has not been synchronized to a preset proportion of lock servers among the other lock servers, the first lock server sends a lock failure message to the first transaction coordinator and deletes the identifier of the first transaction coordinator in the updated transaction coordinator list.

4. The method according to claim 2, characterized in that When the transaction coordinator list includes the identifier of the first transaction coordinator, the first lock server performs a locking operation according to the locking request, and saves the lock data after the locking operation is performed to the storage area of ​​the first lock server.

5. The method according to any one of claims 1 to 4, characterized in that Before the first lock server processes the lock request sent by the transaction coordinator in the transaction coordinator cluster, the method further includes: The first lock server sends a first indication message to the transaction coordinator in the transaction coordinator cluster, where the first indication message instructs the transaction coordinator in the transaction coordinator cluster to send a lock request to the first lock server.

6. The method according to claim 1, characterized in that Before sending a lock data acquisition request to each transaction coordinator in the transaction coordinator list, the method further includes: The first lock server does not receive a heartbeat packet sent by the second lock server within a preset time period.

7. The method according to claim 5, characterized in that The first lock server is a candidate master lock server selected from the lock server cluster according to a preset algorithm.

8. The method according to any one of claims 1 to 4, characterized in that The method further comprises: When the first lock server does not receive the lock data sent by the second transaction coordinator in the transaction coordinator list, the first lock server sends the acquisition request to the third transaction coordinator in the transaction coordinator list, where the third transaction coordinator includes a backup of the lock data in the second transaction coordinator; The first lock server receives the lock data included in the second transaction coordinator sent by the third transaction coordinator.

9. A distributed transaction processing system, characterized in that: The distributed system includes a lock server cluster and a transaction coordinator cluster. The transaction coordinator in the transaction coordinator cluster is used to control the processing process of the distributed transaction. The processing process of the distributed transaction includes the lock operation of the database involved in the distributed transaction, wherein: The first lock server in the lock server cluster is configured to send a lock data acquisition request to each transaction coordinator in the transaction coordinator list according to the transaction coordinator list; the transaction coordinator list is synchronized to the first lock server by the second lock server, the transaction coordinator list records the transaction coordinators that are active in performing lock operations, and the second lock server is a master lock server that processes lock requests sent by the transaction coordinators in the transaction coordinator cluster before the first lock server sends a lock data acquisition request to each transaction coordinator in the transaction coordinator list; Each transaction coordinator in the transaction coordinator list is configured to send its stored lock data to the first lock server; The first lock server is further configured to process the lock request sent by the transaction coordinator in the transaction coordinator cluster after acquiring the lock data sent by each transaction coordinator in the transaction coordinator list.

10. The system according to claim 9, characterized in that The first lock server is further configured to process the lock request sent by the transaction coordinator in the transaction coordinator cluster after acquiring the lock data sent by each transaction coordinator in the transaction coordinator list, specifically including: Receiving a lock request sent by a first transaction coordinator in the transaction coordinator cluster; When the transaction coordinator list does not include the identifier of the first transaction coordinator, adding the identifier of the first transaction coordinator to the transaction coordinator list to obtain an updated transaction coordinator list; Synchronizing the updated transaction coordinator list to other lock servers in the lock server cluster; When it is confirmed that the updated transaction coordinator list is successfully synchronized to a preset proportion of lock servers in the other lock servers, a locking operation is performed according to the locking request, and the lock data after the locking operation is performed is saved to the storage area of ​​the first lock server.

11. The system according to claim 10, wherein: The first lock server is further configured to: When it is confirmed that the updated transaction coordinator list has not been synchronized to a preset proportion of lock servers in the other lock servers, a lock failure message is sent to the first transaction coordinator, and the identifier of the first transaction coordinator in the updated transaction coordinator list is deleted.

12. The system according to claim 10, wherein: The first lock server is further configured to, when the transaction coordinator list includes the identifier of the first transaction coordinator, perform a locking operation according to the locking request, and save the lock data after the locking operation to a storage area of ​​the first lock server.

13. The system according to any one of claims 9 to 12, characterized in that Before processing the lock request sent by the transaction coordinator in the transaction coordinator cluster, the first lock server is further configured to: A first indication message is sent to a transaction coordinator in the transaction coordinator cluster, where the first indication message instructs the transaction coordinator to send a lock request to the first lock server.

14. The system according to claim 9, wherein: Before the first lock server sends a lock data acquisition request to each transaction coordinator in the transaction coordinator list, the method further includes: The first lock server does not receive a heartbeat packet sent by the second lock server within a preset time period.

15. The system according to claim 14, wherein: The first lock server is a candidate master lock server selected from the lock server cluster according to a preset algorithm.

16. The system according to any one of claims 9 to 12, characterized in that The first lock server is further configured to: When the lock data sent by the second transaction coordinator in the transaction coordinator list is not received, the acquisition request is sent to the third transaction coordinator in the transaction coordinator list, where the third transaction coordinator includes a backup of the lock data in the second transaction coordinator; Receive the lock data included in the second transaction coordinator sent by the third transaction coordinator.

17. A distributed transaction processing device, characterized in that: The apparatus comprises means for performing the method according to any one of claims 1 to 8.

18. A computing device, characterized in that The method comprises a processor and a memory, wherein the memory is used to store instructions, and the processor is used to execute the instructions. When the processor executes the instructions, the method according to any one of claims 1 to 8 is performed.

19. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, and when the instructions are executed on the network device, the method according to any one of claims 1 to 8 is executed.

20. A computer program product, characterized in that The computer program product comprises computer instructions, and when executed by a computing device, the computing device performs the method according to any one of claims 1 to 8.

Images