Distributed transaction processing system transaction processing method and computer readable storage medium

Abstract

The embodiment of the invention discloses a distributed transaction processing system transaction processing method and a computer readable storage medium. According to the method, a lock-free conflict detection mechanism is introduced, on the premise that any read-write lock is not used, writing-writing conflicts, writing-reading conflicts or read-writing conflicts of data item granularity between concurrent transactions are detected, and the three data inconsistency problems of dirty reading, unrepeatable reading and magical reading are avoided. Meanwhile, transactions with reading conflicts are allowed to be executed concurrently, and the concurrency of transaction processing is improved. When a timeout problem occurs, the coordinator and the participants respectively execute different protocol termination processes, so that the coordinator and the participants can be timely and properly processed when faults occur, and the 2PC protocol is optimized. Besides, after the participants enter the submission stage of the transaction submission step, the multi-copy mechanism of the system ensures that the sub-transactions undertaken by the participants are not influenced to execute correct submission or rollback operation even if the participants fail, so that the fault tolerance of the system is ensured.

Description

Technical Field

[0001] The present application belongs to the field of database technology, and in particular, relates to a transaction processing method of a distributed transaction processing system and a computer-readable storage medium. Background Art

[0002] Distributed transaction processing systems are software systems that execute transactions in a distributed environment and are widely used in many fields. Typical distributed transaction processing systems include online shopping systems (ensuring that users can successfully place orders and pay for the goods they purchase), banking systems (ensuring that users' transfer operations can be successfully executed), and flight reservation systems (ensuring that users' ticket reservations can be successfully completed). Distributed transaction processing systems have become an important part of modern distributed systems, ensuring data consistency and reliability in distributed systems. Existing distributed transaction processing systems widely use the two-phase commit (2PC) protocol to implement the commit step, ensuring that distributed transactions are either fully committed or fully rolled back in all participants (i.e., nodes that undertake subtransactions).

[0003] To ensure the isolation of transactions, the 2PC protocol can be combined with other technologies such as read-write locks and multi-version concurrency control (MVCC) to achieve different transaction isolation levels. The ANSISQL standard defines several transaction isolation levels, including Read Uncommitted, Read Committed, Repeatable Read, and Serializable. At the Read Uncommitted level, a transaction can read modifications that have not yet been committed by other transactions. This isolation level may cause dirty read problems, that is, uncommitted modifications can be read, and if these modifications are later rolled back, data inconsistency will result. The Read Committed level is the default isolation level for many database management systems (including Oracle and SQL Server). At this isolation level, transactions can only read committed modifications. This solves the dirty read problem, but may cause non-repeatable read problems, that is, reading the same data twice in the same transaction may be different. Repeatable read level is the default isolation level of MySQL. At this isolation level, the transaction reads the same data in the same way throughout the transaction, and there will be no non-repeatable read problem. However, there may be phantom read problems, that is, the result sets of two queries in the same transaction may be different. Serialization is the most stringent isolation level, which avoids the phantom read problem by forcing transactions to be executed serially. At this isolation level, new transactions must wait for other transactions to complete before they can be executed. The performance of transaction processing depends on the transaction isolation level: the higher the transaction isolation level pursued by the distributed transaction processing system, the greater the time cost required for transaction processing.

[0004] Although the 2PC protocol can ensure transaction atomicity and can be combined with other technical means to achieve different transaction isolation levels, the protocol has a blocking problem, which affects the performance of distributed transaction processing. The prior art has proposed a variety of optimization schemes, which are mainly divided into two categories to solve the 2PC problem of decomposable transactions: the first category is optimization for shared architecture-free; the second category is optimization for custom storage. However, the former will increase network communication and complexity; while the latter solves the inconsistency problem by applying the protocol, but requires custom storage design and replication protocol, and still cannot solve the blocking problem of 2PC. It can be seen that although the prior art has optimized 2PC to a certain extent, it still has problems such as poor flexibility and limited performance improvement. Therefore, how to optimize the 2PC protocol is a technical problem that needs to be solved urgently by technicians in this field.

[0005] The preceding description is intended to provide general background information and does not necessarily constitute prior art. Summary of the invention

[0006] Based on this, it is necessary to propose a distributed transaction processing system transaction processing method and computer-readable storage medium to address the above problems, which can avoid the three major data inconsistency problems of dirty reads, non-repeatable reads and phantom reads, while maintaining the concurrency of transaction processing and improving transaction processing efficiency and throughput.

[0007] The present application solves the technical problem by adopting the following technical solutions: The present application provides a transaction processing method for a distributed transaction processing system, which is applied to a distributed transaction processing system; the distributed transaction processing system is composed of multiple nodes, and the distributed transaction processing system divides all stored data into multiple data shards; each data shard has a preset number of copies, and the copies are divided into a unique master copy and multiple slave copies according to a preset consensus protocol, and the master copy and the slave copy corresponding to a data shard are called a copy group; different copies of each data shard are stored in different nodes; for the same copy group, the node storing the master copy is called a participant, and the node storing the slave copy is called a candidate; the distributed transaction processing system also includes a client and a coordinator, and the client and the coordinator are deployed in a node or two different nodes of the distributed transaction processing system; the client is associated with the coordinator, the coordinator is associated with all nodes, and the participants are associated with each other; The method comprises the following steps: After receiving the transaction processing request issued by the user, the client forwards the transaction and the transaction processing request to the coordinator. The transaction consists of a single or multiple statements; the coordinator performs transaction decomposition operations on the transaction to obtain several sub-transactions, each of which involves only data items in one data shard; the coordinator constructs a prepare request for each sub-transaction and sends the prepare request to the corresponding participant. The participant enters the prepare phase according to the prepare request and performs prepare operations on the sub-transaction. The prepare operation includes data constraint detection, concurrency conflict detection, logging operations, and state synchronization operations; the participant generates a feedback response based on the local transaction status obtained from the prepare operation and returns the feedback response to the coordinator. The local transaction status is one of ready and ready to terminate, and the feedback response is one of a commit response, a breach termination response, and a conflict termination response; if the coordinator receives a breach termination response from at least one participant , then a rollback request is sent to all participants to control all participants to perform the rollback operation, and a termination transaction request is issued to the client; if the coordinator does not receive a default termination response from any participant but receives a conflict termination response from at least one participant, a rollback request is sent to all participants to control all participants to perform the rollback operation, and a retry transaction request is issued to the client; if all participants feedback a commit response, the coordinator constructs a commit request for each participant and sends it, and the commit request is used to control the participant to enter the commit phase; the coordinator obtains the read set returned by the participant after the commit operation, integrates all received read sets, synthesizes the request result and feeds back to the client; if the coordinator times out waiting for a participant's response, the coordinator executes the first termination protocol process; if the participant times out waiting for the coordinator's request, the participant executes the second termination protocol process.

[0008] In an optional embodiment of the present application, data constraint detection includes: after receiving a prepare request, the participant creates a read set and a write set according to the subtransaction, the read set and the write set are composed of a four-tuple, and the four-tuple includes a data item, a transaction ID, a statement ID and a read / write time; the participant performs data constraint detection when creating the read set and the write set to determine whether the data item meets the preset data constraints; if the data item does not meet the data constraint, the participant sends a default termination response to the coordinator and ends the prepare phase of the subtransaction, and no longer performs concurrency conflict detection, logging operations and state synchronization operations; if the data item meets the data constraint, the participant performs concurrency conflict detection on the subtransaction it undertakes based on the created read set and write set.

[0009] In an optional embodiment of the present application, a participant maintains a transaction reservation table, which consists of a five-tuple, including a data item, a transaction ID, a statement ID, a read / write tag, and a read / write time; the read / write time is the local time of the participant; the participant locally records the start time and commit time of the transaction in which it is located. The start time is the time when the participant receives the first subtransaction prepare request, and the commit time is the time when the participant receives the last subtransaction commit request; for the participant, a transaction whose commit time has been set in the transaction reservation table is called a completed transaction; a transaction whose commit time is not set in the transaction reservation table is called an unfinished transaction; concurrency conflict detection includes: if there is an unfinished transaction in the subtransaction processed by the participant, the unfinished transaction has a corresponding write five-tuple in the transaction reservation table, and the write time of the unfinished transaction is shorter than the four-tuple of the current transaction for the same data item in the participant's read set or write set. If the maximum read / write time of the tuple is smaller, the current transaction is the subtransaction being processed by the participant, or if there is a completed transaction in the subtransaction processed by the participant, the commit time of the completed transaction is greater than the start time of the current transaction, and the completed transaction has a corresponding write quintuple in the transaction reservation table, the write time of the completed transaction is smaller than the maximum read / write time of the quintuple about the current transaction for the same data item in the participant's read set or write set, or if there is a quintuple for the current transaction in the participant's write set, and the write time of the quintuple is smaller than the maximum read / write time of the quintuple for the same data item in the transaction reservation table, then it is considered that the concurrency conflict detection cannot be passed, and the participant sends a conflict termination response to the coordinator, ends the preparation phase of the subtransaction, and no longer performs logging operations and state synchronization operations; if it is not the above situation, then it is considered that the concurrency conflict detection can be passed, and logging operations and state synchronization operations continue to be performed.

