Distributed Transaction Processing System Transaction Processing Method and Computer Readable Storage Medium

Abstract

The embodiments of the present application disclose a method for transaction processing in a distributed transaction processing system and a computer-readable storage medium. The method of the present application introduces a lock-free conflict detection mechanism. Without using any read-write locks, it detects write-write conflicts, write-read conflicts, or read-write conflicts at the data item granularity between concurrent transactions, avoiding the three major data inconsistency problems of dirty reads, non-repeatable reads, and phantom reads. At the same time, it allows transactions with read-read conflicts to execute concurrently, improving the concurrency of transaction processing. When a timeout problem occurs, different termination protocol processes are executed by the coordinator and the participants respectively, ensuring that the coordinator and the participants can be properly handled in a timely manner when a failure occurs, and optimizing the 2PC protocol. In addition, after the participants enter the commit phase of the transaction commit step, the multi-copy mechanism of the system ensures that even if a participant fails, it does not affect the correct commit or rollback operations of the sub-transactions undertaken by the participant, thus ensuring the fault tolerance of the system.

Description

Technical Field

[0001] This application belongs to the technical field of databases, and particularly relates to a transaction processing method for a distributed transaction processing system and a computer-readable storage medium. Background Art

[0002] A distributed transaction processing system is a software system that executes transactions in a distributed environment and has a wide range of applications in many fields. Typical distributed transaction processing systems include online shopping systems (ensuring that the goods purchased by users can be successfully ordered and paid), banking systems (ensuring that users' transfer operations can be successfully executed), and flight reservation systems (ensuring that users' flight reservations can be successfully completed), etc. The distributed transaction processing system has 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 all committed or all rolled back among all participants (i.e., nodes that undertake sub-transactions).

[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 ANSI SQL 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 been committed by other transactions. This isolation level may lead to the dirty read problem, that is, it can read uncommitted modifications. If these modifications are later rolled back, it will result in data inconsistency. The Read Committed level is the default isolation level for many database management systems (including Oracle and SQL Server). At this isolation level, a transaction can only read modifications that have been committed. This solves the dirty read problem, but the non-repeatable read problem may occur, that is, the same data can be read differently in the same transaction. The Repeatable Read level is the default isolation level for MySQL. At this isolation level, the reading result of the same data in a transaction is the same throughout the transaction process, and the non-repeatable read problem will not occur, but the phantom read problem may occur, that is, the result sets of two queries in the same transaction can be different. Serializable is the strictest isolation level, which avoids the phantom read problem by forcing transactions to execute serially. At this isolation level, a new transaction must wait for other transactions to complete before it can execute. The performance of transaction processing depends on the transaction isolation level: the higher the transaction isolation level pursued by a 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, this protocol has a blocking problem, which affects the performance of distributed transaction processing. Existing technologies have proposed various optimization schemes, mainly divided into two categories, for solving the 2PC problem of decomposable transactions: the first category is the optimization for shared-nothing architecture; the second category is the optimization for custom storage. However, the former will increase network communication and complexity; while the latter solves the inconsistency problem through an application protocol, but requires custom storage design and replication protocol, and still cannot solve the blocking problem of 2PC. It can be seen that although existing technologies have optimized 2PC to a certain extent, there are still 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 those skilled in the art.

[0005] The foregoing description is 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 transaction processing method and a computer-readable storage medium for a distributed transaction processing system to address the above problems. This method 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 its technical problems by adopting the following technical solutions:

[0008] 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. 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 primary replica and multiple secondary replicas according to a preset consensus protocol. The primary replica and secondary replicas corresponding to a 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 primary replica is called a participant, and the node storing the secondary replicas is called a candidate. The distributed transaction processing system also includes a client and a coordinator. The client and the coordinator are deployed in a certain node or two different nodes of the distributed transaction processing system. The client and the coordinator are associated, the coordinator is associated with all nodes, and the participants are associated with each other.

[0009] The method includes the following steps:

[0010] After the client obtains the transaction processing request sent by the user, it 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, and each sub-transaction only involves 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 a prepare operation on the sub-transaction. The prepare operation includes data constraint detection, concurrent conflict detection, logging operation, and status synchronization operation. 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 prepare to terminate, and the feedback response is one of commit response, default termination response, and conflict termination response. If the coordinator receives at least one default termination response feedback from a participant, it sends a rollback request to all participants to control all participants to perform rollback operations and issues a transaction termination requirement to the client. If the coordinator does not receive any default termination response feedback from a participant but receives at least one conflict termination response feedback from a participant, it sends a rollback request to all participants to control all participants to perform rollback operations and issues a retry transaction requirement to the client. If all participants feedback commit responses, the coordinator constructs and sends a commit request for each participant. 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 performing the commit operation, integrates all received read sets, synthesizes the request result, and feeds it back to the client. If the coordinator times out waiting for a response from a participant, the coordinator executes the first termination protocol process. If the participant times out waiting for a request from the coordinator, the participant executes the second termination protocol process.

[0011] In an optional embodiment of the present application, the data constraint detection includes: after receiving the prepare request, the participant creates a read set and a write set according to the sub-transaction. The read set and the write set are composed of quadruples, and the quadruple 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 constraints, the participant sends a default termination response to the coordinator and ends the prepare phase process of the sub-transaction, and no longer performs concurrent conflict detection, logging operation, and status synchronization operation. If the data item meets the data constraints, the participant performs concurrent conflict detection on the sub-transaction it undertakes according to the created read set and write set.

[0012] In an alternative embodiment of the present application, a participant maintains a transaction reservation table, which is composed of quintuples. The quintuples 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. The participant locally records the start time and commit time of the transaction where it is located. 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 a participant, a transaction whose commit time has been set in the transaction reservation table is called a completed transaction; a transaction whose commit time has not been set in the transaction reservation table is called an uncompleted transaction. Concurrent conflict detection includes: if there is an uncompleted transaction among the sub-transactions processed by the participant, the uncompleted transaction has a corresponding write quintuple in the transaction reservation table, and the write time of the uncompleted transaction is smaller than the maximum read / write time of the quadruple of the current transaction for the same data item in the participant's read set or write set, where the current transaction is the sub-transaction being processed by the participant, or if there is a completed transaction among the sub-transactions 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 quadruple of the current transaction for the same data item in the participant's read set or write set, or if there is a quadruple for the current transaction in the participant's write set, and the write time of the quadruple is smaller than the maximum read / write time of the quintuple for the same data item in the transaction reservation table, it is considered that the concurrent conflict detection cannot pass. The participant sends a conflict termination response to the coordinator and ends the preparation phase process of the sub-transaction, and no longer performs the log recording operation and the status synchronization operation. If it is not the above situation, it is considered that the concurrent conflict detection can pass, and the log recording operation and the status synchronization operation are continued.

[0013] In an alternative embodiment of the present application, the participant maintains a local primary pre-write log, and the candidate maintains a local secondary pre-write log. Both the local primary pre-write log and the local secondary pre-write log are composed of multiple log records. The log records are used to record the read set, write set, transaction reservation table, and processing status of the sub-transaction. The execution of the 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 primary pre-write log of the primary copy corresponding to the sub-transaction; the log record is sent to the local secondary pre-write log of the secondary copy 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 recording operation ends.

[0014] In an alternative embodiment of the present application, the status synchronization operation includes: after the data items of the sub-transaction are subjected to data constraint detection, concurrent conflict detection, and logging operations; each participant P calls the function LogOnce (current transaction, participant P, ready to terminate), records the local status of the sub-transaction locally at participant P, and the parameters of the LogOnce function are the transaction ID, participant ID, and local status of the sub-transaction respectively; if the participant corresponding to the second parameter in the LogOnce function has already recorded the local transaction status of the transaction corresponding to the first parameter in the LogOnce function, the LogOnce function returns the local transaction status recorded locally by the participant corresponding to the second parameter, otherwise the local status of the sub-transaction corresponding to the third parameter in the LogOnce function is set as the local transaction status of the participant corresponding to the second parameter and returned; 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 issue a rollback request; otherwise, if the LogOnce function call returns ready, the participant returns a commit response to the coordinator and waits for the coordinator to issue a commit request or a rollback request.

[0015] In an alternative embodiment of the present application, the coordinator executes the first termination protocol process, including: the coordinator calls the function LogOnce (current transaction, participant P, ready to terminate) for each participant P of the current transaction and waits for the return result of each participant according to the LogOnce function; if there is a participant who returns ready to terminate according to the LogOnce function, the coordinator issues a rollback request; if each participant returns ready according to the LogOnce function, the coordinator issues a commit request; if there is a participant who returns timeout according to the LogOnce function, wait for the replica group where the participant is located to select a new replacement participant; the coordinator calls the function LogOnce (current transaction, new participant, ready to terminate) for the new participant until the new participant returns ready to terminate or ready according to the LogOnce function.

[0016] In an optional embodiment of the present application, the process of the participant executing the second termination protocol includes: marking the participant waiting for the coordinator timeout as the current participant, and marking the participants other than the current participant among the participants of the current transaction participated by the current participant as the remaining participants; the current participant calls the function LogOnce(current transaction, participant P, prepare to terminate) for each remaining participant P and waits for the result returned by each remaining participant according to the LogOnce function; if there is a remaining participant who returns prepare to terminate according to the LogOnce function, the current participant performs a rollback operation; if each remaining participant returns prepare ready according to the LogOnce function, the current participant performs a commit operation; if there is a remaining participant who returns timeout according to the LogOnce function, wait for the new participant selected by the replica group where the remaining participant is located; the current participant calls the function LogOnce(current transaction, new participant, prepare to terminate) for the new participant until the new participant returns prepare to terminate or prepare ready according to the LogOnce function.

[0017] In an optional embodiment of the present application, the rollback operation includes: the participant clears all quadruples corresponding to the sub-transaction in the read set and write set constructed according to the sub-transaction, and clears all quintuples corresponding to the sub-transaction in the transaction reservation table; the participant sets the log record about the sub-transaction in the locally maintained main pre-write log to the deleted state; the participant synchronizes the rollback request to the candidates to control all candidates to set the log record about the sub-transaction in the locally maintained slave pre-write log to the deleted state; the participant returns a response without any data item information to the coordinator.

[0018] In an optional embodiment of the present application, the commit operation includes: the participant sets the log record about the sub-transaction in the locally maintained main pre-write log to the committed state and updates the main replica according to the write set of the sub-transaction; synchronize the commit request to the candidates, control the candidates to set the log record about the sub-transaction in the locally maintained slave pre-write log to the committed state, and update the slave replica according to the write set extracted from the log record of the sub-transaction; the participant returns a response containing the read set of the sub-transaction to the coordinator.

[0019] The present application also provides a computer-readable storage medium storing a computer program, which implements the method as described above when executed by a processor.

[0020] Adopting the embodiment of the present application has the following beneficial effects:

[0021] The multi-replica mechanism adopted by the present application ensures that even if a participant fails, it does not affect the correct commit or rollback operation of the sub-transaction undertaken by the participant, thus ensuring the fault tolerance of the system.

[0022] In the preparation stage, a lock-free conflict detection mechanism is introduced. Without using any read-write locks, it detects write-write conflicts, write-read conflicts, or read-write conflicts at the data item granularity (instead of the coarser transaction granularity) among concurrent transactions. If the above conflicts are detected, the current transaction is prompted to restart execution, thus 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 execute concurrently, thus breaking the limitation in the serializable isolation level where a new transaction needs to wait for other transactions to complete before it can execute, greatly improving the concurrency of transaction processing.

[0023] For the situation where the coordinator or participants time out during the preparation or commit stage, this application introduces a solution mechanism where the coordinator and participants execute different termination protocol processes respectively to handle the timeout caused by the failure of the coordinator or participants in a timely manner. This mechanism ensures that the failures of the coordinator and participants can be properly handled in a timely manner, optimizing the 2PC protocol.

[0024] Finally, the entire set of data items to be processed by the participants is divided into a read set and a write set. Instead of sending the entire set of data items to the coordinator, only the read set of the current transaction needs to be sent to the coordinator once when responding to the sub-transaction commit request, and a log record containing the read set and write set of the current transaction is sent to each candidate in the replica group where it is located once after passing the conflict detection, reducing the network transmission volume of data and improving the transaction processing performance.

[0025] The above description is only an overview of the technical solution of this application. In order to be able to more clearly understand the technical means of this application, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features, and advantages of this application more obvious and understandable, the following specifically gives preferred embodiments and, in conjunction with the drawings, details are described in detail. It should be understood that the above general description and the following detailed description are only exemplary and explanatory and cannot limit this application. Brief Description of the Drawings

[0026] In order to more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0027] Among them:

[0028] Figure 1 It is a schematic flow chart of a transaction processing method for a distributed transaction processing system provided by an embodiment;

[0029] Figure 2Schematic diagram of the hardware structure of a distributed transaction processing system provided for an embodiment;

[0030] Figure 3 Schematic diagram of data association of a distributed transaction processing system provided for an embodiment;

[0031] Figure 4 Sequence diagram for a transaction processing failure requiring the client to terminate the transaction provided for an embodiment;

[0032] Figure 5 Sequence diagram for a transaction processing failure requiring the client to retry the transaction provided for an embodiment;

[0033] Figure 6 Sequence diagram for a transaction processing success returning the request result provided for an embodiment;

[0034] Figure 7 Sequence diagram for a coordinator waiting timeout but the transaction can still be successfully processed provided for an embodiment;

[0035] Figure 8 Sequence diagram for a participant waiting timeout but the transaction can still be successfully processed provided for an embodiment;

[0036] Figure 9 Schematic block diagram of the structure of a computer device provided for an embodiment. Detailed implementation manners

[0037] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0038] Distributed transaction processing systems have become an important part of modern distributed systems, ensuring data consistency and reliability in distributed systems. They typically include the following elements: (1) Data partitioning - distributing data across different nodes to improve system scalability and availability; (2) Concurrency control - ensuring that multiple transactions do not interfere with each other when executed simultaneously to ensure data consistency; (3) Transaction management - responsible for coordinating the execution of transactions; (4) Log management - recording the operations of transactions for recovery in case of system failures.

[0039] Distributed transaction processing systems face many technical challenges, such as transaction isolation (which requires ensuring that multiple transactions do not interfere with each other when executed simultaneously), transaction atomicity (which requires ensuring that a transaction either succeeds completely or fails completely), and high performance (which requires improving the efficiency and throughput of transaction processing), etc. To address these challenges, distributed transaction processing systems typically handle the transaction requests submitted by users in two successive steps: (1) Transaction decomposition - According to 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 where the data belongs; (2) Transaction commit - Each sub-transaction is executed separately in its respective node, generating read-write sets; if all the nodes where the sub-transactions belong unanimously agree to commit, the system integrates the read-write sets of all nodes to reply to the user request, and at the same time each node updates the local storage using the read-write sets, otherwise the system ignores the read-write sets in the nodes where the sub-transactions belong, and retries or terminates the transaction. The commit step in these two steps is the most critical because this step must ensure the isolation and atomicity of the transaction.

[0040] Existing distributed transaction processing systems widely adopt the Two-Phase Commit (2PC) protocol to implement the commit step, ensuring that distributed transactions are either all committed or all rolled back among all participants (i.e., the nodes that undertake sub-transactions). The 2PC protocol consists of two phases: (1) Preparation phase - The coordinator sends a prepare request to all participants, and the participants vote according to their local transaction status and write to the log; (2) Commit phase - The coordinator decides to commit or roll back based on the voting results and notifies all participants of the decision result. To ensure transaction isolation, the 2PC protocol can be combined with other technologies such as read-write locks, Multi-Version Concurrency Control (MVCC), etc. to achieve different transaction isolation levels. The ANSI SQL standard defines several transaction isolation levels, including Read Uncommitted, Read Committed, Repeatable Read, and Serializable.

[0041] At the Read Uncommitted level, a transaction can read uncommitted modifications made by other transactions. This isolation level may lead to the dirty read problem, that is, it is possible to read uncommitted modifications, and if these modifications are later rolled back, it will result in data inconsistency.

[0042] The read committed level is the default isolation level in many database management systems, including Oracle and SQL Server. At this isolation level, a transaction can only read committed modifications. This solves the dirty read problem, but it may suffer from the non-repeatable read problem, that is, the same data read twice in the same transaction can be different.

[0043] The repeatable read level is the default isolation level in MySQL. At this isolation level, the result of reading the same data in a transaction remains the same throughout the transaction, and the non-repeatable read problem will not occur. However, the phantom read problem may occur, that is, the result sets of two queries in the same transaction can be different.

[0044] Serializable is the strictest isolation level. It avoids the phantom read problem by forcing transactions to execute serially. At this isolation level, a new transaction must wait for other transactions to complete before it can execute. The performance of transaction processing depends on the transaction isolation level: the higher the transaction isolation level pursued by a distributed transaction processing system, the greater the time cost required for transaction processing.

[0045] Although the 2PC protocol can ensure transaction atomicity and can achieve different transaction isolation levels by combining other technical means, this protocol has a blocking problem, which affects the performance of distributed transaction processing. The blocking problem means that the coordinator needs to wait twice for the responses of all participants before proceeding to the next operation. 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 current unfinished transaction is very likely to conflict with subsequent transactions, causing subsequent transactions to retry continuously and get blocked. For the 2PC problem of decomposable transactions, existing technologies have proposed various optimization schemes, mainly divided into two categories.

[0046] The first category is the optimization for shared-nothing architectures, including: reducing the latency of 2PC by assuming workload and system characteristics, such as Early Prepare and Implicit Yes Vote, but these assumptions do not always apply to decoupled storage architectures; alleviating the blocking problem by adding an extra phase, such as EasyCommit and Babaoglu-Toueg protocols, but this will increase network communication and complexity.

[0047] The second category is the optimization for custom storage, including: co - designing 2PC with Paxos Commit and the underlying Paxos consensus protocol, reducing latency by pre - preparing and skipping the Paxos leader, and avoiding blocking through Paxos consensus, but it requires a custom storage design and replication protocol; TAPIR and MDCC use a customized replication protocol to weaken replica consistency and solve the inconsistency problem through an application protocol, but they require a custom storage design and replication protocol; the distributed databases CockroachDB and YugabyteDB use the Raft replication protocol to determine whether a commit operation is completed, but still cannot solve the blocking problem of 2PC.

[0048] It can be seen that although the prior art has optimized 2PC to a certain extent, there are still problems such as poor flexibility and limited performance improvement. On the other hand, although 2PC combined with the read - write lock technology can achieve the highest serializable transaction isolation level and solve the three major data inconsistency problems of dirty reads, non - repeatable reads, and phantom reads, the serializable transaction isolation level requires ensuring that new transactions wait for other transactions to complete before execution, severely limiting the concurrency of transaction processing and resulting in low transaction processing efficiency and throughput. Therefore, modern distributed transaction processing systems require new technical solutions that can both optimize the 2PC protocol and, on the premise of improving the concurrency of transaction processing, solve the three major data inconsistency problems of dirty reads, non - repeatable reads, and phantom reads, and achieve a transaction isolation level close to serialization. In this transaction isolation level, new transactions can be executed before other transactions are completed. For this, this application proposes a transaction processing method for a distributed transaction processing system. To clearly describe the transaction processing method for the distributed transaction processing system provided in this embodiment, please refer to Figures 1 to 8 .

[0049] 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. Further, the distributed transaction processing system also includes a client and a coordinator. The client and the coordinator are both deployed within the nodes. They can be deployed within the same node or in different nodes respectively. Different deployment methods will not affect the method provided in this application, so the specific deployment method is not specifically limited. The client is the device directly controlled by the user, used to obtain user requirements and feedback to the user according to the processing results; the coordinator is the intermediate device between all nodes and the client, used to overall manage all nodes in the system to respond to and complete the user's requirements. Their specific execution processes will be specifically elaborated later and will not be elaborated here for the time being.

[0050] Before executing the method provided by this application, the distributed transaction processing system divides all the stored data into multiple data shards with a preset upper size limit for management. The specific quantity can be arbitrarily set according to the data size or requirements. And the size of each data shard can be preset and does not need to be the same as each other. The system adopts a multi-copy mechanism to distribute all data shards for storage in each node. For ease of understanding, in Figure 2 In the illustrated embodiment, it is only divided into two data shards, namely data shard 1 and data shard 2.

[0051] Furthermore, a data shard constructs a certain number of copies of its stored data content. Each copy has the same data content, and one data shard corresponds to one copy group. At the same time, the system provided by this application can select one copy from within a copy group as the primary copy according to a preset consensus protocol, and the remaining copies are marked as secondary copies. Among them, any consensus protocol (such as Paxos and Raft) can be used for the election of the primary copy and consensus determination. Limiting the specific consensus protocol does not exceed the scope protected by this invention. During the execution process, the actual data processing process directly targets the primary copy for processing, while the secondary copies change according to the changes of the primary copy. The specific synchronization process will be described in detail later. In a preferred embodiment, a single node does not store all data, and each data shard has copies only on a preset number (not all) of nodes.

[0052] As can be seen from the previously described solution, the copies within the same copy group are respectively stored in different nodes. For the same copy group, the node storing the primary copy is called the participant, and the node storing the secondary copy is called the candidate. Based on this, for ease of understanding the distributed transaction processing system provided by this application, reference can be made to Figure 2 as shown Figure 2 Taking three nodes and two copy groups as an example, it shows the structural relationship of multiple nodes, clients, coordinators, and multiple copies within the system.

[0053] 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 of each functional module, reference can be made to Figure 3 as shown. Figure 3 Continuing Figure 2The provided examples demonstrate the association relationships among the functional modules. The coordinator, as the intermediate module between all replicas and clients, is connected to all replicas and clients respectively. Further, the participants are also associated with each other to facilitate information exchange under specific circumstances. That is to say, the participants in the same transaction are independent of each other, but each knows the access addresses of other participants. Information can be sent between the coordinator and the participants to communicate the sub-transaction processing status. In addition, within the same replica group, the participants are also associated with all candidates to synchronize the data changes occurring within the participants to the candidates, ensuring data reliability. It should be noted that the data sharding of the system and its replica groups are determined before the first transaction processing.

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

[0055] Step S110: After the client obtains the transaction processing request issued by the user, it 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, and each sub-transaction only involves data items in one data shard.

[0056] In an implementation manner, after the user issues a transaction request on the client, the client can search for the transaction corresponding to the transaction request. It should be noted that the transactions processed by the system consist of a single or multiple statements. Then, 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 enable the transaction to be processed by multiple nodes, the transaction can be decomposed, specifically, a decomposition operation is performed. What is obtained after decomposing the transaction is called a sub-transaction, and a transaction decomposition can obtain several sub-transactions. Further, in order to ensure the integrity of each node's processing, each sub-transaction obtained by decomposition only involves data items in one data shard. That is to say, there is a certain correlation between the sub-transaction and the data shard. In the subsequent execution process, the node storing the corresponding data shard can process the corresponding sub-transaction. If the same node has the primary replicas of multiple data shards {T1, T2, …, T n}, then this node acts as the participant in the corresponding n sub-transactions. n

[0057] Step S120: 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 a prepare operation on the sub-transaction. The prepare operation includes data constraint detection, concurrent conflict detection, log record operation, and status synchronization operation.

[0058] ​Step S130: The participant generates a feedback response based on the local transaction status obtained from 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 a commit response, a default termination response, and a conflict termination response.

[0059] In one embodiment, the technical solution of the present application optimizes the 2PC under the 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 in turn corresponds to a replica group. The replica group is divided into a unique primary replica and the remaining secondary replicas according to a preset consensus protocol. The node storing the primary replica is called the participant. Thus, 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.