[0010] In an optional embodiment of the present application, a participant maintains a local master write-ahead log, and a candidate maintains a local slave write-ahead log, both of which are composed of multiple log records, and the log records are used to record the read set, write set, transaction reservation table and processing status of the sub-transaction; executing a log recording operation includes: the participant constructs a log record according to the read set, write set and transaction reservation table of the sub-transaction, and adds the log record to the local master write-ahead log of the master replica corresponding to the sub-transaction; the log record is sent to the local slave write-ahead log of the slave replica of the replica group corresponding to the sub-transaction until the replica group meets the consensus conditions of the preset consensus protocol, and the log recording operation is ended.

[0011] In an optional embodiment of the present application, the state synchronization operation includes: executing after the data items of the subtransaction pass the data constraint detection, concurrency conflict detection and log recording operation; each participant P calls the function LogOnce (current transaction, participant P, ready) to record the local state of the subtransaction locally in the participant P, and the parameters of the LogOnce function are transaction ID, participant ID, and subtransaction local state respectively; if the participant corresponding to the second parameter in the LogOnce function has recorded the local transaction state of the transaction corresponding to the first parameter in the LogOnce function, then the LogOnce function returns the local transaction state recorded locally by the participant corresponding to the second parameter, otherwise the subtransaction local state corresponding to the third parameter in the LogOnce function is set to the local transaction state of the participant corresponding to the second parameter and returns; if the LogOnce function call returns ready to terminate, the participant returns a conflict termination response to the coordinator and waits for the coordinator to send a rollback request; otherwise, the LogOnce function call returns ready to terminate, the participant returns a commit response to the coordinator and waits for the coordinator to send a commit request or a rollback request.

[0012] In an optional embodiment of the present application, the coordinator executes a first termination protocol process, including: the coordinator calls the function LogOnce (current transaction, participant P, ready to terminate) to each participant P of the current transaction, and waits for each participant to return a result according to the LogOnce function; if there is a participant that returns ready to terminate according to the LogOnce function, the coordinator sends a rollback request; if each participant returns ready according to the LogOnce function, the coordinator sends a commit request; if there is a participant that returns a timeout according to the LogOnce function, wait for the replica group to which the participant belongs to select a new participant to take over; the coordinator calls the function LogOnce (current transaction, new participant, ready to terminate) to the new participant until the new participant returns ready to terminate or ready according to the LogOnce function.

[0013] In an optional embodiment of the present application, the participant executes a second termination protocol process, including: marking the participant who has timed out waiting for the coordinator as the current participant, and marking the participants of the current transaction in which the current participant participates, except the current participant, as the remaining participants; the current participant calls the function LogOnce (current transaction, participant P, ready to terminate) to each remaining participant P, and waits for each remaining participant to return a result according to the LogOnce function; if there is a remaining participant that returns ready to terminate according to the LogOnce function, the current participant executes a rollback operation; if each remaining participant returns ready according to the LogOnce function, the current participant executes a commit operation; if there is a remaining participant that returns a timeout according to the LogOnce function, wait for the replica group to which the remaining participants belong to select a new participant to take over; the current participant calls the function LogOnce (current transaction, new participant, ready to terminate) to the new participant until the new participant returns ready to terminate or ready according to the LogOnce function.

[0014] In an optional embodiment of the present application, the rollback operation includes: the participant clears all four-tuples corresponding to the sub-transaction in the read set and write set constructed according to the sub-transaction, and clears all five-tuples corresponding to the sub-transaction in the transaction reservation table; the participant sets the log records of the sub-transaction in the maintained local master write-ahead log to a deleted state; the participant synchronizes the rollback request to the candidate to control all candidates to set the log records of the sub-transaction in the maintained local slave write-ahead log to a deleted state; the participant returns a response that does not contain any data item information to the coordinator.

[0015] In an optional embodiment of the present application, a commit operation includes: the participant sets the log record of the subtransaction in the maintained local master write-ahead log to a committed state, and updates the master replica according to the write set of the subtransaction; synchronizes the commit request to the candidate, controls the candidate to set the log record of the subtransaction in the maintained local slave write-ahead log to a committed state, and updates the slave replica according to the write set extracted from the log record of the subtransaction; the participant returns a response containing the read set of the subtransaction to the coordinator.

[0016] The present application also provides a computer-readable storage medium storing a computer program, which implements the aforementioned method when the computer program is executed by a processor.

[0017] The embodiments of the present application have the following beneficial effects: The multi-copy mechanism adopted in this application ensures that even if a participant fails, it will not affect the correct submission or rollback operation of the sub-transaction undertaken by the participant, thereby ensuring the fault tolerance of the system.

[0018] In the preparation phase, a lock-free conflict detection mechanism is introduced to detect write-write conflicts, write-read conflicts, or read-write conflicts at the data item granularity (rather than the coarser transaction granularity) between concurrent transactions without using any read-write locks. If the above conflicts are detected, the current transaction is prompted to restart execution, thereby avoiding the three major data inconsistency problems of dirty reads, non-repeatable reads, and phantom reads. In addition, this conflict detection mechanism allows transactions with read-read conflicts to be executed concurrently, thus breaking the limitation in the serialization isolation level that new transactions need to wait for other transactions to complete before they can be executed, greatly improving the concurrency of transaction processing.

[0019] In the case of a timeout of the coordinator or participant in the preparation or submission phase, this application introduces a solution mechanism in which the coordinator and the participant respectively execute different termination protocol processes, so as to promptly handle the timeout caused by the failure of the coordinator or the participant. This mechanism ensures that the failure of the coordinator and the participant can be properly handled in a timely manner, thus optimizing the 2PC protocol.

[0020] Finally, the full set of data items to be processed by the participants is divided into a read set and a write set. There is no need to send the full set of data items to the coordinator. Instead, it is only necessary to send the read set of the current transaction to the coordinator once when responding to the sub-transaction submission request. After conflict detection, a log record containing the read set and write set of the current transaction is sent to each candidate in the replica group, which reduces the amount of data transmitted over the network and improves transaction processing performance.

[0021] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented according to the contents of the specification, and in order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the following preferred embodiments are specifically cited and described in detail with the accompanying drawings. It should be understood that the above general description and the detailed description below are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0023] in: Figure 1 A schematic diagram of a process flow of a transaction processing method of a distributed transaction processing system provided by an embodiment; Figure 2 A schematic diagram of the hardware structure of a distributed transaction processing system provided by an embodiment; Figure 3 A data association diagram of a distributed transaction processing system provided by an embodiment; Figure 4 A timing diagram of a transaction processing failure requiring a client to terminate a transaction provided by an embodiment; Figure 5 A timing diagram of a transaction processing failure requiring a client to retry a transaction provided by an embodiment; Figure 6 A timing diagram of a transaction processing successfully returning a request result provided by an embodiment; Figure 7 A timing diagram of a coordinator waiting for a timeout but a transaction can still be successfully processed provided by an embodiment; Figure 8 A timing diagram of an embodiment in which a participant waits for a timeout but a transaction can still be successfully processed; Fig. 9 A schematic block diagram of the structure of a computer device provided by an embodiment. DETAILED DESCRIPTION

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

[0025] Distributed transaction processing systems have become an important part of modern distributed systems, ensuring data consistency and reliability in distributed systems. They usually include the following elements: (1) data partitioning - distributing data on different nodes to improve the scalability and availability of the system; (2) concurrency control - ensuring that multiple transactions do not interfere with each other when executed simultaneously, ensuring data consistency; (3) transaction management - responsible for coordinating the execution of transactions; (4) log management - recording transaction operations so that recovery can be performed when a system failure occurs.

[0026] Distributed transaction processing systems face many technical challenges, such as transaction isolation (ensuring that multiple transactions do not interfere with each other when executed simultaneously), transaction atomicity (ensuring that transactions are either all successful or all failed), and high performance (ensuring improved transaction processing efficiency and throughput). To address these challenges, distributed transaction processing systems usually process transaction requests submitted by users in two consecutive steps: (1) transaction decomposition - based on the data partitioning situation, the transaction is decomposed into sub-transactions for execution. Each sub-transaction only involves the data of a single node and is prepared to be executed in the node to which the data belongs; (2) transaction submission - each sub-transaction is executed in its own node to generate a read-write set; if the nodes to which the sub-transactions belong unanimously agree to submit, the system integrates the read-write sets of each node to reply to the user request, and each node uses the read-write set to update the local storage. Otherwise, the system ignores the read-write set in the node to which the sub-transaction belongs and retries or terminates the transaction. The submission step is the most critical of the two steps because it must ensure the isolation and atomicity of the transaction.

[0027] Existing distributed transaction processing systems widely use the two-phase commit (2PC) protocol to implement the commit step, ensuring that distributed transactions are either fully committed or fully rolled back in all participants (i.e., nodes that undertake subtransactions). The 2PC protocol consists of two phases: (1) the preparation phase - the coordinator sends a prepare request to all participants, and the participants vote based on the local transaction status and write it to the log; (2) the commit phase - the coordinator decides to commit or roll back based on the voting results and notifies all participants of the decision result. In order to ensure the isolation of transactions, the 2PC protocol can be combined with other technologies such as read-write locks and multi-version concurrency control (MVCC) to achieve different transaction isolation levels. The ANSI SQL standard defines several transaction isolation levels, including Read Uncommitted, Read Committed, Repeatable Read, and Serializable.

[0028] At the read uncommitted level, a transaction can read modifications that have not been committed by other transactions. This isolation level may lead to dirty read problems, that is, uncommitted modifications can be read, and if these modifications are later rolled back, data inconsistency will occur.

[0029] Read Committed is the default isolation level for many database management systems (including Oracle and SQL Server). At this isolation level, transactions can only read committed changes. This solves the dirty read problem, but may lead to non-repeatable reads, that is, the same data can be read differently twice in the same transaction.

[0030] Repeatable read is the default isolation level of MySQL. Under this isolation level, the transaction reads the same data in the entire transaction process, and the problem of non-repeatable read will not occur. However, phantom read may occur, that is, the result sets of two queries in the same transaction may be different.

[0031] Serialization is the most stringent isolation level. It avoids the problem of phantom reads by forcing transactions to be executed serially. At this isolation level, new transactions must wait for other transactions to complete before they can be executed. The performance of transaction processing depends on the transaction isolation level: the higher the transaction isolation level pursued by the distributed transaction processing system, the greater the time cost of transaction processing.

[0032] Although the 2PC protocol can ensure transaction atomicity and can be combined with other technical means to achieve different transaction isolation levels, the protocol has a blocking problem that affects the performance of distributed transaction processing. The blocking problem means that the coordinator needs to wait twice for the response of all participants before proceeding to the next step. If a participant does not respond for a long time, the coordinator needs to wait for a long time, resulting in a long delay, and the unfinished current transaction is likely to conflict with subsequent transactions, causing subsequent transactions to be continuously retried and blocked. For the 2PC problem of decomposable transactions, the existing technology has proposed a variety of optimization solutions, which are mainly divided into two categories.

[0033] The first category is optimization for shared-nothing architectures, including: reducing the latency of 2PC by making assumptions about workload and system characteristics, such as Early Prepare and Implicit Yes Vote, but these assumptions are not always applicable to decoupled storage architectures; alleviating blocking problems by adding an extra stage, such as EasyCommit and Babaoglu-Toueg protocols, but this increases network communication and complexity.

[0034] The second category is optimization for custom storage, including: Paxos Commit and the underlying Paxos consensus protocol jointly design 2PC, reduce latency by pre-preparing and skipping the Paxos leader, and avoid blocking through Paxos consensus, but require custom storage design and replication protocols; TAPIR and MDCC use customized replication protocols to weaken replica consistency and solve inconsistency problems by applying protocols, but require custom storage design and replication protocols; distributed databases CockroachDB and YugabyteDB use the Raft replication protocol to determine whether the commit operation is completed, but still cannot solve the blocking problem of 2PC.

[0035] It can be seen that although the existing technology has optimized 2PC to a certain extent, it still has problems such as poor flexibility and limited performance improvement. On the other hand, although 2PC combined with read-write lock technology can achieve the highest serialized transaction isolation level and solve the three major data inconsistency problems of dirty reads, non-repeatable reads and phantom reads, the serialized transaction isolation level requires ensuring that new transactions wait for other transactions to complete before they can be executed, which severely limits the concurrency of transaction processing, resulting in low transaction processing efficiency and throughput. Therefore, modern distributed transaction processing systems require new technical solutions that can not only optimize the 2PC protocol, but also solve the three major data inconsistency problems of dirty reads, non-repeatable reads and phantom reads while improving transaction processing concurrency, and achieve a transaction isolation level that is close to serialization. In this transaction isolation level, new transactions can be executed before other transactions are completed. For this purpose, the present application proposes a distributed transaction processing system transaction processing method. In order to clearly describe the distributed transaction processing system transaction processing method provided in this embodiment, please refer to Figure 1 to Figure 8 .

[0036] The method provided in this application is applied to a distributed transaction processing system. For ease of understanding, the structure and connection relationship of the distributed transaction processing system can be referred to Figure 2 , Figure 3 . The distributed transaction processing system is composed of multiple nodes, and each node stores corresponding data content. Furthermore, the distributed transaction processing system also includes a client and a coordinator. The client and the coordinator are deployed in the node. The two can be deployed in the same node or in different nodes respectively. Different deployment methods will not affect the method provided in this application, so there is no specific restriction on the specific deployment method. The client is the device end directly controlled by the user, which is used to obtain user needs and provide feedback to the user based on the processing results; the coordination end is the intermediate device of all nodes and clients, which is used to coordinate all nodes in the system to respond to and complete user needs. The specific execution process of the two will be explained in detail later, so I will not go into details here.

[0037] Before executing the method provided in this application, the distributed transaction processing system will divide all stored data into multiple data shards with a preset size upper limit for management. The specific number can be set arbitrarily according to the data size or demand. And the size of each data shard can be preset and does not need to be the same as each other. The system uses a multi-copy mechanism to distribute all data shards in various nodes for storage. For ease of understanding, in Figure 2 In the illustrated embodiment, the data is divided into only two data slices, namely, data slice 1 and data slice 2.

[0038] Furthermore, a data shard constructs a number of copies of the data content it stores, each copy has the same data content, and a data shard corresponds to a copy group. At the same time, the system provided by the present application can select a copy from a copy group as the master copy according to a preset consensus protocol, and the remaining copies are marked as slave copies. Among them, any consensus protocol (such as Paxos and Raft) can be used for the election and consensus determination of the master copy. The limitation of the specific consensus protocol does not exceed the scope of protection of the present invention. During the execution process, the actual data processing process is directly processed for the master copy, and the slave copy changes according to the changes of the master copy. The specific synchronization process will be explained in detail later. In a preferred embodiment, a single node does not store all data, and each data shard has a copy only on a preset number (not all) nodes.

[0039] As can be seen from the above description, the replicas in the same replica group are stored in different nodes. For the same replica group, the node storing the primary replica is called a participant, and the node storing the secondary replica is called a candidate. Based on this, to facilitate understanding of the distributed transaction processing system provided by this application, you can refer to Figure 2 As shown, Figure 2 Taking three nodes and two replica groups as an example, the structural relationship between multiple nodes, clients, coordinators, and multiple replicas in the system is demonstrated.

[0040] Furthermore, the client is associated with the coordinator, the coordinator is associated with all nodes, and the participants are associated with each other. For the connection relationship between each functional module, please refer to Figure 3 shown. Figure 3 continue Figure 2The examples provided show the relationship between the functional modules. The coordinator, as the intermediate module between each replica and client, is connected to all replicas and clients respectively. Furthermore, the participants are also interconnected to facilitate information exchange under specific circumstances. In other words, the participants of the same transaction are independent of each other, but know each other's access addresses. The coordinator and participants can send information to each other to exchange sub-transaction processing status. In addition, for the same replica group, participants are also associated with all candidates to synchronize data changes within the participants to the candidates to ensure data reliability. It is worth noting that the system's data shards and their replica groups are determined before the first transaction is processed.

[0041] The transaction processing method of the distributed transaction processing system provided in this embodiment specifically includes steps S110 to S180.

[0042] Step S110: After obtaining the transaction processing request issued by the user, the client forwards the transaction and the transaction processing request to the coordinator. The transaction consists of a single or multiple statements; the coordinator performs a transaction decomposition operation on the transaction to obtain several sub-transactions, each of which involves only data items in one data shard.

[0043] In one embodiment, after the user issues a transaction request on the client, the client can search for the transaction corresponding to the transaction request. It is worth noting that the transactions processed by the system are composed of a single or multiple statements. Afterwards, the client can forward the transaction and the corresponding transaction request to the coordinator, and the coordinator coordinates multiple nodes to process the transaction. In order to allow the transaction to be processed by multiple nodes, the transaction can be decomposed, that is, the decomposition operation is performed. The transaction decomposition is called a sub-transaction, and a transaction decomposition can obtain several sub-transactions. Furthermore, in order to ensure the integrity of the processing of each node, each sub-transaction obtained by the decomposition only involves data items in one data shard. In other words, the sub-transaction and the data shard have a certain correlation. For this, the corresponding sub-transaction can be processed by the node storing the corresponding data shard in the subsequent execution process. If the same node has multiple data shards {T1, T2,…, T n}, then the node acts as the primary replica of T1,T2,…,T n The corresponding n sub-transaction participants.

[0044] Step S120: The coordinator constructs a prepare request for each subtransaction and sends the prepare request to the corresponding participant. The participant enters the prepare phase according to the prepare request and performs prepare operations on the subtransaction. The prepare operations include data constraint detection, concurrency conflict detection, logging operations and state synchronization operations.