[0060] The 2PC protocol consists of two phases: (1) Preparation phase - The coordinator sends a preparation request to all participants. The participants vote according to the local transaction status and write to the log; (2) Commit phase - The coordinator decides to commit or roll back according to the voting results and notifies all participants of the decision result. According to the preparation request, the participants will enter the preparation phase and immediately independently execute the sub-transactions they are responsible for. Specifically, it is to execute the preparation operation, which includes data constraint detection, concurrent conflict detection, log recording operation, and status synchronization operation. In a preferred embodiment, the preparation operation is executed sequentially in the order of data constraint detection, concurrent conflict detection, log recording operation, and status synchronization operation included in the preparation operation. The specific execution process will be described in detail later.

[0061] In one embodiment, the data constraint detection includes: after receiving the preparation request, the participant creates a read set and a write set according to the sub-transaction. The read set and the write set are composed of quadruples, and the quadruple 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 constraints, the participant sends a default termination response to the coordinator and ends the preparation phase process of the sub-transaction, and no longer performs concurrent conflict detection, log recording operation, and status synchronization operation; if the data item meets the data constraints, the participant performs concurrent conflict detection on the sub-transaction it is responsible for according to the created read set and write set.

[0062] In one embodiment, after a participant receives a preparation request and enters the preparation phase, the participant can first create a read set and a write set according to sub-transactions. The read set and the write set are composed of quadruples, and each quadruple includes a data item, a transaction ID, a statement ID, and a read / write time. Herein, the present application defines the basic data unit for transaction processing as a data item, and the data item is defined according to the content stored in the system. For example, when the stored 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 form of basic data unit, such as a row or a column in a traditional data form, etc. Defining specific basic data units is not beyond the scope protected by the present application.

[0063] During the process of creating the read set and the write set, the participant can detect preset data constraints, that is, data constraint detection. The preset data constraints include data integrity constraints and user-defined constraints, etc. These constraints are generally used to determine the legality and consistency of data content, such as "the height value is above 0.5 meters" and "the functional field values of the same entity are unique", etc. Such preset data constraints can be common data integrity constraints in the database field or user-defined constraints, etc. The determination of whether these data constraints are violated (i.e., default determination) can rely on a general automatic reasoner or a customized executable program. Defining specific data constraints or default determination methods is not beyond the scope protected by the present application.

[0064] If the data item does not meet the data constraints, the participant sends a default termination response to the coordinator and ends the preparation phase process of the sub-transaction, and no longer performs concurrent conflict detection, logging operations, and status synchronization operations. Then, step S140 will be executed, and the specific execution process will be described later.

[0065] If the data item meets the data constraints, it is considered that the data constraint detection has passed, and the participant will perform subsequent concurrent conflict detection on the sub-transaction undertaken according to the created read set and write set. The concurrent conflict detection will be described in detail later.

[0066] In one embodiment, a participant maintains a transaction reservation table, which consists of quintuples. The quintuples 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. The participant locally records the start time and commit time of the transaction in which it is involved. 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 a participant, a transaction whose commit time has been set in the transaction reservation table is called a completed transaction; a transaction whose commit time has not been set in the transaction reservation table is called an uncompleted transaction. Concurrent conflict detection includes: if there is an uncompleted transaction among the subtransactions processed by the participant, the uncompleted transaction has a corresponding write quintuple in the transaction reservation table, and the write time of the uncompleted transaction is smaller than the maximum read / write time of the quadruple for the same data item in the read set or write set of the participant for the current transaction, where the current transaction is the subtransaction being processed by the participant; or if there is a completed transaction among the subtransactions 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 quadruple for the same data item in the read set or write set of the participant for the current transaction; or if there is a quadruple for the current transaction in the write set of the participant, and the write time of the quadruple is smaller than the maximum read / write time of the quintuple for the same data item in the transaction reservation table, it is considered that the concurrent conflict detection cannot pass. The participant sends a conflict termination response to the coordinator, ends the prepare phase process of the subtransaction, and no longer performs log record operations and status synchronization operations. If it is not the above situation, it is considered that the concurrent conflict detection can pass, and the log record operations and status synchronization operations are continued.

[0067] In one embodiment, each participant performs conflict detection based on a transaction reservation table maintained by itself. The transaction reservation table consists of quintuples, 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 involved, and both of these times are the local time of the participant. 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 should be noted that a single participant may include the primary replicas involved in multiple subtransactions, so it can receive prepare requests and commit requests for multiple subtransactions.

[0068] For participants, a transaction whose submission time has been set in the transaction reservation table is defined as a completed transaction; a transaction whose submission time has not been set in the transaction reservation table is called an uncompleted transaction. In addition, there are also abandoned transactions in the transaction reservation table, and an abandoned transaction is defined as a transaction whose maximum read / write time is less than the minimum start time of all uncompleted transactions. All quintuples included in the abandoned transaction will be periodically cleared.

[0069] The concurrent conflict detection technology solution provided by this application introduces a lock-free conflict detection mechanism. Instead of introducing read-write locks to ensure the serialization of transaction processing, 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 conflicts with other transactions in terms of data items and needs to restart the 2PC process of the current transaction when one of the following situations (a), (b), or (c) is met. The sub-transactions borne by specific participants are regarded as situations where concurrent conflict detection fails, including the following three types:

[0070] (a) There is an uncompleted transaction in the sub-transactions processed by the participant. The uncompleted transaction has a corresponding write quintuple in the transaction reservation table, and the write time of the uncompleted transaction is smaller than the maximum read / write time of the quadruple of the current transaction in the participant's read set or write set for the same data item.

[0071] (b) There is a completed transaction in the sub-transactions processed by the participant. The submission 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 quadruple of the current transaction in the participant's read set or write set for the same data item.

[0072] (c) There is a quadruple for the current transaction in the participant's write set, and the write time of the quadruple is smaller than the maximum read / write time of the quintuple for the same data item in the transaction reservation table.

[0073] Among them, the current transaction is the sub-transaction being processed by the participant. Situations (a) and (b) mean that between the start time and the submission time of the participant's current transaction, there may be other transactions rewriting the same data items of the current transaction in the participant's read set or write set, that is, read-write conflicts or write-write conflicts may occur.

[0074] Condition (c) means that between the start time and the submission time of the participant's current transaction, the current transaction may rewrite the same data items of other transactions, that is, write-read conflicts or write-write conflicts may occur.

[0075] The present application provides a method. By adopting situations (a), (b), and (c), it can exclude write-write conflicts, write-read conflicts, and read-write conflicts that may occur in multiple concurrent transactions, and can avoid the three major data inconsistency problems of dirty reads, non-repeatable reads, and phantom reads. At the same time, the above situations do not exclude read-read conflicts in multiple concurrent transactions. Therefore, it can break the limitation that a new transaction in the serializable isolation level needs to wait for other transactions to complete before it can be executed, greatly improving the concurrency of transaction processing.

[0076] Specifically, if the above situation exists, it is considered that a sub-transaction 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 process of the sub-transaction, and no longer performs log record operations and status synchronization operations. Subsequently, the steps of step S150 will be executed, and the specific execution process will be described later.

[0077] If it is not any of the above situations, it is considered that the concurrent conflict detection can pass, and the subsequent log record operations and status synchronization operations are continued.

[0078] In one embodiment, the participant maintains a local main write-ahead log, and the candidate maintains a local secondary write-ahead log. Both the local main write-ahead log and the local secondary write-ahead log are composed of multiple log records. The log records are used to record the read set, write set, transaction reservation table, and processing status of the sub-transaction. The execution of the 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 main write-ahead log of the main copy corresponding to the sub-transaction; sends the log record to the local secondary write-ahead log of the secondary copy in the copy group corresponding to the sub-transaction until the copy group meets the consensus condition of the preset consensus protocol, and ends the log record operation.

[0079] In one embodiment, when the data constraint detection and the concurrent conflict detection are passed, it can be regarded that the participant has completed the preparation of the sub-transaction, that is, the local transaction state of the sub-transaction can be marked as ready. Correspondingly, if the data constraint detection or the concurrent conflict detection fails, the local transaction state is marked as ready to terminate. For those that have completed the preparation, the sub-transaction state can be generated into a log record for recording. The participants and candidates in the copy group both maintain persistent (such as stored in a disk file) write-ahead logs. Among them, the participant maintains a local main write-ahead log, and the candidate maintains a local secondary write-ahead log.

[0080] Both the landlord's pre-written log and the local slave pre-written log consist of multiple log records, which are used to record the read set, write set, transaction reservation table, and processing status of sub-transactions. Each log record has a status bit to record its status (unprocessed / committed / deleted), which is set to the unprocessed status during initialization. When the leader election mechanism of the preset consensus protocol elects a candidate as the new participant, the candidate reconstructs the read set, write set, and transaction reservation table required for the participant based on the unprocessed or committed log records. During failure recovery, the participant or candidate first locates the first committed log record that contains the write set but has not updated the local copy. Starting from this log record, it processes the subsequent committed log records that contain the write set one by one, and updates the local copy using the write sets in the log records.

[0081] The specific steps for performing log record operations can be that the participant constructs log records based on the read set, write set, and transaction reservation table of the sub-transaction, and adds the constructed log records to the local master pre-written log. After that, the participant can send the log records to all candidates corresponding to the sub-transaction. The candidates add the log records to the local slave pre-written logs they maintain. When the replica group where the participant is located 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 log records to the pre-written log), the participant ends the log record operation and enters the status synchronization operation.

[0082] It should be noted that in the multi-replica mechanism, the node where the master replica is located needs to transfer log records to the nodes where the slave replicas are located. This application does not specifically limit the log records of the current transaction, including the number and content of the log records, but only requires that the transferred log records cover the subsets of the read set, write set, and transaction reservation table of the participant corresponding to the master replica for the current transaction, so as to ensure that the candidate can reconstruct the read set, write set, and transaction reservation table after replacing the participant as the new participant. Limiting the specific log record information is not beyond the scope protected by this application.

[0083] In one embodiment, the status synchronization operation includes: after the data items in the sub-transaction pass the data constraint detection, concurrent conflict detection, and logging operation; each participant P calls the function LogOnce(current transaction, participant P, ready), and records the local status of the sub-transaction locally on participant P. The parameters of the LogOnce function are the transaction ID, participant ID, and local status of the sub-transaction respectively; if the participant corresponding to the second parameter in the LogOnce function has already recorded the local transaction status of the transaction corresponding to the first parameter in the LogOnce function, the LogOnce function returns the local transaction status recorded locally by the participant corresponding to the second parameter, otherwise the local status of the sub-transaction corresponding to the third parameter in the LogOnce function is set as the local transaction status of the participant corresponding to the second parameter and returned; 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 issue a rollback request; otherwise, if the LogOnce function call returns ready, the participant returns a commit response to the coordinator and waits for the coordinator to issue a commit request or a rollback request.

[0084] In one embodiment, after the logging operation is completed, the participant will perform the status synchronization operation. Specifically, each participant P calls the function LogOnce(current transaction, participant P, ready), and records the local status of the sub-transaction locally on participant P. The LogOnce function called includes three parameters: transaction ID, participant ID, and local status of the sub-transaction. The specific function of the LogOnce function is to record the local status of the sub-transaction locally on participant P. Among them, if the participant corresponding to the second parameter in the LogOnce function has already recorded the local transaction status of the transaction corresponding to the first parameter in the LogOnce function, the LogOnce function returns the local transaction status recorded locally by the participant corresponding to the second parameter, otherwise the local status of the sub-transaction corresponding to the third parameter in the LogOnce function is set as the local transaction status of the participant corresponding to the second parameter and returned.

[0085] Therefore, if the LogOnce function call returns ready to terminate, participant P has been recognized by the coordinator as ready to timeout. At this time, participant P returns a termination response to the coordinator, prompting the coordinator to make a decision to roll back the transaction in the preparation stage. Otherwise, if the LogOnce function call returns ready, participant P returns a commit response to the coordinator and waits for the coordinator's sub-transaction commit or rollback request.

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

[0087] In one embodiment, in steps S140 to S180, the control participant enters the commit phase in the 2PC process. Regardless of the result in the commit phase, for the participant, only two operations will be performed, either commit or rollback, corresponding to the commit operation and the rollback operation respectively. The participant may respond according to the instructions issued by the coordinator, or may detect and execute by itself under specific circumstances. Therefore, the rollback operation and the commit operation are described first.

[0088] In one embodiment, the rollback operation includes: the participant clears all quadruples corresponding to the sub-transaction in the read set and write set constructed according to the sub-transaction, and clears all quintuples corresponding to the sub-transaction in the transaction reservation table; the participant sets the log record about the sub-transaction in the locally maintained main pre-write log to the deleted state; the participant synchronizes the rollback request to the candidates to control all candidates to set the log record about the sub-transaction in the locally maintained slave pre-write log to the deleted state; the participant returns a response that does not contain any data item information to the coordinator.

[0089] In one embodiment, the rollback operation is as follows: the participant clears the multi-tuple records about the current transaction in the local read set, write set and transaction reservation table, sets the log record about the current transaction in the locally maintained main pre-write log to the deleted state, and at the same time synchronizes the rollback request to the candidates in the replica group where it is located, prompting all candidates to also set the log record about the current transaction in the locally maintained slave pre-write log to the deleted state. Finally, the participant returns a response that does not contain any data item information to the coordinator to indicate that the rollback operation is completed.

[0090] In one embodiment, the commit operation includes: the participant sets the log record about the sub-transaction in the locally maintained main pre-write log to the committed state, and updates the primary replica according to the write set of the sub-transaction; synchronizes the commit request to the candidates, controls the candidates to set the log record about the sub-transaction in the locally maintained slave pre-write log to the committed state, and updates the secondary replicas according to the write set extracted from the sub-transaction log record; the participant returns a response containing the read set of the sub-transaction to the coordinator.

[0091] In one embodiment, the commit operation is as follows: the participant sets the log record about the current sub-transaction in the local main pre-write log to the committed state, updates the local primary replica according to the write set of the current transaction, and synchronizes the commit request to the candidates in the replica group where it is located, prompting all candidates to also set the log record about the current sub-transaction in the locally maintained slave pre-write log to the committed state, and extracts the write set from the log record to update the local secondary replicas. Finally, the participant returns a response containing the read set of the current transaction to the coordinator.

[0092] Step S140: If the coordinator receives the default termination responses feedback by at least one participant, it sends a rollback request to all participants to control all participants to perform rollback operations, and issues a transaction termination requirement to the client.

[0093] In an embodiment, for the convenience of understanding the process corresponding to step S140, reference may be made to Figure 4 the timing diagram shown below. Figure 4 The timing diagram shown below demonstrates the processing flow of the transaction failure requiring the client to terminate the transaction, that is, for the case where the sub-transaction in the preparation phase fails to pass the data constraint detection. In this case, the participant that fails to pass the data constraint detection will return a default termination response. As long as any one participant feedbacks a default termination response, the coordinator will control all participants to perform rollback operations, because in this case, the current transaction cannot meet the preset data constraints even if retried and can no longer continue to execute the transaction. At the same time, the coordinator sends a transaction termination requirement including the reason why the transaction cannot be executed to the client. The execution process of the rollback operation has been described in detail above and will not be elaborated here.

[0094] Step S150: If the coordinator does not receive the default termination response feedback by any participant but receives the conflict termination responses feedback by at least one participant, it sends a rollback request to all participants to control all participants to perform rollback operations, and issues a transaction retry requirement to the client.

[0095] In an embodiment, for the convenience of understanding the process corresponding to step S150, reference may be made to Figure 5 the timing diagram shown below. Figure 5 The timing diagram shown below demonstrates the processing flow of the transaction failure requiring the client to retry the transaction, that is, for the case where there is no default termination response feedback by any participant but any one participant feedbacks a conflict termination response, which indicates that there is a participant that fails to pass the concurrent conflict detection. In this case, a rollback request is first sent to all participants to control all participants to perform rollback operations. In contrast, there is still a possibility to continue executing the transaction in this case, and a transaction retry requirement can be issued to the client. And execute the method provided by the present application here according to the instruction feedback by the client.

[0096] Further, after steps S140 and S150, if the coordinator subsequently receives the feedback response feedback by a certain participant in the preparation phase, it sends a sub-transaction rollback request to the participant, but does not send information to the client.