[0045] Step S130: the participant generates a feedback response according to the local transaction status obtained by the preparation operation, and returns the feedback response to the coordinator. The local transaction status is one of ready and ready to terminate, and the feedback response is one of commit response, breach termination response and conflict termination response.

[0046] In one embodiment, the technical solution of the present application optimizes 2PC under a multi-copy mechanism. Based on this transaction decomposition, the transaction is split into multiple sub-transactions; each sub-transaction corresponds to a data shard, and a data shard corresponds to a replica group. The replica group is divided into a unique master replica and the remaining slave replicas according to a preset consensus protocol. The node storing the master replica is called a participant. Therefore, the coordinator can construct a preparation request for each sub-transaction and send the preparation request to the participant corresponding to each sub-transaction, thereby starting the 2PC process.

[0047] The 2PC protocol consists of two phases: (1) Preparation phase - the coordinator sends a preparation request to all participants, and the participants vote based on the local transaction status and write it to the log; (2) Commit phase - the coordinator decides to commit or rollback based on the voting results, and notifies all participants of the decision results. According to the preparation request, the participant will enter the preparation phase and immediately and independently execute the subtransaction it undertakes. Specifically, it is to perform preparation operations, which include data constraint detection, concurrency conflict detection, logging operations and state synchronization operations. In a preferred embodiment, the preparation operations are performed in the order of data constraint detection, concurrency conflict detection, logging operations and state synchronization operations. The specific execution process will be described in detail later.

[0048] In one embodiment, data constraint detection includes: after receiving a prepare request, a participant creates a read set and a write set according to a subtransaction, the read set and the write set are composed of a four-tuple, and the four-tuple includes a data item, a transaction ID, a statement ID, and a read / write time; when creating the read set and the write set, the participant performs data constraint detection to determine whether the data item meets the preset data constraints; if the data item does not meet the data constraint, the participant sends a default termination response to the coordinator and ends the prepare phase of the subtransaction, and no longer performs concurrency conflict detection, logging operations, and state synchronization operations; if the data item meets the data constraint, the participant performs concurrency conflict detection on the subtransaction it undertakes according to the created read set and write set.

[0049] In one embodiment, after a participant receives a prepare request and enters the prepare phase, the participant can first create a read set and a write set based on a subtransaction. The read set and the write set are composed of a four-tuple, which includes a data item, a transaction ID, a statement ID, and a read / write time. Among them, this application defines the basic data unit of transaction processing as a data item. The data item is defined according to the content stored in the system. For example, when the storage content is a set of key-value pairs used in a key-value storage system, the data item is defined as a single key-value pair; it can also be any other basic data unit, such as a row or column in a traditional data form. The limitation of specific basic data units does not exceed the scope of protection of this application.

[0050] Participants can detect preset data constraints, which is data constraint detection, during the process of creating read sets and write sets. Preset data constraints include data integrity constraints and user-defined constraints. These constraints are generally used to determine the legality and consistency of data content, such as "height values ​​are above 0.5 meters" and "functional field values ​​of the same entity are unique". Such preset data constraints can be commonly used data integrity constraints or user-defined constraints in the database field. The determination of whether these data constraints are violated (i.e., breach of contract determination) can rely on a general automatic reasoner or a customized executable program. Limiting specific data constraints or breach of contract determination methods does not exceed the scope of protection of this application.

[0051] If the data item does not satisfy the data constraint, the participant sends a default termination response to the coordinator and ends the preparation phase of the subtransaction, and no longer performs concurrent conflict detection, log recording operations, and state synchronization operations. Then, step S140 will be executed, and the specific execution process will be described later.

[0052] If the data item satisfies the data constraint, it is considered to have passed the data constraint test, and the participant will perform subsequent concurrency conflict detection on the subtransactions undertaken based on the created read set and write set. Concurrency conflict detection will be described in detail later.

[0053] In one implementation, a participant maintains a transaction reservation table, which consists of a five-tuple, including a data item, a transaction ID, a statement ID, a read / write tag, and a read / write time; the read / write time is the local time of the participant; the participant locally records the start time and commit time of the transaction in which it is located, the start time being the time when the participant receives the first subtransaction prepare request, and the commit time being the time when the participant receives the last subtransaction commit request; for the participant, a transaction whose commit time has been defined in the transaction reservation table is called a completed transaction; a transaction whose commit time is not set in the transaction reservation table is called an unfinished transaction; concurrency conflict detection includes: if there is an unfinished transaction in the subtransaction processed by the participant, the unfinished transaction has a corresponding write five-tuple in the transaction reservation table, and the write time of the unfinished transaction is shorter than the four-tuple about the current transaction for the same data item in the participant's read set or write set. , the current transaction is the subtransaction being processed by the participant, or if there is a completed transaction in the subtransaction processed by the participant, the commit time of the completed transaction is greater than the start time of the current transaction, and the completed transaction has a corresponding write quintuple in the transaction reservation table, and the write time of the completed transaction is smaller than the maximum read / write time of the quintuple about the current transaction for the same data item in the participant's read set or write set, or if there is a quintuple for the current transaction in the participant's write set, and the write time of the quintuple is smaller than the maximum read / write time of the quintuple for the same data item in the transaction reservation table, then it is considered that the concurrency conflict detection cannot be passed, and the participant sends a conflict termination response to the coordinator, ends the preparation phase of the subtransaction, and no longer executes logging operations and state synchronization operations; if it is not the above situation, then it is considered that the concurrency conflict detection can be passed, and logging operations and state synchronization operations continue to be executed.

[0054] In one embodiment, each participant performs conflict detection based on a transaction reservation table maintained by itself. The transaction reservation table consists of five tuples, which include data items, transaction IDs, statement IDs, read / write flags, and read / write times. The read / write time is the local time of the participant. Each participant locally records the start time and commit time of the transaction in which it is located. Both times are the local time of the participant, where the start time is the time when the participant receives the first subtransaction prepare request, and the commit time is the time when the participant receives the last subtransaction commit request. It is worth noting that a single participant may contain multiple master copies involved in multiple subtransactions, and therefore may receive prepare requests and commit requests for multiple subtransactions.

[0055] For participants, transactions whose commit time has been set in the transaction reservation table are called completed transactions; transactions whose commit time has not been set in the transaction reservation table are called unfinished transactions. In addition, there are abandoned transactions in the transaction reservation table. Abandoned transactions are defined as transactions whose maximum read / write time is less than the minimum start time of all unfinished transactions. All five-tuples contained in abandoned transactions will be cleared periodically.

[0056] The concurrency conflict detection technology solution provided by this application introduces a lock-free conflict detection mechanism. It does not need to introduce read-write locks to ensure the serialization of transaction processing. Instead, it ensures the quasi-serialization of transaction processing through conflict detection at the data item granularity. This conflict detection mechanism determines that the current transaction has a data item conflict with other transactions when one of the following situations (a), (b) or (c) is met, and the 2PC process of the current transaction needs to be restarted. The following three situations are considered to be the cases where the subtransactions undertaken by specific participants fail the concurrency conflict detection: (a) There is an unfinished transaction in the subtransaction processed by the participant, the unfinished transaction has a corresponding write quintuple in the transaction reservation table, and the write time of the unfinished transaction is smaller than the maximum read / write time of the quintuple of the current transaction for the same data item in the participant's read set or write set; (b) There is a completed transaction in the subtransaction processed by the participant, the commit time of the completed transaction is greater than the start time of the current transaction, and the completed transaction has a corresponding write quintuple in the transaction reservation table, and the write time of the completed transaction is smaller than the maximum read / write time of the quaternary group of the current transaction for the same data item in the participant's read set or write set; (c) There is a four-tuple for the current transaction in the participant's write set, and the write time of the four-tuple is smaller than the maximum read / write time of the five-tuple for the same data item in the transaction reservation table.

[0057] The current transaction is the subtransaction that the participant is processing. Situations (a) and (b) mean that between the start time of the participant's current transaction and the commit time of the current transaction, there may be other transactions that rewrite the same data items of the current transaction in the participant's read set or write set, that is, a read-write conflict or a write-write conflict may occur.

[0058] Condition (c) means that between the start time of the participant's current transaction and the commit time of the current transaction, the current transaction may overwrite the same data item of other transactions, that is, a write-read conflict or a write-write conflict may occur.

[0059] The present application provides a method that uses situations (a), (b) and (c) to eliminate write-write conflicts, write-read conflicts and read-write conflicts that may occur in multiple concurrent transactions, thereby avoiding the three major data inconsistency problems of dirty reads, non-repeatable reads and phantom reads. At the same time, the above situation will not eliminate read-read conflicts among multiple concurrent transactions, thus breaking the limitation in the serialization isolation level that new transactions need to wait for other transactions to complete before they can be executed, greatly improving the concurrency of transaction processing.

[0060] Specifically, if the above situation exists, it is considered that a subtransaction conflict is detected and the concurrent conflict detection fails. Accordingly, the participant stops processing the current transaction, sends a conflict termination response to the coordinator, and ends the preparation phase of the subtransaction, and no longer performs logging operations and state synchronization operations. Step S150 will be executed later, and the specific execution process will be described later.

[0061] If none of the above situations occurs, it is considered that the concurrency conflict detection can be passed and subsequent logging operations and state synchronization operations can continue to be executed.

[0062] In one embodiment, a participant maintains a local master write-ahead log, and a candidate maintains a local slave write-ahead log, both of which are composed of multiple log records, and the log records are used to record the read set, write set, transaction reservation table and processing status of the sub-transaction; performing a log record operation includes: the participant constructs a log record according to the read set, write set and transaction reservation table of the sub-transaction, and adds the log record to the local master write-ahead log of the master replica corresponding to the sub-transaction; sending the log record to the local slave write-ahead log of the slave replica of the replica group corresponding to the sub-transaction until the replica group meets the consensus condition of the preset consensus protocol, and ends the log record operation.

[0063] In one embodiment, after passing the data constraint check and the concurrency conflict check, it can be considered that the participant has completed the preparation of the subtransaction, that is, the local transaction state of the subtransaction can be marked as ready. Correspondingly, if the data constraint check or the concurrency conflict check is not passed, the local transaction state is marked as ready to terminate. For the completed preparation, the subtransaction state generation log record can be recorded. The participants and candidates of the replica group maintain persistent (for example, stored in disk files) write-ahead logs, wherein the participants maintain a local master write-ahead log and the candidates maintain a local slave write-ahead log.

[0064] Both the landlord write-ahead log and the local slave write-ahead log consist of multiple log records, which are used to record the read set, write set, transaction reservation table, and processing status of the subtransaction. Each log record has a status bit that records the status (unprocessed / committed / deleted), which is initialized to the unprocessed state. When the leader election mechanism of the preset consensus protocol elects a candidate as a new participant, the candidate reconstructs the read set, write set, and transaction reservation table that the participant needs to have based on the unprocessed or committed log records. When a participant or candidate recovers from a failure, first locate the first committed log record that contains a write set but does not update the local copy. Starting from this log record, process the subsequent committed log records containing the write set one by one, and use the write set in the log record to update the local copy.

[0065] The specific steps for executing the logging operation may be that the participant constructs the log record according to the read set, write set and transaction reservation table of the subtransaction, and adds the constructed log record to the local master write-ahead log. After that, the participant can send the log record to all candidates corresponding to the subtransaction. The candidate adds the log record to the local slave write-ahead log maintained by it. When the replica group meets the consensus conditions of the preset consensus protocol (for example, more than half of the replicas in the Paxos or Raft protocol have added the log record to the write-ahead log), the participant ends the logging operation and enters the state synchronization operation.

[0066] It is worth noting that in the multi-copy mechanism, the node where the master copy is located needs to transmit log records to the node where the slave copy is located. This application does not specifically limit the log records of the current transaction, including the number and content of log records. It only requires that the transmitted log records cover the read set, write set and transaction reservation table subset of the current transaction of the participant corresponding to the master copy, so as to ensure that the candidate can reconstruct the read set, write set and transaction reservation table after replacing the participant and becoming a new participant. Limiting the specific log record information does not exceed the scope of protection of this application.

[0067] In one embodiment, the state synchronization operation includes: executing after the data items of the subtransaction pass data constraint detection, concurrency conflict detection and log recording operations; each participant P calls the function LogOnce (current transaction, participant P, ready) to record the local state of the subtransaction locally in the participant P, and the parameters of the LogOnce function are transaction ID, participant ID, and subtransaction local state; if the participant corresponding to the second parameter in the LogOnce function has recorded the local transaction state of the transaction corresponding to the first parameter in the LogOnce function, the LogOnce function returns the local transaction state recorded locally by the participant corresponding to the second parameter, otherwise the subtransaction local state corresponding to the third parameter in the LogOnce function is set to the local transaction state of the participant corresponding to the second parameter and returns; if the LogOnce function call returns ready to terminate, the participant returns a conflict termination response to the coordinator and waits for the coordinator to send a rollback request; otherwise, the LogOnce function call returns ready to terminate, the participant returns a commit response to the coordinator and waits for the coordinator to send a commit request or a rollback request.

[0068] In one embodiment, after completing the logging operation, the participants will perform a state synchronization operation. Specifically, each participant P calls the function LogOnce (current transaction, participant P, ready) to record the local state of the subtransaction locally in the participant P. The LogOnce function called includes three parameters: transaction ID, participant ID, and subtransaction local state. The specific function of the LogOnce function is to record the local state of the subtransaction locally in the participant P. If the participant corresponding to the second parameter in the LogOnce function has recorded the local transaction state of the transaction corresponding to the first parameter in the LogOnce function, the LogOnce function returns the local transaction state recorded locally by the participant corresponding to the second parameter, otherwise the local state of the subtransaction corresponding to the third parameter in the LogOnce function is set to the local transaction state of the participant corresponding to the second parameter and returned.

[0069] Therefore, if the LogOnce function call returns Prepared to Terminate, participant P has been identified by the coordinator as having timed out from preparation. In this case, participant P returns a termination response to the coordinator, prompting the coordinator to make a decision to roll back the transaction during the Prepare phase. Otherwise, the LogOnce function call returns Ready. In this case, participant P returns a Commit response to the coordinator and waits for the coordinator's subtransaction commit or rollback request.

[0070] After step S130, multiple possibilities will be generated, and different operations will be performed for different possibilities. In this application, there are 5 possible results, corresponding to steps S140 to S180 respectively.

[0071] In one embodiment, steps S140-S180 control the participants to enter the submission phase of the 2PC process. In the submission phase, no matter what the result is, only two operations will be performed for the participants, either submission or rollback, corresponding to the submission operation and rollback operation respectively. The participants may respond according to the instructions issued by the coordinator, or they may perform self-detection and self-execution under specific circumstances. Therefore, the rollback operation and the submission operation are first explained.

[0072] In one embodiment, the rollback operation includes: the participant clears all four-tuples corresponding to the sub-transaction in the read set and write set constructed according to the sub-transaction, and clears all five-tuples corresponding to the sub-transaction in the transaction reservation table; the participant sets the log records of the sub-transaction in the maintained local master write-ahead log to a deleted state; the participant synchronizes the rollback request to the candidate to control all candidates to set the log records of the sub-transaction in the maintained local slave write-ahead log to a deleted state; the participant returns a response that does not contain any data item information to the coordinator.

[0073] In one embodiment, the rollback operation is as follows: the participant clears the local read set, write set, and multi-tuple records of the current transaction in the transaction reservation table, sets the log records of the current transaction in the local master write-ahead log to the deleted state, and synchronizes the rollback request to the candidates of the replica group, prompting all candidates to also set the log records of the current transaction in the local slave write-ahead log to the deleted state. Finally, the participant returns a response without any data item information to the coordinator to indicate that the rollback operation is completed.

[0074] In one embodiment, a commit operation includes: the participant sets the log record of the subtransaction in the maintained local master write-ahead log to a committed state, and updates the master replica according to the write set of the subtransaction; synchronizes the commit request to the candidate, controls the candidate to set the log record of the subtransaction in the maintained local slave write-ahead log to a committed state, and updates the slave replica according to the write set extracted from the subtransaction log record; the participant returns a response containing the read set of the subtransaction to the coordinator.

[0075] In one embodiment, the commit operation is as follows: the participant sets the log record of the current subtransaction in the local master write-ahead log to the committed state, updates the local master replica according to the write set of the current transaction, and synchronizes the commit request to the candidates of the replica group, prompting all candidates to also set the log record of the current subtransaction in the local slave write-ahead log to the committed state, extract the write set from the log record and update the local slave replica. Finally, the participant returns a response containing the read set of the current transaction to the coordinator.

[0076] Step S140: If the coordinator receives a default termination response from at least one participant, it sends a rollback request to all participants to control all participants to perform a rollback operation, and sends a transaction termination request to the client.

[0077] In one embodiment, to facilitate understanding of the process corresponding to step S140, reference may be made to Figure 4 The timing diagram is shown. Figure 4 The timing diagram shown shows the process of requesting the client to terminate the transaction due to transaction processing failure, that is, for the case where the sub-transaction fails the data constraint test in the preparation phase. In this case, the participant that fails the data constraint test will return a default termination response. As long as any participant feeds back a default termination response, the coordinator will control all participants to roll back, because in this case the current transaction cannot meet the preset data constraints even if it is retried, and the transaction can no longer be executed. At the same time, the coordinator sends a termination transaction request to the client containing the reason why the transaction cannot be executed. The execution process of the rollback operation has been described in detail in the previous article and will not be expanded here.

[0078] Step S150: If the coordinator does not receive a default termination response from any participant but receives a conflict termination response from at least one participant, it sends a rollback request to all participants to control all participants to perform a rollback operation, and sends a retry transaction request to the client.