[0097] Step S160: If all participants have fed back submission responses, the coordinator constructs the submission requests for each participant and sends them. The submission requests are used to control the participants to enter the submission phase. The coordinator obtains the read sets returned by the participants after performing the submission operation, integrates all the received read sets, synthesizes the request result, and feeds it back to the client.

[0098] In one embodiment, for the convenience of understanding the process corresponding to step S160, reference may be made to Figure 6 the timing diagram shown below. Figure 6 The timing diagram shown below demonstrates the processing flow of successfully returning the request result for transaction processing. Correspondingly, that is, all participants have fed back submission responses, indicating that all participants are ready. The coordinator can then make a decision to commit the transaction, construct the submission requests for each participant and send them. The submission requests are used to control the participants to enter the submission phase. The participants then perform the submission operation and return the read sets obtained from performing the submission operation to the coordinator. The execution process of the submission operation has been described in detail above and will not be elaborated here. Until each participant has responded, the coordinator integrates the read sets included in each response, synthesizes the request result, and sends it to the client.

[0099] This application divides the entire set of data items to be processed by the participants into read sets and write sets, and does not need to send the entire set of data items to the coordinator. Instead, it only needs to send the read set of the current transaction to the coordinator once when responding to the submission request of the sub-transaction, and send a log record containing the read set and write set of the current transaction to each candidate in the replica group where it is located once after passing the conflict detection, reducing the network transmission volume of data and improving the transaction processing performance.

[0100] Furthermore, during the execution process of the flow provided in this application, there may also be situations where the coordinator or a participant waits for a timeout. In this regard, this application separately introduces a first termination protocol process and a second termination protocol process for waiting timeouts to handle them in a timely manner when a failure causes a timeout. This timely processing mechanism ensures that in specific situations, even if the coordinator or a participant waits for a timeout, the transaction can still be successfully processed. For the convenience of understanding the first termination protocol process and the second termination protocol process, reference may be made to Figure 7 and Figure 8 , Figure 7 which shows the timing diagram where the coordinator waits for a timeout but the transaction can still be successfully processed, Figure 8 and

[0101] Step S170: If the coordinator waits for a response from a certain participant to timeout, the coordinator executes the first termination protocol process.

[0102] In one embodiment, the coordinator executes the first termination protocol process, including: the coordinator calls the function LogOnce(current transaction, participant P, prepare to terminate) for each participant P of the current transaction and waits for the return results of each participant according to the LogOnce function; if there is a participant who returns prepare to terminate according to the LogOnce function, the coordinator issues a rollback request; if each participant returns ready according to the LogOnce function, the coordinator issues a commit request; if there is a participant who returns timeout according to the LogOnce function, wait for the new participant selected by the replica group where the participant is located; the coordinator calls the function LogOnce(current transaction, new participant, prepare to terminate) for the new participant until the new participant returns prepare to terminate or ready according to the LogOnce function.

[0103] In one embodiment, during the execution process, it is possible for the coordinator to wait for a participant to time out. In this case, the coordinator executes the first termination protocol process to solve 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 the termination protocol implementation function called by the coordinator, and the parameters include the current transaction ID, which is used to call LogOnce(current transaction, R, terminate) for all participants R corresponding to the current transaction to check the local transaction processing status of all participants. The coordinator waits for each participant to perform operations according to the return results of the LogOnce function. The definition of the LogOnce function has been described in detail above and will not be repeated here. That is to say, in the processing flow of the first termination protocol process, the coordinator can communicate with all participants to determine the local transaction status of all participants, so as to decide whether to commit or roll back, avoiding ineffective waiting and improving the processing efficiency.

[0104] If there is a participant who returns prepare to terminate according to the LogOnce function, it means that there is a participant whose preparation fails. The coordinator needs to issue a rollback request to all participants to control all participants to perform rollback operations.

[0105] If each participant returns ready according to the LogOnce function, it means that all participants have been prepared and can be committed. The coordinator can then issue a commit request to all participants to control the participants to enter the commit phase.

[0106] If there is a participant whose timeout is returned according to the LogOnce function, wait for the replica group where the participant is located to select a new replacement participant; the coordinator calls the function LogOnce(current transaction, new participant, prepare to terminate) on the new participant until the new participant returns prepare to terminate or ready according to the LogOnce function.

[0107] Furthermore, the introduction of the first termination protocol process enables the coordinator to perform timely control according to the timing of participant failures. If a participant P fails before receiving the sub-transaction prepare request, the replica group where P is located uses a preset consensus protocol to re-elect a new primary replica and its corresponding participant Q. At this time, the coordinator's wait for the response from participant P will surely time out, causing the coordinator to execute the first termination protocol process. Inevitably, the call to LogOnce(current transaction, P, terminate) also times out. Therefore, the coordinator identifies the new participant Q in the replica group where P is located and re-calls LogOnce(current transaction, Q, terminate). Since Q has not received the sub-transaction prepare request, LogOnce(current transaction, Q, terminate) will surely return terminate, prompting CoordinatorTerminationProtocol(current transaction) to return terminate. Thus, the coordinator can make a timely decision to roll back the transaction and send a sub-transaction rollback request to all participants (at this time Q has replaced P). Participants that have not yet entered the prepare phase, such as Q, automatically ignore this sub-transaction rollback request. Participants in the prepare phase, such as R, also ignore this sub-transaction rollback request and then handle it according to two cases:

[0108] (Case 1) If the sub-transaction fails to pass the data constraint check or concurrent conflict check during execution, then R returns a terminate response to the coordinator and enters the commit phase. Subsequently, the coordinator sends a sub-transaction rollback request to R again;

[0109] (Case 2) After the sub-transaction is executed normally and the log record is synchronized to the secondary replica, R calls LogOnce(current transaction, R, ready). Since the coordinator has previously called LogOnce(current transaction, R, terminate), LogOnce(current transaction, R, ready) returns terminate. Thus, R also returns a terminate response to the coordinator and enters the commit phase. Subsequently, the coordinator sends a sub-transaction rollback request to R again. After a participant in the commit phase receives the sub-transaction rollback request, it directly performs the transaction rollback operation.

[0110] If a certain participant P fails after receiving the sub - transaction prepare request and before returning a commit or abort response, the replica group where P is located uses a preset consensus protocol to re - elect a new primary replica and its corresponding participant Q. At this time, the coordinator will definitely time out while waiting for the response from participant P, and thus call the termination protocol implementation function CoordinatorTerminationProtocol(current transaction), and call LogOnce(current transaction, R, abort) for all participants R. Inevitably, the call to LogOnce(current transaction, P, abort) also times out. Therefore, the coordinator identifies the new participant Q in the replica group where P is located and re - calls LogOnce(current transaction, Q, abort). This call to the LogOnce function for Q will definitely return abort. Therefore, CoordinatorTerminationProtocol(current transaction) also returns abort, which prompts the coordinator to make a timely decision to roll back the transaction and send a sub - transaction roll - back request to all participants. Similarly, subsequent processing will cause all participants of the current transaction to perform transaction roll - back operations.

[0111] If a certain participant P fails after returning a commit response, the replica group where P is located uses a preset consensus protocol to re - elect a new primary replica and its corresponding participant Q. At this time, the coordinator makes corresponding processing according to three situations:

[0112] (Situation 1) The coordinator has made a commit decision and sent a sub - transaction commit request to all participants. At this time, the coordinator will definitely time out while waiting for the response from participant P. Therefore, the coordinator identifies the new participant Q in the replica group where P is located and sends a sub - transaction commit request to Q. Subsequently, Q replaces P to perform the transaction commit operation;

[0113] (Situation 2) The coordinator has made a roll - back decision and sent a sub - transaction roll - back request to all participants. At this time, the coordinator will definitely time out while waiting for the response from participant P. Therefore, the coordinator identifies the new participant Q in the replica group where P is located and sends a sub - transaction roll - back request to Q. Subsequently, Q replaces P to perform the transaction roll - back operation;