[0079] In one embodiment, to facilitate understanding of the process corresponding to step S150, reference may be made to Figure 5 The timing diagram is shown. Figure 5 The timing diagram shown shows the processing flow of requesting the client to retry a transaction when a transaction fails, that is, for a situation where there is no default termination response fed back by a participant but a conflict termination response fed back by any participant is received, this situation indicates that a participant has failed the concurrent conflict detection. In this case, a rollback request is first sent to all participants to control all participants to perform a rollback operation. Relatively speaking, in this case, there is still the possibility of continuing to execute the transaction, and a request to retry the transaction can be issued to the client. The method provided in this application is executed here according to the instructions fed back by the client.

[0080] Furthermore, after steps S140 and S150, if the coordinator subsequently receives a feedback response from a participant in the preparation phase, it sends a subtransaction rollback request to the participant, but no longer sends information to the client.

[0081] Step S160: If all participants feedback a commit response, the coordinator constructs a commit request for each participant and sends it. The commit request is used to control the participant to enter the commit phase. The coordinator obtains the read set returned by the participant after executing the commit operation, integrates all received read sets, synthesizes the request result and feeds back to the client.

[0082] In one embodiment, to facilitate understanding of the process corresponding to step S160, reference may be made to Figure 6 The timing diagram is shown. Figure 6 The timing diagram shown shows the processing flow of the transaction processing successfully returning the request result. Correspondingly, all participants feedback the commit response, indicating that all participants are ready. The coordinator can make the decision to commit the transaction, construct and send the commit request of each participant. The commit request is used to control the participants to enter the commit phase. The participants perform the commit operation and return the read set obtained by executing the commit operation to the coordinator. The execution flow of the commit operation has been described in detail in the previous article and will not be expanded here. After each participant has a response, the coordinator integrates the read sets contained in each response, synthesizes the request result and sends it to the client.

[0083] This application divides the full set of data items to be processed by the participants into a read set and a write set. There is no need to send the full set of data items to the coordinator. Instead, it is only necessary to send the read set of the current transaction to the coordinator once when responding to a sub-transaction submission request. After passing the conflict detection, a log record containing the read set and write set of the current transaction is sent to each candidate in the replica group, thereby reducing the amount of data transmitted over the network and improving transaction processing performance.

[0084] Furthermore, during the execution of the process provided by the present application, there may be a situation where the coordinator or participant waits for a timeout. In response to this, the present application introduces a first termination protocol process and a second termination protocol process for waiting timeouts, so as to handle them in a timely manner when a failure causes a timeout. This timely processing mechanism ensures that in certain circumstances, even if the coordinator or participant waits for a timeout, the transaction can still be successfully processed. For an understanding of the first termination protocol process and the second termination protocol process, please refer to Figure 7 and Figure 8 , Figure 7 A timing diagram showing that the coordinator waits for a timeout but the transaction is still successfully processed. Figure 8 A sequence diagram showing that a participant wait times out but the transaction is still successfully processed.

[0085] Step S170: If the coordinator times out waiting for a response from a participant, the coordinator executes the first termination protocol process.

[0086] In one embodiment, the coordinator executes a first termination protocol process, including: the coordinator calls the function LogOnce(current transaction, participant P, ready to terminate) to each participant P of the current transaction, and waits for each participant to return a result according to the LogOnce function; if there is a participant that returns ready to terminate according to the LogOnce function, the coordinator sends a rollback request; if each participant returns ready according to the LogOnce function, the coordinator sends a commit request; if there is a participant that returns a timeout according to the LogOnce function, wait for the replica group to which the participant belongs to select a new participant to replace it; the coordinator calls the function LogOnce(current transaction, new participant, ready to terminate) to the new participant until the new participant returns ready to terminate or ready according to the LogOnce function.

[0087] In one embodiment, during the execution process, the coordinator may wait for a certain participant to time out. In this case, the coordinator executes the first termination protocol process to resolve it. Specifically, during the execution of the first termination protocol process, the coordinator will call the termination protocol implementation function CoordinatorTerminationProtocol (current transaction). The CoordinatorTerminationProtocol function is a termination protocol implementation function called by the coordinator. The parameters include the current transaction ID, which is used to call LogOnce (current transaction, R, termination) for all participants R corresponding to the current transaction to view the local transaction processing status of all participants. The coordinator waits for each participant to operate according to the result returned by the LogOnce function. The definition of the LogOnce function has been detailed in the previous text and will not be repeated here. In other words, in the first termination protocol process processing flow, the coordinator can communicate with all participants to determine the local transaction status of all participants, and thus decide whether to commit or roll back, avoiding invalid waiting and improving processing efficiency.

[0088] If a participant returns preparation termination according to the LogOnce function, it means that a participant has failed to prepare, and the coordinator needs to send a rollback request to all participants to control all participants to perform the rollback operation.

[0089] If each participant returns ready according to the LogOnce function, it means that all participants are ready and can submit. The coordinator can then send a submission request to all participants to control the participants to enter the submission phase.

[0090] If a participant returns a timeout according to the LogOnce function, the coordinator waits for the replica group to select a new participant to take over; the coordinator calls the function LogOnce(current transaction, new participant, ready to terminate) to the new participant until the new participant returns ready to terminate or is ready according to the LogOnce function.

[0091] Furthermore, the introduction of the first termination protocol process enables the coordinator to perform timely control according to the timing of the failure of the participant. If a participant P fails before receiving the subtransaction preparation request, the replica group where P is located uses the preset consensus protocol to re-elect a new primary replica and its corresponding participant Q. At this time, the coordinator must time out waiting for the response of participant P, so that the coordinator executes the first termination protocol process. Inevitably, the call of LogOnce(current transaction, P, termination) also times out, so the coordinator identifies the new participant Q in the replica group where P is located and calls LogOnce(current transaction, Q, termination) again. Since Q has not received the subtransaction preparation request, LogOnce(current transaction, Q, termination) must return termination, prompting CoordinatorTerminationProtocol(current transaction) to return termination, so the coordinator can make a timely decision to roll back the transaction and send a subtransaction rollback request to all participants (at this time, Q has replaced P). Participants that have not yet entered the preparation stage, such as Q, automatically ignore the subtransaction rollback request. Participant R in the preparation stage also ignores the subtransaction rollback request, and then makes corresponding processing according to two situations: (Case 1) If the subtransaction fails to pass the data constraint check or concurrency conflict check during execution, R returns a termination response to the coordinator and enters the commit phase. The coordinator then sends a subtransaction rollback request to R again. (Case 2) After the subtransaction is executed normally and the log record is synchronized with the slave replica, R calls LogOnce(current transaction, R, ready). Since the coordinator has previously called LogOnce(current transaction, R, terminated), LogOnce(current transaction, R, ready) returns terminated, so R also returns a terminated response to the coordinator and enters the commit phase. Then the coordinator sends a subtransaction rollback request to R again. After receiving the subtransaction rollback request, the participant in the commit phase directly executes the transaction rollback operation.

[0092] If a participant P fails after receiving a subtransaction prepare request and before returning a commit or termination response, the replica group where P is located uses the preset consensus protocol to re-elect a new primary replica and its corresponding participant Q. At this time, the coordinator must time out waiting for the response of participant P, so it calls the termination protocol implementation function CoordinatorTerminationProtocol(current transaction) and calls LogOnce(current transaction, R, termination) for all participants R. Inevitably, the call to LogOnce(current transaction, P, termination) also times out, so the coordinator identifies the new participant Q in the replica group where P is located and calls LogOnce(current transaction, Q, termination) again. This LogOnce function call for Q must return termination, so CoordinatorTerminationProtocol(current transaction) also returns termination, prompting the coordinator to make a timely decision to roll back the transaction and send a subtransaction rollback request to all participants. Similarly, subsequent processing will cause all participants in the current transaction to perform a transaction rollback operation.

[0093] If a participant P fails after returning a submission response, the replica group to which P belongs uses the preset consensus protocol to re-elect a new primary replica and its corresponding participant Q. At this time, the coordinator handles the following three situations: (Case 1) The coordinator has made a commit decision and sent a subtransaction commit request to all participants. At this time, the coordinator must time out waiting for the response of participant P. Therefore, the coordinator identifies the new participant Q in the replica group where P is located and sends a subtransaction commit request to Q. Then Q replaces P to perform the transaction commit operation; (Case 2) The coordinator has made a rollback decision and sent a subtransaction rollback request to all participants. At this time, the coordinator must time out waiting for the response of participant P. Therefore, the coordinator identifies the new participant Q in the replica group where P is located and sends a subtransaction rollback request to Q. Then Q replaces P to perform the transaction rollback operation; (Case 3) The coordinator has not made a decision to commit or rollback. At this time, the coordinator is still in the preparation stage. It will continue to wait for the commit or termination response from other participants except P. If all other participants return a commit response, the process will be transferred to the above case 1. If any other participant returns a termination response, the process will be transferred to the above case 2.

[0094] If a participant P fails after returning a termination response, the replica group where P is located uses the preset consensus protocol to re-elect a new primary replica and its corresponding participant Q. At this time, the coordinator must have made a rollback decision and sent a subtransaction rollback request to all participants. After that, the coordinator must have timed out waiting for the response from participant P, so the coordinator identifies the new participant Q in the replica group where P is located and sends a subtransaction rollback request to Q, and then Q replaces P to perform the transaction rollback operation.