[0114] (Situation 3) The coordinator has not made a commit or roll - back decision yet. At this time, the coordinator is still in the preparation stage and will continue to wait for the commit or abort responses from other participants except P. If all other participants return commit responses later, it will be processed as in the above Situation 1; if a certain other participant returns an abort response later, it will be processed as in the above Situation 2.

[0115] If a participant P fails after returning a termination response, the replica group where P is located uses a 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 sub-transaction rollback request to all participants. After that, the coordinator will definitely time out while waiting for the response from participant P. Therefore, the coordinator identifies the new participant Q in the replica group where P is located and sends a sub-transaction rollback request to Q, and then Q replaces P to perform the transaction rollback operation.

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

[0117] In one embodiment, the participant executes the second termination protocol process, including: marking the participant that times out waiting for the coordinator as the current participant, and marking the participants other than the current participant among the participants of the current transaction participated by the current participant as the remaining participants; the current participant calls the function LogOnce(current transaction, participant P, prepare to terminate) for each remaining participant P and waits for the return result of each remaining participant according to the LogOnce function; if there is a remaining participant that returns prepare to terminate according to the LogOnce function, the current participant performs a rollback operation; if each remaining participant returns ready according to the LogOnce function, the current participant performs a commit operation; if there is a remaining participant that returns timeout according to the LogOnce function, wait for the replacement new participant selected by the replica group where the remaining participants are located; the current participant calls the function LogOnce(current transaction, new participant, prepare to terminate) for the new participant until the new participant returns prepare to terminate or ready according to the LogOnce function.

[0118] In one embodiment, it is also possible for a participant to wait for the coordinator response to time out during the execution of the process. In this case, the participant executes the second termination protocol process to resolve it. Specifically, during the execution of the second termination protocol process, the participant waiting for the coordinator to time out is marked as the current participant, and among the participants of the current transaction participated by the current participant, the participants other than 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 the termination protocol implementation function called by the current participant Q, and the parameters include the current transaction and the current participant ID, and are used to call LogOnce(current transaction, participant P, prepare to terminate) for each remaining participant P other than Q for the current transaction. The current participant Q waits for the results returned by each remaining participant P to perform operations. That is to say, in the case of waiting for the coordinator to time out, the current participant Q can imitate the function of the coordinator, view the local transaction status of all participants under the current transaction, and thus decide whether to commit or roll back by itself, avoiding ineffective waiting and improving the processing efficiency.

[0119] There may be various results when the current participant Q calls LogOnce(current transaction, participant P, prepare to terminate), so different operations can be performed for different results respectively:

[0120] If there is a remaining participant P who returns prepare to terminate according to the LogOnce function, it can be determined that the remaining participant P is ready to fail and the transaction processing cannot proceed, and the current participant Q can perform a rollback operation;

[0121] If each remaining participant returns ready according to the LogOnce function, it can be determined that all the remaining participants are ready and there is no need to wait for the coordinator to issue a commit request, and the current participant Q can perform a commit operation;

[0122] If there is a remaining participant P who returns timeout according to the LogOnce function, wait for the new participant R to be selected from the replica group where the remaining participant P is located; the current participant calls the function LogOnce(current transaction, new participant R, prepare to terminate) for the new participant R until the new participant R returns prepare to terminate or ready according to the LogOnce function.

[0123] Similar to the first termination protocol process, the introduction of the second termination protocol process can prompt the current participant to perform timely control according to the timing of the coordinator failure. If the coordinator fails before sending any sub-transaction prepare requests, the participant cannot receive the sub-transaction prepare requests and the participant does not need to take any action.

[0124] If the coordinator fails after sending out partial sub - transaction prepare requests and before sending out all sub - transaction prepare requests, then the coordinator will surely not receive responses from some participants on time after failure recovery. At this time, the coordinator will surely call the termination protocol implementation function CoordinatorTerminationProtocol(current transaction), and obtain the termination return result, thus making a decision to roll back the transaction, and sending out sub - transaction roll - back requests to all participants.

[0125] If the coordinator fails after sending out all sub - transaction prepare requests and before sending out sub - transaction commit requests to all participants, then there must be a current participant Q that waits for the sub - transaction commit request from the coordinator to time out. At this time, the current participant Q calls the termination protocol implementation function ParticipantTerminationProtocol(current transaction, Q), and calls LogOnce(current transaction, P, terminated) for each of the other remaining participants P of the current transaction except Q. If there is some other participant P that makes the LogOnce function call return terminated, then P did not respond to the sub - transaction prepare request of the coordinator. At this time, the coordinator did not make a decision to commit the transaction; when P needs to return the response to the sub - transaction prepare request, P calling LogOnce(current transaction, P, ready) will surely get a terminated return result, so the response that P returns to the coordinator is terminated, prompting the coordinator to make a decision to roll back the transaction. Therefore, ParticipantTerminationProtocol(current transaction, Q) returns terminated, and prompts the current participant Q to perform the transaction roll - back operation in a timely manner. If all other participants make the LogOnce function call return ready, then all participants of the current transaction, including the current participant Q itself, have returned commit responses to the coordinator. Therefore, ParticipantTerminationProtocol(current transaction, Q) returns commit, and prompts the current participant Q to perform the transaction commit operation in a timely manner.

[0126] If the coordinator fails after sending all sub - transaction prepare requests and before sending sub - transaction rollback requests to all participants, then there must be a current participant Q waiting for the sub - transaction rollback request from the coordinator to time out. At this time, the current participant Q calls the termination protocol implementation function ParticipantTerminationProtocol(current transaction, Q), and for each of the other remaining participants P of the current transaction except the current participant Q, calls LogOnce(current transaction, P, termination). Since the coordinator sends the sub - transaction rollback request only after making the decision to roll back the transaction, there must be a remaining participant P that has returned a termination response to the coordinator, so 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.

[0127] If the coordinator fails after sending sub - transaction commit requests to all participants, then all participants have started to execute the transaction commit operation. All participants need to wait for the coordinator to recover from the failure and then return a response containing the read set of the current transaction to the coordinator.

[0128] If the coordinator fails after sending sub - transaction rollback requests to all participants, then all participants have started to execute 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.

[0129] In summary, the above - mentioned fault - handling process ensures that the failures of the coordinator and participants can be handled promptly and properly, optimizing the 2PC protocol. In addition, when a participant enters the commit phase of the transaction commit step, the system's multi - copy mechanism ensures that even if the participant fails, it does not affect the correct commit or rollback operation of the sub - transaction undertaken by the participant, thus ensuring the fault tolerance of the system.

[0130] In the preparation phase, 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, it prompts the current transaction to restart execution, thus 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 execute concurrently, thus breaking the limitation that a new transaction needs to wait for other transactions to complete before it can execute in the serializable isolation level, greatly improving the concurrency of transaction processing.

[0131] In the case of timeouts occurring in the preparer or submitter coordinator or participants, the present application introduces a resolution mechanism in which the coordinator and participants execute different termination protocol processes respectively to handle in a timely manner timeouts caused by failures of the coordinator or participants. This mechanism ensures that failures of the coordinator and participants can be handled properly and promptly, optimizing the 2PC protocol.

[0132] Finally, the present application divides the complete set of data items to be processed by the participants into a read set and a write set, and does not need to send the complete set of data items to the coordinator. Instead, it only needs to send the read set of the current transaction to the coordinator once when responding to a subtransaction commit request, and send a log record containing the read set and write set of the current transaction to each candidate in the local replica group once after passing the conflict detection, reducing the network transmission volume of data and improving the transaction processing performance.

[0133] Figure 9 The internal structure diagram of a computer device in an embodiment is shown. This computer device can specifically be a client, a coordinator in a distributed transaction processing system, or a participant or a candidate. As Figure 9 shown, this computer device includes a processor, a memory, and a network interface connected through a system bus. Among them, the memory includes a non-volatile storage medium and an internal memory. The non-volatile storage medium of this computer device stores an operating system and can also store a computer program. When the computer program is executed by the processor, the processor can implement the transaction processing method of the distributed transaction processing system. The internal memory can also store a computer program. When the computer program is executed by the processor, the processor can execute the transaction processing method of the distributed transaction processing system. Those skilled in the art can understand that Figure 9 the structure shown in