[0095] Step S180: If the participant's waiting for the request from the coordinator times out, the participant executes a second termination protocol process.

[0096] In one embodiment, the participant executes the second termination protocol process, including: marking the participant who has timed out waiting for the coordinator as the current participant, and marking the participants of the current transaction in which the current participant participates, except the current participant, as the remaining participants; the current participant calls the function LogOnce (current transaction, participant P, ready to terminate) to each remaining participant P, and waits for each remaining participant to return a result according to the LogOnce function; if there is a remaining participant that returns ready to terminate according to the LogOnce function, the current participant executes a rollback operation; if each remaining participant returns ready according to the LogOnce function, the current participant executes a commit operation; if there is a remaining participant that returns timeout according to the LogOnce function, wait for the replica group to which the remaining participants belong to select a new participant to take over; the current participant calls the function LogOnce (current transaction, new participant, ready to terminate) to the new participant until the new participant returns ready to terminate or ready according to the LogOnce function.

[0097] In one embodiment, the participant may also time out waiting for the coordinator to respond during the execution of the process. In this case, the participant executes the second termination protocol process to resolve it. Specifically, in the execution of the second termination protocol process, the participant who has timed out waiting for the coordinator is marked as the current participant, and the participants of the current transaction in which the current participant participates, except the current participant, are marked as the remaining participants. The current participant Q will execute the termination protocol implementation function ParticipantTerminationProtocol (current transaction, Q). The ParticipantTerminationProtocol function is a termination protocol implementation function called by the current participant Q. The parameters include the current transaction and the current participant ID, which is used to call LogOnce (current transaction, participant P, ready to terminate) for each remaining participant P in the current transaction except Q. The current participant Q waits for each remaining participant P to return a result to operate. In other words, in the case of a timeout waiting for the coordinator, the current participant Q can imitate the function of the coordinator to check the local transaction status of all participants under the current transaction, so as to decide whether to commit or roll back, thereby avoiding invalid waiting and improving processing efficiency.

[0098] There may be multiple results when the current participant Q calls LogOnce(current transaction, participant P, ready to terminate), so different operations can be performed for different results: If there is any other participant P that returns the preparation termination according to the LogOnce function, it can be determined that the preparation of the other participant P has failed, the transaction processing cannot be carried out, and the current participant Q can perform the rollback operation; If all other participants return ready according to the LogOnce function, it can be determined that all other participants are ready, and the current participant Q can perform the commit operation without waiting for the coordinator to send a commit request; If there is a remaining participant P that returns a timeout according to the LogOnce function, then wait for the replica group where the remaining participant P is located to select a new participant R to take over; the current participant calls the function LogOnce (current transaction, new participant R, ready to terminate) to the new participant R until the new participant R returns ready to terminate or is ready according to the LogOnce function.

[0099] Similar to the first termination protocol process, the introduction of the second termination protocol process can prompt the current participants to perform timely control according to the timing of the coordinator failure. If the coordinator fails before issuing any subtransaction prepare request, the participant cannot receive the subtransaction prepare request and the participant does not need to take any action.

[0100] If the coordinator fails after issuing some subtransaction prepare requests and before issuing all subtransaction prepare requests, the coordinator will inevitably fail to receive responses from some participants on time after the failure is recovered. At this time, the coordinator must call the termination protocol implementation function CoordinatorTerminationProtocol(current transaction) and obtain the return result of the termination, so as to make a decision to roll back the transaction and issue a subtransaction rollback request to all participants.

[0101] If the coordinator fails after sending all subtransaction prepare requests and before sending subtransaction commit requests to all participants, there must be a current participant Q that has timed out waiting for the coordinator's subtransaction commit request. At this time, the current participant Q calls the termination protocol implementation function ParticipantTerminationProtocol(current transaction, Q), and calls LogOnce(current transaction, P, termination) for each remaining participant P of the current transaction except Q. If there is another participant P that makes the LogOnce function call return termination, P does not respond to the coordinator's subtransaction prepare request, and the coordinator does not make a decision to commit the transaction; when P needs to return a response to the subtransaction prepare request, P calls LogOnce(current transaction, P, ready) and must get a termination return result, so the response returned by P to the coordinator is termination, prompting the coordinator to make a decision to roll back the transaction, so ParticipantTerminationProtocol(current transaction, Q) returns termination and prompts the current participant Q to perform the transaction rollback operation in a timely manner. If all other participants have made the LogOnce function call return ready, all participants of the current transaction, including the current participant Q itself, have returned a commit response to the coordinator, so ParticipantTerminationProtocol (current transaction, Q) returns commit and prompts the current participant Q to perform the transaction commit operation in a timely manner.

[0102] If the coordinator fails after issuing all subtransaction prepare requests and before issuing subtransaction rollback requests to all participants, there must be a current participant Q whose subtransaction rollback request waiting for the coordinator has timed out. At this time, the current participant Q calls the termination protocol implementation function ParticipantTerminationProtocol(current transaction, Q), and calls LogOnce(current transaction, P, termination) for each remaining participant P of the current transaction except the current participant Q. Since the subtransaction rollback request is issued only after the coordinator makes the decision to roll back the transaction, there must be a remaining participant P that has returned a termination response to the coordinator, so that the LogOnce function call for P returns termination. Therefore, ParticipantTerminationProtocol(current transaction, Q) returns termination, prompting the current participant Q to perform the transaction rollback operation in a timely manner.

[0103] If the coordinator fails after sending a subtransaction commit request to all participants, all participants have started the transaction commit operation. All participants need to wait for the coordinator to recover and return a response containing the current transaction read set to the coordinator.

[0104] If the coordinator fails after sending a subtransaction rollback request to all participants, all participants have already started the transaction rollback operation. Since all participants do not need to return a response to the coordinator, the failure of the coordinator has no impact on all participants.

[0105] In summary, the above fault handling process ensures that the coordinator and participants can be properly handled in a timely manner when a fault occurs, and optimizes the 2PC protocol. In addition, when the participant enters the commit phase of the transaction commit step, the system's multi-copy mechanism ensures that even if a participant fails, it will not affect the correct commit or rollback operation of the sub-transaction undertaken by the participant, thereby ensuring the fault tolerance of the system.

[0106] In the preparation stage, the conflict detection mechanism introduced in this application detects write-write conflicts, write-read conflicts, or read-write conflicts at the data item granularity (rather than the coarser transaction granularity) between concurrent transactions without using any read-write locks. If the above conflicts are detected, the current transaction is prompted to restart execution, thereby avoiding the three major data inconsistency problems of dirty reads, non-repeatable reads, and phantom reads. In addition, this conflict detection mechanism allows transactions with read-read conflicts to be executed concurrently, thus breaking the limitation in the serialization isolation level that new transactions need to wait for other transactions to complete before they can be executed, greatly improving the concurrency of transaction processing.

[0107] In the case of a timeout of the coordinator or participant in the preparation or submission phase, this application introduces a solution mechanism in which the coordinator and the participant execute different termination protocol processes respectively, so as to promptly handle the timeout caused by the failure of the coordinator or the participant. This mechanism ensures that the failure of the coordinator and the participant can be properly handled in a timely manner, thus optimizing the 2PC protocol.

[0108] Finally, this application divides the full set of data items to be processed by the participants into a read set and a write set. There is no need to send the full set of data items to the coordinator. Instead, it only needs to send the read set about the current transaction to the coordinator once when responding to the sub-transaction submission request. After passing the conflict detection, a log record containing the read set and write set of the current transaction is sent to each candidate in the replica group, which reduces the amount of data transmitted over the network and improves transaction processing performance.

[0109] Fig. 9 FIG. 1 shows an internal structure diagram of a computer device in an embodiment. The computer device may be a client, a coordinator, a participant or a candidate in a distributed transaction processing system. Fig. 9 As shown, the computer device includes a processor, a memory and a network interface connected via a system bus. The memory includes a non-volatile storage medium and an internal memory. The non-volatile storage medium of the computer device stores an operating system and may also store a computer program. When the computer program is executed by the processor, the processor may implement a transaction processing method of a distributed transaction processing system. The internal memory may also store a computer program. When the computer program is executed by the processor, the processor may implement a transaction processing method of a distributed transaction processing system. Those skilled in the art will appreciate that Fig. 9 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0110] In one embodiment, the present application further proposes a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor executes the steps of the method described in any of the aforementioned embodiments.