[0134] In an embodiment, the present application also proposes a computer-readable storage medium storing a computer program. When the computer program is executed by the processor, the processor is caused to execute the steps of the method described in any of the foregoing embodiments.

[0135] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. 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 methods. Among them, any reference to a memory, storage, database, or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memories. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

[0136] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, 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, it should be considered as the scope described in this specification.

[0137] The above-described embodiments merely represent several implementation manners of the present application. The description is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application should be subject to the appended claims.

Claims

1. A transaction processing method for a distributed transaction processing system, characterized in that Applied to a distributed transaction processing system; The distributed transaction processing system is composed of multiple nodes. All the stored data in the distributed transaction processing system is divided into multiple data shards; each data shard has a preset number of replicas. The replicas are divided into a unique primary replica and multiple secondary replicas according to a preset consensus protocol. The primary replica and the secondary replicas 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 primary replica is called a participant, and the node storing the secondary replicas is called a candidate; The distributed transaction processing system further includes a client and a coordinator, and the client and the coordinator are deployed in a certain node or two different nodes of the distributed transaction processing system; The client and the coordinator are associated, the coordinator is associated with all the nodes, and the participants are associated with each other; The method includes the following steps: After the client obtains a transaction processing request issued by a user, it 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 a number of sub-transactions, and each sub-transaction only involves 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 a prepare operation on the sub-transaction. The prepare operation includes data constraint detection, concurrent conflict detection, log record operation, and status synchronization operation; The participant generates a feedback response according to the local transaction state obtained from the prepare operation and returns the feedback response to the coordinator. The local transaction state is one of ready and aborted, and the feedback response is one of commit response, default abort response, and conflict abort response; If the coordinator receives at least one default abort response feedback from a participant, it sends a rollback request to all the participants to control all the participants to perform a rollback operation and issues a transaction termination requirement to the client; If the coordinator does not receive any default abort response feedback from a participant but receives at least one conflict abort response feedback from a participant, it sends a rollback request to all the participants to control all the participants to perform a rollback operation and issues a retry transaction requirement to the client; If all the participants feedback the commit response, the coordinator constructs and sends a commit request for each participant. 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 performing the commit operation, integrates all the received read sets, synthesizes the request result and feeds it back to the client; If the coordinator times out waiting for a response from a participant, the coordinator executes the first termination protocol process; If the waiting of the participant for the coordinator's request times out, the participant executes the second termination protocol process.

2. The transaction processing method of the 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 sub-transaction. The read set and the write set are composed of quadruples, and the quadruple 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 the data constraint detection to determine whether the data item meets the preset data constraints; If the data item does not meet the data constraints, the participant sends the default termination response to the coordinator, ends the prepare phase process of the sub-transaction, and no longer performs the concurrent conflict detection, the log record operation, and the status synchronization operation; If the data item meets the data constraints, the participant performs the concurrent conflict detection on the sub-transaction it undertakes according to the created read set and write set.

3. The transaction processing method of the distributed transaction processing system according to claim 2, wherein, The participant maintains a transaction reservation table, which is composed of quintuples, and the quintuple includes a data item, a transaction ID, a statement ID, a read / write flag, and a read / write time; The read / write time is the local time of the participant; the participant locally records the start time and the commit time of the transaction it is in. 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 defined as a completed transaction; A transaction whose commit time has not been set in the transaction reservation table is called an uncompleted transaction; The concurrent conflict detection includes: If there is an uncompleted transaction in the sub-transactions processed by the participant, the uncompleted transaction has a corresponding write quintuple in the transaction reservation table, and the write time of the uncompleted transaction is smaller than the maximum read / write time of the quadruple of the current transaction for the same data item in the participant's read set or write set. The current transaction is the sub-transaction being processed by the participant, or If there is a completed transaction in the sub-transactions 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 quadruple of the current transaction for the same data item in the participant's read set or write set, or If there is a quadruple for the current transaction in the participant's write set, and the write time of the quadruple is smaller than the maximum read / write time of the quintuple for the same data item in the transaction reservation table, it is considered that the concurrent conflict detection cannot pass. The participant sends the conflict termination response to the coordinator, ends the prepare phase process of the sub-transaction, and no longer performs the log record operation and the status synchronization operation; If the above situation does not occur, it is considered that the concurrent conflict detection can be passed, and the log recording operation and the status synchronization operation are continued.

4. The transaction processing method of the distributed transaction processing system according to claim 1, characterized in that, The participant maintains a local main write-ahead log, and the candidate maintains a local slave write-ahead log. Both the local main write-ahead log and the local slave write-ahead log 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. The execution of the 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 main write-ahead log of the main copy corresponding to the sub-transaction. The log record is sent to the local slave write-ahead log of the slave copy of the copy group where the sub-transaction is located until the copy group meets the consensus condition of the preset consensus protocol, and the log recording operation ends.

5. The transaction processing method of the distributed transaction processing system according to claim 1, characterized in that, The status synchronization operation includes: It is executed after the data item of the sub-transaction passes the data constraint detection, the concurrent conflict detection, and the log recording operation. Each participant P calls the function LogOnce (current transaction, participant P, ready), and records the local state of the sub-transaction locally at participant P. The parameters of the LogOnce function are transaction ID, participant ID, and local state of the sub-transaction respectively. If the participant corresponding to the second parameter in the LogOnce function has already 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 sub-transaction corresponding to the third parameter in the LogOnce function is set as 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 issue the rollback request. Otherwise, the LogOnce function call returns ready, the participant returns the commit response to the coordinator, and waits for the coordinator to issue the commit request or the rollback request.

6. The transaction processing method of the distributed transaction processing system according to claim 1, characterized in that, The coordinator executes the first termination protocol process, including: The coordinator calls the function LogOnce (current transaction, participant P, ready to terminate) for each participant P of the current transaction, and waits for the return results of each participant according to the LogOnce function. If there is a participant who returns ready to terminate according to the LogOnce function, the coordinator issues the rollback request. If each participant returns ready according to the LogOnce function, the coordinator issues the commit request. If there is a timeout returned by a certain participant according to the LogOnce function, wait for the replica group where the participant is located to select a new replacement participant; the coordinator calls the function LogOnce(current transaction, the new participant, ready to terminate) on the new participant until the new participant returns ready to terminate or ready according to the LogOnce function.

7. The transaction processing method of the distributed transaction processing system according to claim 1, characterized in that, The process for the participant to execute the second termination protocol includes: Mark the participant waiting for the coordinator timeout as the current participant, and mark the participants other than the current participant among the participants of the current transaction participated by the current participant as the remaining participants; The current participant calls the function LogOnce(current transaction, participant P, ready to terminate) on each of the remaining participants P and waits for the result returned by each of the remaining participants according to the LogOnce function; If there is a certain remaining participant that returns ready to terminate according to 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 commit operation; If there is a certain remaining participant that returns a timeout according to the LogOnce function, wait for the replica group where the remaining participant is located to select a new replacement participant; the current participant calls the function LogOnce(current transaction, the new participant, ready to terminate) on the new participant until the new participant returns ready to terminate or ready according to the LogOnce function.

8. The transaction processing method of the distributed transaction processing system according to claim 1, characterized in that, The rollback operation includes: The participant clears all quadruples corresponding to the subtransaction in the read set and write set constructed according to the subtransaction, and clears all quintuples corresponding to the subtransaction in the transaction reservation table; The participant sets the log record about the subtransaction in the locally maintained main pre-write log to the deleted state; The participant synchronizes the rollback request to the candidates to control all candidates to set the log record about the subtransaction in the locally maintained slave pre-write log to the deleted state; The participant returns a response containing no data item information to the coordinator.

9. The transaction processing method of the distributed transaction processing system according to claim 1, characterized in that, The commit operation includes: The participant sets the log record about the subtransaction in the locally maintained main pre-write log to the committed state and updates the main replica according to the write set of the subtransaction; Synchronize the commit request to the candidates, control the candidates to set the log record about the subtransaction in the locally maintained slave pre-write log to the 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 containing the read set of the subtransaction to the coordinator.

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, it implements the method according to any one of claims 1 to 9.

Images