[0111] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the program can be stored in a non-volatile computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0112] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0113] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A transaction processing method for a distributed transaction processing system, characterized in that: Applied to distributed transaction processing systems; The distributed transaction processing system is composed of multiple nodes. The distributed transaction processing system divides all stored data into multiple data shards. Each data shard has a preset number of replicas. The replicas are divided into a unique master replica and multiple slave replicas according to a preset consensus protocol. The master replica and the slave replica corresponding to one data shard are called a replica group. Different replicas of each data shard are stored in different nodes. For the same replica group, the node storing the master replica is called a participant, and the node storing the slave replica is called a candidate. The distributed transaction processing system further includes a client and a coordinator, wherein the client and the coordinator are deployed in a certain node or two different nodes of the distributed transaction processing system; The client is associated with the coordinator, the coordinator is associated with all the nodes, and the participants are associated with each other; The method comprises the following steps: After obtaining the transaction processing request issued by the user, the client forwards the transaction and the transaction processing request to the coordinator, wherein the transaction is composed of a single statement or multiple statements; The coordinator performs a transaction decomposition operation on the transaction to obtain a plurality of sub-transactions, each of which involves only a data item in one of the data shards; The coordinator constructs a prepare request for each of the subtransactions and sends the prepare request to the corresponding participant. The participant enters the prepare phase according to the prepare request and performs prepare operations on the subtransaction, wherein the prepare operations include data constraint detection, concurrency conflict detection, log recording operations, and state synchronization operations. The participant generates a feedback response according to the local transaction state obtained by the preparation operation, and returns the feedback response to the coordinator, wherein the local transaction state is one of ready and ready to terminate, and the feedback response is one of a commit response, a breach termination response, and a conflict termination response; If the coordinator receives the default termination response fed back by at least one of the participants, it sends a rollback request to all the participants to control all the participants to perform the rollback operation, and sends a transaction termination request to the client; If the coordinator does not receive the default termination response fed back by any of the participants but receives the conflict termination response fed back by at least one of the participants, it sends a rollback request to all the participants to control all the participants to perform the rollback operation, and sends a retry transaction request to the client; If all the participants feedback the commit response, the coordinator constructs a commit request for each participant and sends it, and the commit request is used to control the participant to enter the commit phase; The coordinator obtains the read set returned by the participant after executing the commit operation, integrates all the received read sets, synthesizes the request result and feeds back to the client; If the coordinator times out waiting for a response from a participant, the coordinator executes a first termination protocol process; If the participant's waiting for the request from the coordinator times out, the participant executes a second termination protocol process.

2. The transaction processing method of a distributed transaction processing system according to claim 1, characterized in that: The data constraint detection includes: After receiving the prepare request, the participant creates the read set and the write set according to the subtransaction, wherein the read set and the write set are composed of a four-tuple, and the four-tuple includes a data item, a transaction ID, a statement ID, and a read / write time; The participant performs the data constraint check when creating the read set and the write set to determine whether the data item satisfies the preset data constraint; If the data item does not satisfy the data constraint, the participant sends the breach termination response to the coordinator, and ends the preparation phase of the subtransaction, and no longer performs the concurrency conflict detection, the logging operation, and the state synchronization operation; If the data item satisfies the data constraint, the participant performs the concurrency conflict detection on the undertaken subtransaction according to the created read set and write set.

3. The transaction processing method of a distributed transaction processing system according to claim 2, characterized in that: The participant maintains a transaction reservation table, which is composed of five tuples, including data items, transaction IDs, statement IDs, read / write flags, and read / write times; The read / write time is the local time of the participant; the participant locally records the start time and commit time of the transaction, the start time is the time when the participant receives the first sub-transaction prepare request, and the commit time is the time when the participant receives the last sub-transaction commit request; For the participant, a transaction whose commit time has been set in the transaction reservation table is called a completed transaction; Transactions whose commit time is not set in the transaction reservation table are called unfinished transactions; The concurrent conflict detection includes: If there is an unfinished transaction in the subtransaction processed by the participant, the unfinished transaction has a corresponding write quintuple in the transaction reservation table, and the write time of the unfinished transaction is smaller than the maximum read / write time of the quintuple of the current transaction for the same data item in the read set or the write set of the participant, the current transaction is the subtransaction being processed by the participant, or If there is a completed transaction in the subtransaction processed by the participant, the commit time of the completed transaction is greater than the start time of the current transaction, and the completed transaction has a corresponding write quintuple in the transaction reservation table, and the write time of the completed transaction is less than the maximum read / write time of the quaternary group of the current transaction for the same data item in the read set or the write set of the participant, or If there is a four-tuple for the current transaction in the write set of the participant, and the write time of the four-tuple is smaller than the maximum read / write time of the five-tuple for the same data item in the transaction reservation table, It is considered that the concurrent conflict detection cannot be passed, and the participant sends the conflict termination response to the coordinator, and ends the preparation phase of the subtransaction, and no longer executes the log recording operation and the state synchronization operation; If the above situation does not occur, it is considered that the concurrent conflict detection can be passed, and the logging operation and the state synchronization operation can continue to be executed.

4. The transaction processing method of a distributed transaction processing system according to claim 1, characterized in that: The participant maintains a local master write-ahead log, and the candidate maintains a local slave write-ahead log, both the master write-ahead log and the local slave write-ahead log are composed of a plurality of log records, and the log records are used to record the read set, write set, transaction reservation table and processing status of the subtransaction; The execution log recording operation includes: The participant constructs a log record according to the read set, write set and transaction reservation table of the subtransaction, and adds the log record to the local master write-ahead log of the master replica corresponding to the subtransaction; The log record is sent to the local slave write-ahead log of the slave replica of the replica group corresponding to the sub-transaction until the replica group meets the consensus condition of the preset consensus protocol, and the log record operation is terminated.

5. The transaction processing method of a distributed transaction processing system according to claim 1, characterized in that: The state synchronization operation includes: Executed after the data items of the subtransaction pass the data constraint detection, the concurrency conflict detection and the log recording operation; Each of the participants P calls the function LogOnce (current transaction, participant P, ready) to record the local state of the subtransaction locally at the participant P. The parameters of the LogOnce function are transaction ID, participant ID, and local state of the subtransaction respectively. If the participant corresponding to the second parameter in the LogOnce function has recorded the local transaction state of the transaction corresponding to the first parameter in the LogOnce function, the LogOnce function returns the local transaction state recorded locally by the participant corresponding to the second parameter. Otherwise, the local state of the subtransaction corresponding to the third parameter in the LogOnce function is set to the local transaction state of the participant corresponding to the second parameter and returned. If the LogOnce function call returns ready to terminate, the participant returns the conflict termination response to the coordinator and waits for the coordinator to send the rollback request; Otherwise, the LogOnce function call returns ready, the participant returns a commit response to the coordinator, and waits for the coordinator to send the commit request or the rollback request.

6. The transaction processing method of a distributed transaction processing system according to claim 1, characterized in that: The coordinator performs a first termination protocol process, including: The coordinator calls the function LogOnce(current transaction, participant P, ready to terminate) to each participant P of the current transaction, and waits for each participant to return a result according to the LogOnce function; If there is a participant that is ready to terminate according to the return of the LogOnce function, the coordinator sends the rollback request; If each of the participants returns ready according to the LogOnce function, the coordinator sends the commit request; If there is a participant that times out according to the LogOnce function, the coordinator waits for the replica group to which the participant belongs to select a new participant to take over; the coordinator calls the function LogOnce (current transaction, the new participant, ready to terminate) to the new participant until the new participant returns ready to terminate or is ready according to the LogOnce function.

7. The transaction processing method of a distributed transaction processing system according to claim 1, characterized in that: The participants perform a second termination agreement process, including: Mark the participant who has timed out waiting for the coordinator as the current participant, and mark the participants of the current transaction in which the current participant participates, except the current participant, as the remaining participants; The current participant calls the function LogOnce(current transaction, participant P, ready to terminate) to each of the remaining participants P, and waits for each of the remaining participants to return a result according to the LogOnce function; If there is any of the remaining participants that is ready to terminate according to the return of the LogOnce function, the current participant performs the rollback operation; If each of the remaining participants returns ready according to the LogOnce function, the current participant performs the submit operation; If there is a timeout returned by any of the remaining participants according to the LogOnce function, wait for the replica group where the remaining participants are located to select a new participant to take over; the current participant calls the function LogOnce (current transaction, the new participant, ready to terminate) to the new participant until the new participant returns ready to terminate or is ready according to the LogOnce function.

8. The transaction processing method of a distributed transaction processing system according to claim 1, wherein: The rollback operation includes: The participant clears all four-tuples corresponding to the subtransaction in the read set and write set constructed according to the subtransaction, and clears all five-tuples corresponding to the subtransaction in the transaction reservation table; The participant sets the log record of the subtransaction in the maintained local master write-ahead log to a deleted state; The participant synchronizes the rollback request to the candidates to control all the candidates to set the log record of the sub-transaction maintained locally in the write-ahead log to a deleted state; The participant returns a response to the coordinator that does not contain any data item information.

9. The transaction processing method of a distributed transaction processing system according to claim 1, wherein: The submit operation includes: The participant sets the log record of the subtransaction in the maintained local master write-ahead log to a committed state, and updates the master copy according to the write set of the subtransaction; Synchronize the commit request to the candidate, control the candidate to set the log record of the subtransaction in the maintained local slave write-ahead log to a committed state, and update the slave replica according to the write set extracted from the log record of the subtransaction; The participant returns a response to the coordinator containing the read set of the subtransaction.

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

Images