Transaction processing method, device, node equipment and storage medium

Abstract

The present application discloses a transaction processing method, apparatus, node device and storage medium, belonging to the field of database technology. The present application can be applied to various scenarios such as cloud technology, artificial intelligence, smart transportation, and assisted driving. After distributing sub-transactions to the master-replica node device in a distributed database system, the master-replica node device is only instructed to perform data anomaly detection in the preparation phase without performing data synchronization between the master and slave replicas. After the submission phase, the master-replica node device is instructed to locally submit the sub-transaction and synchronize the redo log to the slave replica node device. Only one round of communication is required to achieve data consistency between the master and slave replicas, which greatly reduces the number of synchronizations between the master and slave replicas and compresses the replica synchronization overhead, thereby minimizing the adverse effects of the multi-replica mechanism on the transaction processing performance within the system.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a transaction processing method, apparatus, node device, and storage medium. Background Art

[0002] With the development and advancement of database technology and the prevalence of cloud environments, the use of distributed databases to provide data services for large-scale online applications has become increasingly popular. Currently, to provide highly available data services, distributed databases generally incorporate a multi-replication mechanism. Specifically, within a data storage cluster, data is partitioned into multiple data partitions and stored on different data nodes. Each data partition is synchronized between a master and slave replica, typically with one master replica corresponding to multiple slave replicas.

[0003] When a multi-copy mechanism is introduced, replica synchronization technology with operation granularity is involved. That is, during the transaction execution process, for each write operation involved in the transaction, the master replica will synchronize the written data to the slave replica. However, in big data scenarios, parallel transactions may perform a large number of write operations at the same time. At this time, the number of synchronizations between the master and slave replicas in the cluster increases sharply, and the replica synchronization overhead is very high, which can easily have an adverse impact on the transaction processing performance of the database system. Summary of the Invention

[0004] The present invention provides a transaction processing method, apparatus, node device, and storage medium that can reduce the number of synchronizations between master and slave replicas within a cluster, reduce replica synchronization overhead, and mitigate the adverse effects of replica synchronization on system transaction processing performance. The technical solution is as follows:

[0005] In one aspect, a transaction processing method is provided, which is executed by a coordination node device of a distributed database system, the method comprising:

[0006] Determine the primary and secondary node devices corresponding to the database operations executed by the target transaction;

[0007] Distributing the sub-transactions of the target transaction on the master and replica node devices to the master and replica node devices;

[0008] Sending a prepare request to the master and replica node devices, wherein the prepare request is used to instruct the master and replica node devices to perform data anomaly detection on the sub-transaction;

[0009] When the transaction commit conditions are met, a commit request is sent to the master replica node device, wherein the commit request is used to instruct the master replica node device to commit the sub-transaction and send the redo log of the sub-transaction to the corresponding slave replica node device.

[0010] In one aspect, a transaction processing method is provided, which is executed by a master and replica node device of a distributed database system, the method comprising:

[0011] In response to a sub-transaction of the target transaction on the primary and replica node devices, executing a database operation corresponding to the sub-transaction;

[0012] In response to a prepare request of the target transaction, performing data anomaly detection on the sub-transaction;

[0013] Committing the sub-transaction in response to a commit request of the target transaction;

[0014] The redo log of the sub-transaction is sent to the corresponding slave replica node device, so that the slave replica node device redoes the sub-transaction when replaying the redo log.

[0015] In one aspect, a transaction processing device is provided, the device being a coordination node device of a distributed database system, the device comprising:

[0016] A determination module, configured to determine the primary and secondary node devices corresponding to the database operations executed by the target transaction;

[0017] A distribution module, configured to distribute the sub-transactions of the target transaction on the master and replica node devices to the master and replica node devices;

[0018] A sending module, configured to send a prepare request to the master and replica node devices, wherein the prepare request is used to instruct the master and replica node devices to perform data anomaly detection on the sub-transaction;

[0019] The sending module is also used to send a commit request to the master replica node device when the transaction commit conditions are met. The commit request is used to instruct the master replica node device to commit the sub-transaction and send the redo log of the sub-transaction to the corresponding slave replica node device.

[0020] In one possible implementation, the determining module is configured to:

[0021] Determine the data partition to which the data item corresponding to the database operation belongs;

[0022] Based on the partition information table, the master and replica node devices corresponding to the data partitions are queried and obtained. The partition information table is used to record the corresponding relationship between the data partitions and the master and replica node devices.

[0023] In one possible implementation, the coordination node device stores an operation log list of the target transaction, where the operation log list includes operation records of database operations currently executed by the target transaction;

[0024] The apparatus further includes: an adding module for adding, in response to the sub-transaction execution result returned by the master-copy node device, an operation record of the database operation executed by the sub-transaction in the operation log list, wherein the operation record represents the operation type of the database operation and the data items involved in the operation.

[0025] In a possible implementation, in the distributed database system, the coordinating node device and at least one other coordinating node device constitute a coordinating node group, and the sending module is further configured to:

[0026] At intervals of a first target duration, a stored operation log list of at least one transaction is sent to the at least one other coordination node device in the coordination node group.

[0027] In one possible implementation, the sending module is further configured to:

[0028] When the operation records of the sub-transactions of the target transaction are all added to the operation log list and the operation log list has been synchronized to any other coordination node device, the preparation request is sent to the master and replica node devices.

[0029] In one possible implementation, the operation log list is further used to store at least one of a preparation operation record or a submission operation record of the target transaction, wherein the preparation operation record is used to record the status of the target transaction in the preparation phase, and the submission operation record is used to record the status of the target transaction in the submission phase.

[0030] In a possible implementation manner, the determination module is further configured to: if the master and replica node devices fail, determine a target node device selected from at least one slave node device corresponding to the master and replica node devices;

[0031] The determining module is further configured to: determine a target sub-transaction corresponding to the target node device, wherein the target sub-transaction is a sub-transaction originally executed by the primary and replica node devices but waiting to be recovered due to a failure;

[0032] The sending module is further configured to send the to-be-recovered operation queue of the target sub-transaction to the target node device, where the to-be-recovered operation queue includes at least one operation record corresponding to the target sub-transaction in the operation log list.

[0033] In one possible implementation, the target node device is randomly selected from the at least one slave replica node device; or, the target node device is the node device with the lowest load among the at least one slave replica node device.

[0034] In one possible implementation, in the distributed database system, the coordinating node device and at least one other coordinating node device constitute a coordinating node group. If any other coordinating node device in the coordinating node group fails, the coordinating node device takes over transactions originally executed on the other failed coordinating node device. The apparatus further includes:

[0035] a query module, configured to query a synchronization progress parameter of an operation log list of any transaction originally being executed on the other coordination node device that has failed, wherein the synchronization progress parameter is used to indicate whether the coordination node device has synchronized the operation log list of the entire transaction;

[0036] A coordination module, configured to coordinate the transaction based on the synchronized operation log list when the synchronization progress parameter indicates that the operation log list of the entire transaction has been synchronized;

[0037] The coordination module is further configured to notify the terminal that initiated the transaction to resend the request statement of the transaction when the synchronization progress parameter indicates that the operation log list of the entire transaction has not been synchronized; and coordinate the transaction based on the request statement returned by the terminal.

[0038] In one aspect, a transaction processing device is provided, the device being a master / replica node device of a distributed database system, the device comprising:

[0039] An execution module, configured to execute a database operation corresponding to a sub-transaction of a target transaction on the primary and replica node devices in response to the sub-transaction of the target transaction;

[0040] a detection module, configured to perform data anomaly detection on the sub-transaction in response to a prepare request of the target transaction;

[0041] a commit module, configured to commit the sub-transaction in response to a commit request of the target transaction;

[0042] The sending module is used to send the redo log of the sub-transaction to the corresponding slave replica node device, so that the slave replica node device redoes the sub-transaction when playing back the redo log.

[0043] In one possible implementation, when the master replica node device serves as a slave replica node device of another master replica node device, if the other master replica node device fails, the master replica node device is elected as the target node device, the apparatus further includes:

[0044] a receiving module, configured to receive a queue of operations to be recovered of a target sub-transaction sent by any coordinating node device, wherein the target sub-transaction is a sub-transaction originally assigned by the coordinating node device to the other primary and replica node devices for execution but is awaiting recovery due to a failure;

[0045] a determination module configured to determine, based on the queue of operations to be recovered, from the target subtransactions, a first subtransaction that meets a transaction commit condition, a second subtransaction that meets a transaction rollback condition, and a remaining third subtransaction;

[0046] a redo module, configured to redo the first sub-transaction and the third sub-transaction based on the queue of operations to be recovered;

[0047] A discarding module is configured to discard the operation record associated with the second sub-transaction.

[0048] In one possible implementation, the determining module is configured to:

[0049] In the queue of operations to be recovered, query the preparation operation record of the parent transaction corresponding to any target sub-transaction;

[0050] If the prepare operation record indicates that the parent transaction is in a prepare-completed state during the prepare phase, determining the target subtransaction as the first subtransaction;

[0051] If the prepare operation record indicates that the parent transaction is in a prepare failure state during the prepare phase, determining the target subtransaction as a second subtransaction;

[0052] If the prepare operation record indicates that the state of the parent transaction in the prepare phase is neither the prepare complete state nor the prepare fail state, the target subtransaction is determined to be the third subtransaction.

[0053] In one possible implementation, the redo module includes:

[0054] a first redo unit, configured to redo the first subtransaction based on the queue of operations to be recovered;

[0055] The second redo unit is used to redo the third sub-transaction based on the queue of operations to be recovered when a redo completion instruction is received from any coordination node device in the multiple coordination node groups in the distributed database system, and the redo completion instruction is used to indicate that the redo of the first sub-transaction coordinated by the corresponding coordination node group is completed.

[0056] In one possible implementation manner, the first redo unit is configured to:

[0057] When the target node device has completed replaying the redo log of the first subtransaction, maintaining information required for concurrency control of the first subtransaction and committing the first subtransaction; or

[0058] In a case where the target node device has not yet replayed the redo log of the first subtransaction, based on the queue of operations to be recovered, at least one operation record corresponding to the first subtransaction is executed, information required for concurrency control of the first subtransaction is maintained, and the first subtransaction is committed.

[0059] In one possible implementation manner, the second redo unit is configured to:

[0060] executing, based on the queue of operations to be recovered, at least one operation record corresponding to the third subtransaction, and maintaining information required for concurrency control of the third subtransaction;

[0061] In response to a commit request for the third subtransaction, commit the third subtransaction, and send a redo log of the third subtransaction to at least one slave replica node device corresponding to the target node device;

[0062] In response to the rollback instruction for the third sub-transaction, the third sub-transaction is rolled back.

[0063] On the one hand, a node device is provided, which includes one or more processors and one or more memories, wherein the one or more memories store at least one computer program, and the at least one computer program is loaded and executed by the one or more processors to implement a transaction processing method such as any possible implementation method described above.

[0064] On the one hand, a storage medium is provided, in which at least one computer program is stored. The at least one computer program is loaded and executed by a processor to implement a transaction processing method as described in any possible implementation manner.

[0065] In one aspect, a computer program product or computer program is provided, comprising one or more program codes stored in a computer-readable storage medium. One or more processors of a node device can read the one or more program codes from the computer-readable storage medium and execute the one or more program codes, thereby enabling the node device to perform the transaction processing method of any of the possible implementations described above.

[0066] The beneficial effects of the technical solutions provided in the embodiments of the present application include at least:

[0067] In a distributed database system, after distributing sub-transactions to the master and replica node devices, in the preparation phase of the two-phase commit algorithm, the coordination node device sends a preparation request, which only instructs the master and replica node devices to perform data anomaly detection but does not require data synchronization between the master and slave replicas. After the transaction commit conditions are met and the commit phase is entered, the coordination node device sends a commit request to instruct the master and replica node devices to locally commit the sub-transactions and synchronize the redo logs to the slave replica node devices. Therefore, only one round of communication is required in the commit phase to achieve data consistency between the master and slave replicas, thereby greatly reducing the number of synchronizations between the master and slave replicas in the system, compressing the replica synchronization overhead under the multi-replica mechanism, and thus minimizing the adverse effects of the multi-replica mechanism on the transaction processing performance in the system. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0069] Figure 1 This is a schematic diagram of the architecture of a distributed database system using a multi-copy mechanism provided in an embodiment of the present application;

[0070] Figure 2 This is a schematic diagram of the principle of replica synchronization at an operation granularity provided by an embodiment of the present application;

[0071] Figure 3 This is a schematic diagram of the principle of a fault recovery technology under operation granularity synchronization provided by an embodiment of the present application;

[0072] Figure 4 This is a schematic diagram of the principle of replica synchronization at a transaction granularity provided by an embodiment of the present application;

[0073] Figure 5 This is a schematic diagram of an implementation environment of a transaction processing method provided in an embodiment of the present application;

[0074] Figure 6 This is a flowchart of a transaction processing method provided by an embodiment of the present application;

[0075] Figure 7 This is an interactive flow chart of a transaction processing method provided by an embodiment of the present application;

[0076] Figure 8 This is a principle flow chart of a lightweight transaction-granularity replica synchronization mechanism provided by an embodiment of the present application;

[0077] Figure 9This is a schematic diagram of the principle of a lightweight transaction-granularity replica synchronization mechanism provided by an embodiment of the present application;

[0078] Figure 10 This is a principle flow chart of a lightweight transaction-granularity replica synchronization mechanism combined with the OCC algorithm provided in an embodiment of the present application;

[0079] Figure 11 This is an interactive flow chart of a fault recovery process when a master and replica node device fails, provided by an embodiment of the present application;

[0080] Figure 12 This is a principle flow chart of a fault recovery mechanism provided by an embodiment of the present application;

[0081] Figure 13 This is a schematic diagram of a transaction recovery process provided by an embodiment of the present application;

[0082] Figure 14 This is an interactive flow chart of a fault recovery process when a coordination node device fails, provided by an embodiment of the present application;

[0083] Figure 15 This is a schematic diagram of a transaction execution process provided by an embodiment of the present application;

[0084] Figure 16 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of the present application;

[0085] Figure 17 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of the present application;

[0086] Figure 18 This is a structural diagram of a node device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0087] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0088] In this application, the terms "first", "second", etc. are used to distinguish identical or similar items with substantially the same effects and functions. It should be understood that there is no logical or temporal dependency between "first", "second", and "nth", nor is there any limitation on the quantity and execution order.

[0089] In the present application, the term "at least one" means one or more, and the term "plurality" means two or more. For example, a plurality of first positions means two or more first positions.

[0090] In this application, the term "including at least one of A or B" refers to the following situations: including only A, including only B, and including both A and B.

[0091] The user-related information (including but not limited to the user's device information, personal information, behavioral information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application, when applied to specific products or technologies in the manner of the embodiments of this application, are all obtained with the user's permission, consent, authorization or full authorization of all parties, and the collection, use and processing of relevant information, data and signals must comply with the relevant laws, regulations and standards of the relevant countries and regions. For example, the data items involved in this application (if related to the user) are all obtained with full authorization and separate consent.

[0092] Before introducing the embodiments of this application, it is necessary to introduce some basic concepts in the field of cloud technology:

[0093] Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide or local area network (WAN) to enable data computing, storage, processing, and sharing. It is also a general term for network technology, information technology, integration technology, management platform technology, and application technology, all of which are applied within the cloud computing business model. This technology forms a resource pool that can be used flexibly and conveniently on demand. Cloud computing will become a crucial pillar of the cloud technology landscape. Backend services for technical network systems, such as those for video sites, image sites, and more portals, require significant computing and storage resources. With the rapid development and application of the internet industry, every item will likely have its own unique identifier and will need to be transmitted to backend systems for logical processing. Data of varying levels will be processed separately, and data from all industries will require robust system support, which can be achieved through cloud computing.

[0094] Cloud Storage: A new concept that extends and develops from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as storage system) refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to bring together a large number of different types of storage devices (storage devices are also called storage nodes) in the network through application software or application interfaces to work together and provide external data storage and business access functions.

[0095] Database: Simply put, it can be thought of as a digital filing cabinet—a place where electronic files are stored, where users can add, query, update, and delete data. A database is a collection of data stored in a specific way, shared by multiple users, with minimal redundancy, and independent of applications.

[0096] The following explains the terms used in the embodiments of the present application:

[0097] Distributed database: Distributed database systems usually use smaller computer systems. Each computer can be placed in a separate place. Each computer may have a complete copy of the database management system, or a partial copy, and has its own local database. Many computers located in different locations are interconnected through the network to form a complete, global, logically centralized, and physically distributed large database.

[0098] Transaction: A transaction is a logical unit of execution within a database management system. It consists of a finite sequence of database operations and is the smallest execution unit of a database system operation. Within a system, each series of operations is called a transaction, and a single operation can also be called a transaction.

[0099] Database operation: A database operation consists of three parts: operation type, transaction, and variable version. This refers to which version of the variable the transaction performs which type of database operation on. Operation types include read and write, and variables are the actors (or operation objects) of database operations. A variable can contain several variable versions (also called versions). Whenever a transaction updates a variable, a new variable version is added. Each variable version is usually identified by a natural number as the version number. The larger the version number, the newer the variable version.

[0100] Concurrency control: In computer science, particularly in programming, operating systems, multiprocessing, and databases, concurrency control is a mechanism that ensures the timely correction of errors caused by concurrent operations. The basic unit of concurrency control is the transaction. Concurrency control refers to various techniques used to protect database integrity when multiple users are updating and executing concurrently. Improper concurrency mechanisms can lead to problems such as dirty reads, phantom reads, and non-repeatable reads.

[0101] Locking mechanism: In a database system, different transactions may need to modify the same data item at the same time. The locking mechanism is used to ensure the correctness of modifications to these data items in different concurrent transactions. In other words, the locking mechanism can ensure that in a multi-concurrent transaction environment, at a certain point in time, only one transaction can obtain the lock for a certain data item, thereby ensuring data consistency.

[0102] Optimistic Concurrency Control (OCC): The OCC algorithm is a concurrency control method applied to transactional systems, such as relational database management systems and software in-memory transactions. The OCC algorithm assumes that most transactions can complete without interfering with each other. When a transaction is running, it can use resources without acquiring locks. Before committing, each transaction verifies that no other transaction has modified the data items it reads. If conflicting modifications are detected, the transaction is rolled back.

[0103] Two-Phase Commit (2PC): Also known as two-phase commit, in the computer networking and database fields, two-phase commit refers to an algorithm designed to maintain consistency when committing transactions across all nodes in a distributed database system architecture. Two-phase commit is often referred to as a protocol. In distributed database systems, transactions involving cross-node operations involve each node knowing whether its own database operation succeeded or failed, but not whether operations on other nodes succeeded or failed. When a transaction spans multiple nodes, to maintain ACID properties, a coordinator component is required to centrally monitor the operation results across all nodes (called participants) and ultimately instruct them whether to actually commit the results (e.g., write updated data items to disk). Therefore, the two-phase commit algorithm can be summarized as follows: participants notify the coordinator of the success or failure of their operations, and the coordinator, based on the feedback from all participants, decides whether to commit or abort the operation. ACID refers to the four properties that a database management system must possess to ensure that transactions are correct and reliable when writing or updating data: Atomicity (or indivisibility), Consistency (Consistency), Isolation (also known as independence), and Durability.

[0104] With the development and advancement of database technology and the prevalence of cloud environments, the use of distributed databases to provide data services for large-scale online applications has become increasingly popular. Currently, to provide highly available data services, distributed databases generally incorporate a multi-replication mechanism. Specifically, within a data storage cluster, data is partitioned into multiple data partitions and stored on different data nodes. Each data partition is synchronized between a master and slave replica, with one master replica typically corresponding to multiple slave replicas. It should be noted that in a multi-replication mechanism, master and slave replicas are relative to data partitions. That is, a distributed database system may include at least one node device, each of which may store data for multiple data partitions. However, master replica functionality is provided only for some data partitions, while slave functionality is provided for the remaining data partitions. In other words, the same physical machine may serve as the master replica for some data partitions and as a slave replica for others.

[0105] Figure 1 This is a schematic diagram of a distributed database system using a multi-copy mechanism provided in an embodiment of the present application. Figure 1 As shown, in the distributed database system 100, the node devices in the system can be decomposed into two layers: a coordination layer and a storage layer. The coordination layer is composed of multiple coordination node devices (Coordinator) in the system. For example, the coordination layer includes coordination node devices 111 to 113. The coordination node device refers to the coordinator in the two-phase commit algorithm. The coordination node device is responsible for independently coordinating transactions and returning transaction execution results to the client; the storage layer is composed of multiple data node devices (Data Server) in the system. For example, the storage layer includes data node devices 121 to 124. The data node device refers to the participant in the two-phase commit algorithm. The data node device is responsible for storing and reading and writing data items.

[0106] In the distributed database system 100, data is horizontally divided into multiple data partitions (Partitions). Each data partition contains a specific number of data items and is distributed on each data node device according to certain rules (such as hash partitioning). For each data partition, there is a corresponding replica group (Replica Group) in the distributed database system 100. That is, the same data partition will store multiple data replicas on different data node devices. There is only one leader replica in a replica group. Figure 1 The coordinating node device will send all data requests related to the data partition, i.e., read and write requests, to the primary replica. At the same time, all replicas in the replica group except the primary replica are slave replicas (Follower, Figure 1The number of slave replicas can be one or more, and the master and slave replicas use a replica synchronization mechanism (generally using a consensus protocol such as Paxos, Raft, etc.) to keep data synchronized between the slave replicas and the master replica.

[0107] Schematically, data node device 121 stores data for data partitions 1, 2, and 3. Data node device 121 serves as the primary replica only for data partition 1 and as a secondary replica for the remaining data partitions 2 and 3. Similarly, data node device 122 stores data for data partitions 1 and 2. Data node device 122 serves as a secondary replica for data partition 1 and as the primary replica for data partition 2. Similarly, data node device 123 stores data for data partitions 2 and 3. Data node device 123 serves as a secondary replica for data partition 2 and as the primary replica for data partition 3. Similarly, data node device 124 stores data for data partitions 1 and 3. Data node device 124 serves as a secondary replica for data partitions 1 and 3. For the same data partition, taking data partition 1 as an example, any transaction that changes the data in data partition 1 will synchronize data (replication) between the primary replica (i.e., data node device 121) and its two secondary replicas (i.e., data node devices 122 and 124).

[0108] Schematically, in the above-mentioned distributed database system 100, the overall process of transaction execution includes: after receiving an external data request to initiate a transaction, the system randomly assigns a coordination node device to the transaction. For example, the external transaction 1 (Txn 1) is assigned to the coordination node device 111, and the coordination node device 111 is responsible for coordinating the subsequent operations of transaction 1. Next, the coordination node device 111 decomposes the transaction 1 into one or more sub-transactions and distributes each sub-transaction to the corresponding data node device. For example, if a sub-transaction of transaction 1 is to operate on data on data partition 3, the coordination node device 111 determines the data partition 3 where the data items involved in the sub-transaction are located based on the partition information table. Then, it finds the primary copy of data partition 3, that is, the data node device 123, and then sends the database operation statement related to the sub-transaction to the data node device 123, so that the data node device 123 can execute the sub-transaction. Finally, when the read and write operations of all sub-transactions of transaction 1 are completed, the transaction will be globally committed within the distributed database system 100 according to the two-phase commit algorithm. At this time, the coordination node device 111 will initiate a 2PC request to communicate with each data node device affected by transaction 1, and complete the global commit of transaction 1 through the two stages of preparation (Prepare) and submission (Commit).

[0109] In the framework of the above-mentioned distributed database system, it can be seen that any distributed database system (such as Spanner, CockroachDB, etc.) can be logically divided into a coordination layer and a data layer. The coordination layer is composed of multiple coordination node devices. The coordination node devices are responsible for processing data requests, breaking down the transactions corresponding to the data requests into sub-transactions, and distributing the sub-transactions. They are also responsible for returning the transaction execution results to the client. The data layer is composed of multiple data node devices. The data node devices are responsible for storing and reading and writing data items. For example, each data node device can store one or more data tables in its database, and each data table can be used to store one or more data items.

[0110] In some embodiments, the above-mentioned distributed database system can be provided as a database system based on blockchain technology (hereinafter referred to as the "blockchain system"). The above-mentioned blockchain system is essentially a decentralized distributed database system, which adopts a consensus algorithm to maintain the consistency of the ledger data recorded by different node devices on the blockchain, and uses a cryptographic algorithm to ensure the encrypted transmission and non-tamperability of the ledger data between different node devices. The ledger function is expanded through a script system, and the interconnection between different node devices is carried out through network routing.

[0111] A blockchain system may include one or more blockchains. A blockchain is a string of data blocks generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block.

[0112] Nodes in a blockchain system can form a peer-to-peer (P2P) network. The P2P protocol is an application-layer protocol that runs on top of the Transmission Control Protocol (TCP). Within a blockchain system, any node device can possess the following functions: 1) Routing, a basic node function used to support communication between nodes; 2) Applications, deployed within the blockchain to implement specific services based on actual business needs. These applications record data related to these functions to form ledger data, which carries a digital signature to indicate the source of the data. These ledger data is then sent to other nodes in the blockchain system. Upon successful verification of the data's source and integrity, these nodes add the data to a temporary block. Applications can implement services such as wallets, shared ledgers, and smart contracts; 3) Blockchain, a series of sequentially connected blocks. Once a new block is added to the blockchain, it cannot be removed. Blockchains record the ledger data submitted by nodes in the blockchain system.

[0113] In some embodiments, each block may include a hash value of the transaction record stored in the block (the hash value of the block) and a hash value of the previous block. Each block is connected through the hash value to form a blockchain. In addition, the block may also include information such as the timestamp when the block was generated.

[0114] In the framework of the above-mentioned distributed database system, it can be seen that when introducing a multi-copy mechanism, it is necessary to implement replica synchronization between the master and slave replicas during the transaction execution process, such as replica synchronization at the operation granularity, replica synchronization at the transaction granularity, or other replica synchronization technologies. These technologies are explained one by one below.

[0115] A) Operation-level replica synchronization

[0116] Operation-granular replica synchronization means that during transaction execution, for each write operation, the primary replica will synchronize the written data items to the secondary replica. Figure 2 This is a schematic diagram of the principle of replica synchronization at an operation granularity provided by an embodiment of the present application, such as Figure 2 As shown, in the case of replica synchronization at the operation granularity, assuming that transaction T1 involves writing (Write) data items X1 and Y1, the coordination node device 201 will send the write operation (such as writing data version X1) to the master replica 211 of the data partition where X1 is located, and then the master replica 211 will initiate replica synchronization in the replica group 210 of the data partition where X1 is located, and synchronize the data item X1 to be written to the slave replicas 212 and 213. Finally, in the replica group 210, the master replica 211 and the slave replicas 212 and 213 will all update the data item X0 to X1 to maintain data consistency. Similarly, the coordination node device 201 will also send the write operation (such as writing data version Y1) to the master replica of the data partition where Y1 is located, and then the master replica will initiate replica synchronization to synchronize the data item Y1 to be written to the slave replica. This is similar to the replica synchronization process of X1 and will not be repeated here.

[0117] Based on this synchronization mechanism, when a node failure occurs on the primary replica in a replica group, since the secondary replica has already synchronized the data items of each write operation on the primary replica, it is only necessary to re-elect a primary replica in the replica group and continue to read and write data on the newly elected primary replica based on the synchronized data to achieve failure recovery. Figure 3 This is a schematic diagram of a principle of a fault recovery technology under operation granularity synchronization provided by an embodiment of the present application, such as Figure 3As shown, if the primary replica 211 in the replica group 210 fails before the transaction T1 reads the data item X, the replica group 210 will select a slave replica to replace it as the new primary replica. Assuming that the original slave replica 212 is selected as the new primary replica, since the old primary replica 211 has synchronized the data item X1 to the slave replica 212 when writing X1, after the slave replica 212 is selected as the new primary replica, the transaction T1 can continue to perform the read operation of X on the new primary replica (i.e., the slave replica 212) and can ensure that the data item X1 is read consistently before and after the failure occurs, so that the transaction T1 will not be rolled back due to the node failure.

[0118] B) Transaction-level replica synchronization

[0119] Transaction-granular replica synchronization refers to replica synchronization during the two-phase commit of a transaction. That is, in the prepare phase of the two-phase commit algorithm, a prepare log (Prepare Log) is first synchronized. The prepare log contains the data that needs to be written for this transaction; then, in the commit phase (Commit), a commit log (Commit Log) is synchronized. The commit log contains the commit information of this transaction.

[0120] Figure 4This is a schematic diagram of the principle of replica synchronization at a transaction granularity provided by an embodiment of the present application, as shown in 400. Assuming that the coordination node device of a certain transaction is C1, the transaction involves operating data items in data partitions 1 and 2, wherein data partition 1 includes the master replica P1 and the slave replica P1', and data partition 2 includes the master replica P2 and the slave replica P2', then when the transaction enters the preparation phase, the coordination node device C1 sends a preparation request to the master replicas P1 and P2 of the data partitions where all data items involved in the transaction are located. The master replica P1 will synchronize the received preparation log to the slave replica P1' and return a preparation completion response to the coordination node device C1. Similarly, the master replica P2 will synchronize the received preparation log to the slave replica P2' and return a preparation completion response to the coordination node device C1. After the coordination node device C1 receives the preparation completion response returned by the master replicas of all data partitions, assuming that all master replicas return preparation success, it enters the commit phase; otherwise, if any master replica returns preparation failure, the transaction will be rolled back. Then, in the transaction commit phase, the coordinating node device C1 sends a commit request to the primary replicas P1 and P2 of the data partitions where all data items involved in the transaction are located. The primary replica P1 will synchronize the received commit log to the slave replica P1' and return a commit completion response to the coordinating node device C1. Similarly, the primary replica P2 will synchronize the received commit log to the slave replica P2' and return a commit completion response to the coordinating node device C1. After the coordinating node device C1 receives the commit completion responses returned by the primary replicas of all data partitions, if all primary replicas return a commit success, the transaction commit is completed.

[0121] Based on this transaction-granular replica synchronization strategy, when a node failure occurs, the executing transaction will be rolled back. For example, Figure 3 In the failure shown, since the two-phase commit algorithm has not yet been entered and the transaction is still in execution, the master copy 211 fails. At this time, the slave copy 212 does not have the data item X1 written by transaction T1 (still the old version X0), which will cause transaction T1 to be unable to continue execution, so transaction T1 will be rolled back.

[0122] C) Other replica synchronization technologies

[0123] Traditional databases based on master-slave technology generally synchronize the logs generated by transactions to the backup machine when transactions are committed, to maintain consistency between the master and backup data. If a node failure occurs, this approach will roll back the transaction being executed on the failed node, and then the backup machine will continue to provide services. In addition, some systems use lazy replication (LazyReplication) to synchronize replicas to improve transaction processing performance. Lazy replication technology means that after a transaction is committed, additional update transactions are generated to asynchronously replay the data items written by the submitted transaction on the replica. However, if a node device fails, this mechanism will cause the data items written by the submitted transaction on the node device to be lost, so availability cannot be achieved.

[0124] To summarize, for the replica synchronization strategy at the operation granularity, since replica synchronization is required for each write operation, in big data scenarios, there may be a situation where a large number of parallel transactions need to perform write operations at the same time. At this time, the number of synchronizations between the master and slave replicas in the cluster increases sharply, the replica synchronization overhead is very large, and transaction performance is inevitably adversely affected; for the replica synchronization strategy at the transaction granularity, since replica synchronization is only performed when entering the two-phase commit, there may be a situation where many transactions are rolled back due to node failures before entering the two-phase commit.

[0125] In view of this, an embodiment of the present application provides a transaction processing method, namely, a lightweight replica synchronization mechanism, and provides a fast fault recovery method, which can improve the two major problems of replica synchronization affecting transaction processing performance under a multi-replica mechanism and system failures causing a large number of transactions to be rolled back, thereby achieving high availability and high processing performance for distributed database systems.

[0126] On the one hand, a lightweight transaction-granularity replica synchronization mechanism is provided to improve the transaction processing performance of distributed database systems. That is, the data items written by the transaction are packaged for replica synchronization only when each transaction is committed. Therefore, when each transaction performs replica synchronization, there is no need to perform two rounds of synchronization in the preparation phase and the submission phase. Instead, only one round of synchronization is required in the submission phase. Therefore, the network overhead of replica synchronization for each transaction can be reduced to one round, thereby minimizing the impact of replica synchronization on transaction performance.

[0127] On the other hand, a fast fault recovery algorithm is provided to improve the availability of the transaction-granularity replica synchronization mechanism. By building a coordination node group and utilizing the transaction operations (i.e., operation log list) temporarily stored on other coordination node devices in the coordination node group and the characteristics of multiple copies, it is ensured as much as possible that the transaction will not be rolled back due to node failure. In addition, when a node failure occurs, only the sub-transactions on the failed node are redone, and all sub-transactions of the entire parent transaction are not redone, thereby improving the transaction redo efficiency.

[0128] The following describes the system architecture of the embodiment of the present application.

[0129] Figure 5 This is a schematic diagram of an implementation environment of a transaction processing method provided in an embodiment of the present application. Figure 5 The embodiments of the present application are applicable to any distributed database system, such as Spanner, CockroachDB, etc., in which a gateway server 501, a distributed storage cluster 502, and a distributed coordination system 503 (such as ZooKeeper) may be included. The distributed storage cluster 502 is equivalent to a storage layer, including multiple data node devices, which are responsible for storing and reading and writing data items. The distributed coordination system 503 is equivalent to a coordination layer, including multiple coordination node devices, which are responsible for independently coordinating transactions and returning transaction execution results to the application client.

[0130] The gateway server 501 is used to receive external data requests and send the read and write transactions corresponding to the data requests to the distributed coordination system 503. For example, after the user logs in to the application client on the terminal, the application client is triggered to generate a data request and call the API (Application Programming Interface) provided by the distributed database system to send the data request to the gateway server 501. For example, the API can be a MySQL API (an API provided by a relational database system).

[0131] Optionally, the terminal used on the user side can be a smart phone, tablet computer, laptop computer, desktop computer, smart speaker, smart watch, smart voice interaction device, smart home appliance, car terminal, etc., but is not limited to these.

[0132] In some embodiments, the gateway server 501 can be combined with any coordination node device of the distributed coordination system 503 on the same physical machine, that is, a certain coordination node device can serve as the gateway server 501 .

[0133] The distributed coordination system 503 includes multiple coordination node groups, each coordination node group includes multiple coordination node devices. For data requests forwarded by the gateway server 501, the data request will be randomly assigned to a coordination node device in a coordination node group. The coordination node device parses the data request to obtain the corresponding read and write transaction, and then disassembles the read and write transaction to obtain one or more sub-transactions, and forwards each sub-transaction to the master copy (a data node device) of the corresponding data partition in the distributed storage cluster 502. At the same time, the coordination node device is also responsible for coordinating the two-stage commit of the read and write transaction. Finally, the coordination node device returns the transaction execution result of the read and write transaction to the gateway server 501, and then forwards the transaction execution result to the application client via the gateway server 501.

[0134] Alternatively, a technician can access the distributed coordination system 503 through a scheduler on a terminal, thereby controlling the back-end distributed coordination system 503 based on the front-end scheduler to manage each cluster or server. For example, a technician can use the scheduler to control ZooKeeper to delete a data node device from the distributed storage cluster 502, thereby making the data node device invalid.

[0135] The distributed storage cluster 502 includes multiple data node devices, and the data will be horizontally divided into multiple data partitions. Each data partition contains a specific number of data items and is distributed on each data node device according to certain rules (such as hash partitioning). Each data partition will correspond to a replica group, which contains multiple data replicas. There is only one master replica in the replica group. The coordination node device will send all data requests involving the data partition to the master replica. At the same time, the remaining replicas in the replica group except the master replica are all slave replicas. The number of slave replicas can be one or more. The master and slave replicas use a replica synchronization mechanism (generally using a consensus protocol, such as Paxos, Raft and other consistency protocols) to keep data synchronized between the slave replicas and the master replica.

[0136] Schematically, each replica group includes a master replica and multiple slave replicas, such as Figure 1As shown, a replica group including a master replica and two slave replicas is used as an example for illustration. The data node device where the master replica is located can be called a master, and the data node device where the slave replica is located can be called a standby. Each master or standby is configured with an agent device. The agent device can be physically independent of the master or standby. Of course, the agent device can also serve as an agent module on the master or standby. Taking replica group 1 of data partition 1 as an example, replica group 1 includes a master database and agent device (master database + agent, referred to as master DB + agent), and also includes two standby databases and agent devices (standby database + agent, referred to as standby DB + agent).

[0137] In an exemplary scenario, the set of database instances on the master or standby machines corresponding to each replica group is called a SET. For example, assuming a replica group adopts a one-master-two-standby cluster architecture, the SET of the replica group is the set of the master database instance and the two standby database instances. In this case, consistency protocols such as Paxos and Raft can be used to ensure consistency between the master data and the replica data on the standby machines. Optionally, each SET can be linearly expanded to meet business processing requirements in big data scenarios. In some financial business scenarios, global transactions usually refer to cross-SET transfers.

[0138] above Figure 5 The provided distributed database system can be viewed as jointly maintaining a single logically large table. The data stored in this large table is distributed by primary key across replica groups corresponding to each data partition in the distributed storage cluster 502. The data partitions stored in each replica group are independent of those in other replica groups, thereby achieving horizontal partitioning of the logically large table. Because the system can horizontally partition each data table in each database for distributed storage, it can also be figuratively described as having a "sharded database and table" architecture.

[0139] This sharded database and table architecture is a common architecture for distributed databases. It is widely used in scenarios such as finance and the Internet, and has a huge industrial impact. If there are distributed transactions across nodes, the distributed database system can also support them through technologies such as the two-phase commit algorithm, ensuring the atomicity and consistency of data during write operations.

[0140] In some embodiments, the distributed database system composed of the above-mentioned gateway server 501, distributed storage cluster 502 and distributed coordination system 503 can be regarded as a server that provides data services to user terminals. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0141] The terminal used on the user side and the above-mentioned server can be directly or indirectly connected through wired or wireless communication, and this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc., which are not limited in this application.

[0142] The following is a brief introduction to the replica synchronization mechanism of the embodiment of the present application.

[0143] The transaction processing method involved in the embodiments of the present application can be applied to various distributed database systems with similar architectures of sharded libraries and tables. Applying this method on the product side can improve the transaction processing performance of distributed database products to meet the stringent requirements of current Internet applications on database performance. High-performance transaction capabilities are particularly important for improving product competitiveness.

[0144] Figure 6 This is a flow chart of a transaction processing method provided by an embodiment of the present application. Figure 6 This embodiment is executed by a coordination node device of a distributed database system and includes the following steps:

[0145] 601. The coordinating node device determines the primary and replica node devices corresponding to the database operations executed in the target transaction.

[0146] The coordination node device is a node device located at the coordination layer in the distributed database system. The coordination node device is responsible for independently coordinating transactions and returning transaction execution results to the application client on the terminal side.

[0147] Among them, the target transaction is obtained based on the parsing of the data request, which includes a DDL (Data Definition Language) request and a DML (Data Manipulate Language) request. The DML request refers to a business request. For example, a query request is a typical business request. In the financial scenario, the query request is to query the balance, query the flow, etc. In the smart transportation scenario, the query request is to query nearby available parking spaces, query the road conditions near the destination, etc. The embodiment of the present application does not specifically limit the content of the data request.

[0148] In some embodiments, the data request is a request sent by a user to a distributed database system through an application client on a terminal. Schematically, the user logs in to the application client on the terminal, triggering the application client to generate the data request and calling the MySQL API to send the data request to the distributed database system.

[0149] In some embodiments, after receiving any request, the coordination node device parses the header field of the request. When the header field indicates that the request is a data request, the coordination node device parses the data field of the data request to obtain the SQL statement of the target transaction corresponding to the data request (or, the data request may also be a NoSQL request, in which case the parsed result is typically an access to a data structure of a key-value pair). SQL is abbreviated as Structured Query Language in English and Structured Query Language in Chinese.

[0150] Optionally, the coordination node device can directly receive data requests from the application client side, or the coordination node device receives data requests forwarded by the gateway server, and the gateway server acts as a transit between the application client and the coordination node device. For example, the gateway server randomly forwards the new data request to any coordination node device in the distributed coordination system, or the gateway server forwards the data request to the coordination node device with lower load in the distributed coordination system to better achieve system load balancing. The embodiments of the present application do not specifically limit this.

[0151] In some embodiments, after the coordinating node device parses the data request to obtain the SQL statement of the target transaction, it determines at least one data item operated by the target transaction. The data item involved in the embodiments of the present application refers to a row of data records in a data table (also called a tuple), which stores the instantiation information of all data columns in the definition of the data table (i.e., the field data corresponding to each data column) and is arranged in the order of the data column definitions to form a continuous content. The "operation" of the target transaction on the data record refers to a database operation, and the operation types of database operations include read operations and write operations, which are collectively referred to as read and write operations.

[0152] Since the target transaction is usually composed of a sequence of database operations, that is, the target transaction may involve multiple database operations, these database operations may also point to the same or different data items, and in a distributed database system, different data items may also be located in different data partitions, and different data partitions each correspond to different master and replica node devices, which may lead to the possibility of involving cross-node operations. The embodiments of the present application involve the processing flow and replica synchronization mechanism of distributed transactions for cross-node operations.

[0153] In some embodiments, for any data item involved in executing database operations in the target transaction, the data partition to which the data item belongs is determined, and then, based on the partition information table, the master-replica node device corresponding to the data partition is queried, wherein the partition information table is used to record the correspondence between the data partition and the master-replica node device. The above operation is performed on each data item involved in the operation of the target transaction, and at least one master-replica node device corresponding to at least one data item can be determined.

[0154] 602. The coordinating node device distributes the sub-transactions of the target transaction on the primary and replica node devices to the primary and replica node devices.

[0155] In some embodiments, for at least one master replica node device determined in step 601 above, the coordinating node device decomposes the target transaction into respective sub-transactions on at least one master replica node device. For example, for any master replica node device, based on the data items operated by the target transaction on the data partition corresponding to the master replica node device and the corresponding database operations, the sub-transactions on the master replica node device are determined. In one example, the target transaction involves writing data item X1 and writing data item Y1. Data item X belongs to data partition 1, and data item Y belongs to data partition 2. Then, for the master replica node device 1 of data partition 1, the sub-transaction decomposed onto the master replica node device 1 is writing data item X1 (i.e., updating data item X from version X0 to version X1). For the master replica node device 2 of data partition 2, the sub-transaction decomposed onto the master replica node device 2 is writing data item Y1 (i.e., updating data item Y from version Y0 to Y1).

[0156] In some embodiments, for any master-replica node device, the coordinating node device sends a database operation sequence carrying the corresponding sub-transaction to the master-replica node device, thereby distributing the sub-transaction to the master-replica node device, so that when the master-replica node device receives the distributed sub-transaction, it executes the database operation corresponding to each data item of the sub-transaction according to the database operation sequence of the distributed sub-transaction.

[0157] In an example, for the above-mentioned master-replica node device 1, the sub-transaction that is disassembled is the write data item X1. The database operation sequence of this sub-transaction is {(Write, X1)}, so the database operation sequence {(Write, X1)} of the corresponding sub-transaction is sent to the master-replica node device 1. Similarly, the database operation sequence {(Write, Y1)} of the corresponding sub-transaction is sent to the master-replica node device 2.

[0158] 603. The coordinating node device sends a prepare request to the primary and replica node devices. The prepare request is used to instruct the primary and replica node devices to perform data anomaly detection on the sub-transaction.

[0159] In some embodiments, after receiving the distributed sub-transaction, each master-replica node device will execute the database operations corresponding to each data item of the sub-transaction based on the database operation sequence of the sub-transaction. After the sub-transaction is executed, the master-replica node device returns the sub-transaction execution result to the coordination node device.

[0160] Since the same target transaction can be broken down into multiple sub-transactions, different sub-transactions usually correspond to different master-replica node devices. Therefore, the coordination node device receives the sub-transaction execution results returned by each master-replica node device. If the sub-transaction execution results of all sub-transactions of the target transaction are received, it means that the preparation phase of the two-phase commit algorithm can be entered. Therefore, the coordination node device sends a preparation request to each master-replica node device. The preparation request is used to instruct the master-replica node device to locally start data anomaly detection for the sub-transaction, obtain the anomaly detection result, and return a preparation completion response corresponding to the obtained anomaly detection result to the coordination node device.

[0161] Schematically, under the OCC mechanism, after receiving the prepare request, the master replica node device locks the data items in the local write set of the sub-transaction (i.e., applies for a write lock), and then verifies the data items in the local read set of the sub-transaction to determine whether the data items have been modified by other transactions. If the data items have been modified by other transactions, the target transaction corresponding to the sub-transaction needs to be rolled back, and the anomaly detection result is set to an exception exists, and a prepare completion response indicating that the preparation failed is returned. If the data item has not been modified by other transactions, the next data item is detected. After traversing all data items in the read set, if all data items have not been modified by other transactions, the anomaly detection result is set to no exception exists, and a prepare completion response indicating that the preparation is successful is returned.

[0162] 604. When the transaction commit conditions are met, the coordinating node device sends a commit request to the master replica node device. The commit request is used to instruct the master replica node device to commit the sub-transaction and send the redo log of the sub-transaction to the corresponding slave replica node device.

[0163] In some embodiments, after receiving the prepare request, each master replica node device will perform data anomaly detection on the sub-transaction, obtain an anomaly detection result, and return a prepare completion response corresponding to the anomaly detection result to the coordination node device. This prepare completion response can indicate that the preparation is successful or failed on the master replica node device. If the anomaly detection result is that there is no anomaly, then a prepare completion response indicating that the preparation is successful is returned. If the anomaly detection result is that there is an anomaly, then a prepare completion response indicating that the preparation has failed is returned.

[0164] In some embodiments, after the coordinating node device receives the prepare completion responses returned by all the master and replica node devices corresponding to the target transaction, if all prepare completion responses indicate successful preparation, it is determined that the transaction commit conditions are met; otherwise, if any prepare completion response indicates a preparation failure, it is determined that the transaction rollback conditions are met.

[0165] In some embodiments, in order to avoid a master replica node device failing to return a preparation completion response for a long time, causing the coordination node device to be in a state of waiting for a preparation completion response, the technician pre-sets a timeout threshold. The coordination node device starts timing after sending a preparation request to each master replica node device. When the timing does not exceed the timeout threshold, it waits for the preparation completion response returned by each master replica node device. When the timing reaches the timeout threshold, it stops waiting. If the preparation completion response returned by all master replica node devices is received at this time, and all preparation completion responses indicate that the preparation is successful, it is determined that the transaction commit condition is met; otherwise, if any master replica node device does not return a preparation completion response (i.e., the waiting timeout), or the preparation completion response returned by any received master replica node device indicates that the preparation failed, it is determined that the transaction rollback condition is met. Among them, the timeout threshold is any value greater than 0, such as a timeout threshold of 3 seconds, 5 seconds, 10 seconds, etc. The embodiment of the present application does not specifically limit the timeout threshold.

[0166] In some embodiments, when the transaction commit conditions are met, the coordinating node device sends a commit request to each master replica node device. This commit request is used to instruct each master replica node device to commit the corresponding sub-transaction locally to achieve local data storage. At the same time, to ensure data consistency between the master and slave replicas, the commit request is also used to instruct each master replica node device to send the redo log (Redo Log) of the sub-transaction to each slave replica node device of the replica group to which it belongs, so that each slave replica node device can asynchronously replay the redo log of the sub-transaction after receiving the redo log of the sub-transaction, thereby replaying the database operations on each data item involved in the sub-transaction on the slave replica node device, and ensuring that the data versions between the master and slave replicas remain consistent after the replay is completed.

[0167] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0168] The method provided by the embodiment of the present application distributes sub-transactions to the master and slave node devices in a distributed database system. Then, in the preparation phase of the two-phase commit algorithm, the coordinating node device issues a preparation request, which only instructs the master and slave node devices to perform data anomaly detection but does not require data synchronization between the master and slave replicas. After the transaction commit conditions are met and the commit phase is entered, the coordinating node device issues a commit request, which instructs the master and slave node devices to locally commit the sub-transactions and synchronize the redo logs to the slave replica node devices. Therefore, only one round of communication is required in the commit phase to achieve data consistency between the master and slave replicas, thereby greatly reducing the number of synchronizations between the master and slave replicas in the system, compressing the replica synchronization overhead under the multi-replica mechanism, and thus minimizing the adverse effects of the multi-replica mechanism on the transaction processing performance in the system.

[0169] In the previous embodiment, we briefly introduced the lightweight transaction-granularity replica synchronization mechanism of this application. This mechanism ensures that each transaction, when replica synchronization is required, requires at most one network communication round, minimizing the cost of replica synchronization. Next, we will introduce how the coordinator node device and the data node device communicate and interact to implement this lightweight transaction-granularity replica synchronization mechanism, by combining the construction of a coordinator node group (CoordinatorGroup) in a distributed database system.

[0170] Figure 7 This is an interactive flow chart of a transaction processing method provided by an embodiment of the present application, such as Figure 7 As shown, this embodiment is applicable to a distributed database system and is implemented by interaction between the coordination node device in the coordination layer and the data node device in the storage layer, as described below:

[0171] 701. The coordinating node device determines the primary and replica node devices corresponding to each database operation executed in the target transaction.

[0172] In an embodiment of the present application, the concept of a coordination node group is introduced. In a distributed coordination system of a distributed database system, multiple coordination node groups are involved, and each coordination node group is composed of several (two or more) coordination node devices.

[0173] For external data requests, the gateway server randomly forwards the data request to any coordination node device in any coordination node group to simplify the request processing logic, or the gateway server randomly forwards the data request to the coordination node device with the lowest load in any coordination node group to balance the load within the system, or the gateway server forwards the data request to any coordination node device in the coordination node group with the lowest total load to balance the load within the system, or the gateway server forwards the data request to the coordination node device with the lowest load in the coordination node group with the lowest total load to balance the load within the system. The embodiments of the present application do not specifically limit this.

[0174] The coordinating node device involved in the embodiments of the present application refers to a node device in a coordinating node group that is responsible for processing target transactions. The coordinating node devices other than the coordinating node device in the coordinating node group are referred to as other coordinating node devices.

[0175] The target transaction involved in the embodiment of the present application refers to any transaction processed by a distributed database system. This transaction can be a read transaction or a write transaction, and can be a stand-alone transaction or a distributed transaction. Since stand-alone transactions do not involve the use of a two-phase commit algorithm for submission, distributed transactions are used as an example for illustration here.

[0176] In some embodiments, after receiving a data request, the coordinating node device parses the data request to obtain the SQL statement of the target transaction, then creates the target transaction, applies for the transaction start timestamp of the target transaction, and initializes the context information of the target transaction in the memory. The context information is used to store information that needs to be maintained during the transaction operation.

[0177] In some embodiments, after the context information of the target transaction is initialized, the database operation sequence of the target transaction is determined based on the SQL statement of the target transaction. The database operation sequence is used to indicate which data items the target transaction is to perform which type of database operations on. Database operations can be divided into read operations or write operations. Since the target transaction may involve performing the same or different database operations on different data items, and different data items may belong to different data partitions, and different data partitions correspond to different master-replica node devices, the coordinating node device needs to decompose the target transaction into sub-transactions corresponding to different master-replica node devices.

[0178] In some embodiments, the coordinating node device first determines at least one data item involved in the database operation performed by the target transaction. Next, for each data item involved in the database operation performed by the target transaction, the coordinating node device determines the data partition to which the data item belongs. Next, based on a partition information table, the coordinating node device corresponding to the data partition is queried, where the partition information table records the correspondence between data partitions and primary and secondary node devices. By performing the above operations for each data item involved in the target transaction, at least one primary and secondary node device corresponding to each data item can be determined.

[0179] 702. The coordinating node device distributes the sub-transactions of the target transaction on the master and replica node devices to each master and replica node device.

[0180] In some embodiments, the process of determining the master replica node device in the above step 701 can also be regarded as a process of decomposing the target transaction into sub-transactions corresponding to different master replica node devices. For example, based on the SQL statement of the target transaction, at least one data item involved in executing the database operation of the target transaction is determined. Then, for each data item, the data partition to which the data item belongs is determined. Then, based on the partition information table, the master replica node device corresponding to the data partition is queried, and a database operation sequence of a sub-transaction is created for the master replica node device. The current data item and the corresponding database operation are added to the database operation sequence of the sub-transaction. The above operation is repeated. After the SQL of the target transaction is parsed, a database operation sequence corresponding to the sub-transaction can be generated for each master replica node device. For example, the SQL statement of the target transaction indicates that data items X1 and Y1 are to be written, and data item Z1 is to be read at the same time. Assuming that data items X1 and Z1 both belong to data partition 1, and Y1 belongs to data partition 2, when disassembling the sub-transaction, in the partition information table, the master replica node device 1 of data partition 1 to which data item X1 belongs is found, and the database operation sequence {(Write, X1)} of sub-transaction 1 is created for the master replica node device 1. The master replica node device 2 of data partition 2 to which data item Y1 belongs is found, and the database operation sequence {(Write, Y1)} of sub-transaction 2 is created for the master replica node device 2. At the same time, it is found that the data partition 1 to which data item Z1 belongs still corresponds to the master replica node device 1, so the database operation sequence of sub-transaction 1 is updated to {(Write, X1), (Read, Z1)}.

[0181] In some embodiments, based on the SQL statement of the target transaction, it is determined which data items in which data partitions the target transaction involves operating. Then, for each data partition, it is determined that the target transaction involves performing corresponding database operations on each data item of the data partition. Then, the master and replica node devices of the data partition are queried from the partition information table, and the above-determined information is added to the database operation sequence of the sub-transaction of the current master and replica node device. The process of disassembling the sub-transaction on the current master and replica node device is completed. This process is repeated until all data items involved in performing database operations on the target transaction have been added to the database operation sequence of the corresponding sub-transaction. At this time, the target transaction is disassembled and the corresponding sub-transactions are distributed to each master and replica node device (that is, the database operation sequence of the corresponding sub-transaction is issued).

[0182] In other words, when decomposing sub-transactions, for the same master-replica node device, determine which data items in the data partition corresponding to the master-replica node device need to perform which type of database operations. The determined result represents the database operation sequence of the sub-transactions that need to be executed on the master-replica node device. Optionally, the coordinating node device distributes the database operation sequence of the corresponding sub-transaction to each master-replica node device, which is equivalent to distributing the sub-transactions decomposed from the target transaction.

[0183] 703. The master-replica node device responds to the sub-transaction of the target transaction on the master-replica node device, executes the database operation corresponding to the sub-transaction, and returns the sub-transaction execution result to the coordination node device.

[0184] In some embodiments, after the master-replica node device receives the sub-transaction distributed by the coordinating node device (i.e., the database operation sequence of the sub-transaction), it performs corresponding database operations on each data item in the database operation sequence in serial or parallel based on the database operation sequence of the sub-transaction. For example, assuming that the database operation sequence of the received sub-transaction is {(Write, X1), (Read, Z1)}, the master-replica node device needs to modify the data item X from version X0 to version X1, and also needs to read the data item Z1. Writing the data item X1 and reading the data item Z1 can be serial operations or parallel operations, and the embodiments of the present application do not specifically limit this.

[0185] In some embodiments, after traversing the database operation sequence of the sub-transaction, it represents that the master-replica node device has completed the execution of the sub-transaction, and at this time the sub-transaction execution result is returned to the coordination node device. If the corresponding database operations are successfully executed on all data items in the database operation sequence of the sub-transaction, the returned sub-transaction execution result indicates a successful execution. If the corresponding database operation cannot be executed on any data item in the database operation sequence of the sub-transaction due to some failure, the returned sub-transaction execution result indicates a failed execution.

[0186] 704. The coordinating node device adds an operation record of the database operation executed by the sub-transaction to the operation log list in response to the sub-transaction execution result returned by any master and replica node device.

[0187] The operation log list involved in the embodiment of the present application is also called an operation log, an operation record table, etc. The operation log list is a memory linked list structure ops stored in the context information of the target transaction. The operation log list is used to temporarily store in the coordination node device which database operations are to be performed on which data items of the target transaction. At the same time, the coordination node device will also asynchronously send the operation log list to at least one other coordination node device in the coordination node group, so that other coordination node devices can also temporarily store the operation log list, so that when the coordination node device fails, other coordination node devices can promptly take over the transactions originally responsible for coordination on the coordination node device, and continue to coordinate the originally blocked transactions according to the operation log list corresponding to the transactions. The fault recovery mechanism will be described in detail in the next embodiment and will not be elaborated here.

[0188] Schematically, the operation log list is a memory linked list structure ops maintained in the context information of the target transaction, which is used to maintain the database operations executed in the target transaction on the coordination node device. For example, each linked list node in the memory linked list structure ops represents a database operation op=<type,data> , a database operation consists of two fields: the type field, which is the operation type field, for example, it contains four operation types, namely read (Read), write (Write), prepare (Prepare) and commit (Commit); the data field, which is the operation data item field, represents the operation object of the database operation. In an example, assuming that the target transaction involves writing data items X1 and Y1, then the operation log list ops = {<Write,X1> ,<Write,Y1> In another example, suppose the target transaction wants to read data item Z, and when executing the Read(Z) operation, it reads version Z0. Then the operation record stored in ops for this Read(Z) operation is<Read,Z0> .

[0189] It should be noted that, when the type field is a write operation, the data field is the new value to be written by the target transaction; when the type field is a read operation, the data field is the data version read by the read operation (that is, the latest visible version of the data item); when the type field is prepare or commit, when the prepare or commit operation is not completed, the data field value is Null, indicating that it is waiting for the response from each master and replica node device. When the prepare or commit operation is successful, the data field value is True. When the prepare or commit operation fails (at this time, the target transaction needs to be rolled back), the data field value is False.

[0190] In some embodiments, the coordinating node device creates and stores an operation log list for the target transaction within the context information of the target transaction. The operation log list includes operation records for the database operations currently executed by the target transaction, with each operation record identifying the operation type and data items involved in the operation. Subsequently, whenever a sub-transaction execution result is received from any master-replica node device, if the sub-transaction execution result indicates successful execution, the operation record for the database operation executed by the sub-transaction is added to the operation log list.

[0191] In some embodiments, due to the introduction of the concept of a coordination node group, in other words, in the distributed database system, the coordination node device and at least one other coordination node device constitute a coordination node group. In order to avoid collectively redoing all transactions that the coordination node device was originally responsible for coordinating after the coordination node device fails, the coordination node device can send a stored operation log list of at least one transaction to the at least one other coordination node device in the coordination node group at intervals of the first target duration. In other words, at intervals of the first target duration, each coordination node device in the coordination node group synchronizes the operation log list with each other. Wherein, the first target duration is any value greater than 0, for example, the first target duration is 10 seconds, 20 seconds, 30, etc. The embodiment of the present application does not specifically limit the first target duration. In this way, when the coordination node device fails, other coordination node devices in the same coordination node group can use the operation log list that has been synchronized by the coordination node device to continue to coordinate the corresponding transactions, or, when any other coordination node device in the same coordination node group fails, the coordination node device can use the operation log list that has been synchronized by the failed coordination node device to continue to coordinate the corresponding transactions. The relevant fault recovery process will be introduced in detail in the subsequent embodiments and will not be explained here.

[0192] 705 . After adding all operation records of the subtransactions of the target transaction to the operation log list, the coordinating node device sends the operation log list to at least one other coordinating node device in the coordinating node group to which it belongs.

[0193] In some embodiments, after receiving the sub-transaction execution results returned by all master and replica node devices, if all sub-transaction execution results indicate successful execution, the coordinating node device will add the operation records of all sub-transactions to the operation log list under the processing logic of the above step 704. At this time, the operation log list contains the operation records of all database operations involved in the execution of the target transaction, that is, at this time, all database operations involved in the execution of the target transaction have been temporarily stored on the coordinating node device. Then, the coordinating node device synchronizes the operation log list to at least one other coordinating node device in the same coordinating node group. When synchronizing the operation log list, when it is detected that the operation log list contains the operation records of all sub-transactions, the operation log list can be immediately synchronized to at least one other coordinating node device in the same coordinating node group, so that the preparation phase of the two-phase commit algorithm can be quickly entered. Alternatively, according to the timed synchronization mechanism, the operation log list of at least one transaction currently stored, including the target transaction, is synchronized once every first target time interval, so that the operation log list can be asynchronously synchronized, so that the operation log list of the target transaction is also temporarily stored on other coordinating node devices.

[0194] 706. When the operation log list has been synchronized to any other coordination node device, the coordination node device sends a preparation request to each master and replica node device. The preparation request is used to instruct the master and replica node device to perform data anomaly detection on the corresponding sub-transaction.

[0195] In some embodiments, before entering the preparation phase of the two-phase commit algorithm, it is necessary to first confirm that the operation log list of the target transaction has been temporarily stored on at least one other coordination node device in the coordination node group to which it belongs. In other words, when the operation log list has been synchronized to any other coordination node device in the coordination node group to which it belongs, the target transaction enters the preparation node of the two-phase commit algorithm, and the coordination node device sends a preparation request to each master and replica node device.

[0196] In some embodiments, as can be seen from the introduction of the operation log list ops in step 704 above, the type field of each operation record not only provides two actual operation types of reading (Read) and writing (Write) of the data item, but also provides two operation types of prepare (Prepare) and commit (Commit) that describe which stage of the two-phase commit algorithm the transaction is in. Therefore, an operation record with the type field value of prepare (Prepare) can be called a prepare operation record, and an operation record with the type field value of commit (Commit) can be called a commit operation record. In other words, the operation log list is also used to store at least one of the prepare operation record or commit operation record of the target transaction.

[0197] Optionally, the preparation operation record of the target transaction is used to record the status of the target transaction in the preparation stage. For example, when the type field value is Prepare, the data field value is Null, which means that the system is waiting for each master and replica node device to return a preparation completion response. The data field value is True, which means that the preparation is successful. The data field value is False, which means that the preparation has failed.

[0198] Optionally, the commit operation record of the target transaction is used to record the status of the commit phase of the target transaction. For example, when the type field is Commit, the data field is Null, which means that the system is waiting for each master and replica node device to return a commit completion response. The data field is True, which means that the commit is successful. The data field is False, which means that the commit failed.

[0199] In some embodiments, after the coordination node device sends a prepare request to each master and replica node device, it inserts a prepare operation record into the operation log list of the target transaction.<Prepare,Null> , indicating that the preparation request has been sent, but the preparation completion response returned by all master and replica node devices has not yet been received.

[0200] 707. The master and replica node devices respond to the prepare request of the target transaction, perform data anomaly detection on the sub-transaction corresponding to the master and replica node devices, and obtain an anomaly detection result.

[0201] In some embodiments, after receiving a preparation request for a target transaction, any master-replica node device starts data anomaly detection for the sub-transaction of the target transaction on the master-replica node device, that is, detects whether there is a data conflict between the sub-transaction and the concurrent transaction, and obtains the anomaly detection result of the sub-transaction.

[0202] Schematically, under the OCC mechanism, after receiving the prepare request, the master-replica node device locks the data items in the local write set of the sub-transaction (i.e., applies for a write lock), and then verifies the data items in the local read set of the sub-transaction to determine whether the data items have been modified by other transactions. If the data items have been modified by other transactions, the target transaction corresponding to the sub-transaction needs to be rolled back, and the anomaly detection result is set to an anomaly exists. If the data item has not been modified by other transactions, continue to detect the next data item. After traversing all data items in the read set, if all data items have not been modified by other transactions, the anomaly detection result is set to no anomaly exists.

[0203] 708. The master and replica node devices return a preparation completion response corresponding to the abnormality detection result to the coordination node device.

[0204] In some embodiments, when the abnormality detection result is that an abnormality exists, the master replica node device returns a preparation completion response indicating that the preparation failed to the coordination node device, for example, the preparation completion response indicating that the preparation failed is a string of error codes; when the abnormality detection result is that there is no abnormality, the master replica node device returns a preparation completion response indicating that the preparation is successful to the coordination node device, for example, the preparation completion response indicating that the preparation is successful is an ACK (Acknowledge Character) message.

[0205] In other embodiments, the master-replica node device directly returns the abnormality detection result as a preparation completion response to the coordination node device, and the coordination node device determines whether the preparation is successful or failed based on the abnormality detection result. The content of the preparation completion response in the embodiment of the present application is not specifically limited.

[0206] 709. The coordinating node device receives the preparation completion response from each master and replica node device. When each preparation completion response indicates that the preparation is successful, it is determined that the transaction commit condition is met.

[0207] In some embodiments, after the coordinating node device receives the prepare completion responses returned by all the master and replica node devices corresponding to the target transaction, if all prepare completion responses indicate successful preparation, it is determined that the transaction commit conditions are met and the process proceeds to the following step 710; otherwise, if any prepare completion response indicates a preparation failure, it is determined that the transaction rollback conditions are met and a rollback instruction for the target transaction is sent to each master and replica node device.

[0208] In some embodiments, after the coordination node device receives the exception detection results returned by all master and replica node devices corresponding to the target transaction, if all the exception detection results indicate that there is no exception, it is determined that the transaction commit conditions are met and the process proceeds to the following step 710; otherwise, if any of the exception detection results indicates that there is an exception, it is determined that the transaction rollback conditions are met and a rollback instruction for the target transaction is sent to each master and replica node device.

[0209] In some embodiments, in order to avoid a master replica node device from failing to return a preparation completion response, causing the coordination node device to be in a state of waiting for a preparation completion response, the technician pre-sets a timeout threshold. The coordination node device starts timing after sending a preparation request to each master replica node device. When the timing does not exceed the timeout threshold, it waits for the preparation completion response returned by each master replica node device. When the timing reaches the timeout threshold, it stops waiting. If the preparation completion response returned by all master replica node devices is received at this time, and all preparation completion responses indicate that the preparation is successful, it is determined that the transaction commit condition is met and the following step 710 is entered; otherwise, if any master replica node device does not return a preparation completion response (i.e., the waiting timeout), or the preparation completion response returned by any received master replica node device indicates that the preparation failed, it is determined that the transaction rollback condition is met and a rollback instruction of the target transaction is sent to each master replica node device. Wherein, the timeout threshold is any value greater than 0, such as a timeout threshold of 3 seconds, 5 seconds, 10 seconds, etc. The embodiment of the present application does not specifically limit the timeout threshold.

[0210] In some embodiments, the coordinating node device starts timing after sending a prepare request to each master replica node device. When the timing does not exceed the timeout threshold, it waits for the exception detection results returned by each master replica node device. When the timing reaches the timeout threshold, it stops waiting. If the exception detection results returned by all master replica node devices are received at this time, and all exception detection results indicate that there is no exception, it is determined that the transaction commit condition is met and enters the following step 710; otherwise, if any master replica node device does not return an exception detection result (that is, the waiting timeout), or the exception detection result returned by any master replica node device received indicates that there is an exception, it is determined that the transaction rollback condition is met, and a rollback instruction for the target transaction is sent to each master replica node device.

[0211] 710. When the transaction commit conditions are met, the coordinating node device sends a commit request to each master replica node device. The commit request is used to instruct the master replica node device to commit the sub-transaction and send the redo log of the sub-transaction to the corresponding slave replica node device.

[0212] In some embodiments, when the transaction commit conditions are met, the coordinating node device sends a commit request to each master replica node device. This commit request is used to instruct each master replica node device to commit the corresponding sub-transaction locally to achieve local data storage. At the same time, to ensure data consistency between the master and slave replicas, the commit request is also used to instruct each master replica node device to send the redo log (Redo Log) of the sub-transaction to each slave replica node device of the replica group to which it belongs, so that each slave replica node device can asynchronously replay the redo log of the sub-transaction after receiving the redo log of the sub-transaction, thereby replaying the database operations on each data item involved in the sub-transaction on the slave replica node device, and ensuring that the data versions between the master and slave replicas remain consistent after the replay is completed.

[0213] In some embodiments, after the coordination node device sends a commit request to each master and replica node device, it inserts a commit operation record into the operation log list of the target transaction.<Commit,Null> , indicating that the commit request has been sent, but the commit completion response returned by all master and replica node devices has not yet been received.

[0214] 711. The master and replica node devices submit the sub-transaction in response to the commit request of the target transaction.

[0215] In some embodiments, after receiving a commit request sent by a coordinating node device, any master replica node device locally commits the sub-transaction of the target transaction on the master replica node device, writes the data item modifications made by the sub-transaction to disk, and simultaneously locally releases the memory occupied by the read set and write set of the sub-transaction. At this time, the information maintained for concurrency control of the sub-transaction (such as the applied lock resources) is also released.

[0216] 712. The master replica node device sends the redo log of the sub-transaction to the corresponding slave replica node device, so that the slave replica node device redoes the sub-transaction when replaying the redo log.

[0217] In some embodiments, after receiving the commit request, the master replica node device, in addition to executing the above-mentioned step 711 to commit the sub-transaction, also needs to send the redo log of the sub-transaction to at least one corresponding slave replica node device. For example, based on the partition information table, it queries which slave replica node devices are in the replica group of the data partition corresponding to the master replica node device, and sends the redo log of the sub-transaction to each slave replica node device obtained from the query, so as to achieve the replica synchronization operation between the master replica node device and the slave replica node devices. After receiving the redo log of the sub-transaction sent by the master replica node device, the slave replica node device will replay the redo log locally, thereby synchronizing the data item modifications made by the sub-transaction to the local area, and ensuring data consistency between the master and slave replicas.

[0218] In some embodiments, the redo log of a subtransaction mainly includes the data items to be written by the subtransaction this time. The redo log is played back on the replica through physical replication. Physical replication means that the smallest unit transmitted in the data stream is a physical data block or a physical log block. Physical data blocks store physical data records, and physical log blocks store physical log records. Physical replication is performed based on physical data blocks or physical log blocks.

[0219] In an embodiment of the present application, a lightweight transaction-granularity replica synchronization mechanism is proposed. In the transaction execution phase, the two-phase commit algorithm is still followed. The atomicity of transaction commit is guaranteed through the two phases of the preparation phase and the commit phase. According to the framework of the distributed database system introduced earlier, each data partition corresponds to a replica group, including a master replica (Leader) and multiple slave replicas (Followers). In the embodiment of the present application, only when any target transaction enters the commit phase, the master replica packages the redo log of the local sub-transaction of the target transaction (equivalent to the data items written by the sub-transaction) to be synchronized to the slave replica. It can be seen that if the target transaction operates on data items on multiple data partitions, the master replica of each data partition will send the redo log of the local sub-transaction (equivalent to the data items written by the sub-transaction on the corresponding data partition) to the corresponding slave replica. Since data synchronization between replicas is achieved by transferring redo logs, when each target transaction is committed, a redo log of the local sub-transaction will be generated on the master replica of each data partition. The structure of the redo log mainly includes the new value to be written by the sub-transaction.

[0220] Next, we introduce the communication process of the two-phase algorithm of the lightweight transaction-granularity replica synchronization mechanism. Figure 8This is a principle flow chart of a lightweight transaction granularity replica synchronization mechanism provided by an embodiment of the present application. As shown in 800, assuming that the coordination node device of the target transaction is C1, the coordination node group to which the coordination node device C1 belongs also includes other coordination node devices C2, assuming that the target transaction involves operating data items in data partitions 1 and 2, where data partition 1 includes a master replica P1 and a slave replica P1', and data partition 2 includes a master replica P2 and a slave replica P2', then after all sub-transactions of the target transaction are executed and before the target transaction enters the preparation stage, the coordination node device C1 The operation log list ops of the target transaction will be sent to the other coordination node device C2 for temporary storage, and then enter the preparation phase of the two-phase commit algorithm. The coordination node device C1 sends a prepare request to the master replicas P1 and P2 of the data partitions where all data items involved in the target transaction are located. It should be noted that the master replicas P1 and P2 only need to perform data anomaly detection on the corresponding sub-transactions locally, and do not need to generate any replica synchronization with their respective slave replicas P1' and P2'. The master replicas P1 and P2 each return a prepare completion response to the coordination node device C1 after completing the data anomaly detection. After the coordination node device C1 receives the prepare completion response returned by the master replicas P1 and P2 of all data partitions, assuming that all master replicas P1 and P2 return prepare success, it enters the commit phase of the two-phase commit algorithm; otherwise, if any master replica P1 or P2 returns prepare failure, the target transaction will be rolled back. Then, in the commit phase of the target transaction, the coordinating node device C1 sends a commit request to the primary replicas P1 and P2 of the data partitions where all data items involved in the target transaction are located. The primary replica P1 will commit the corresponding sub-transaction locally, and package the redo log of the corresponding sub-transaction and send it to the slave replica P1', and return a commit completion response to the coordinating node device C1. Similarly, the primary replica P2 will commit the corresponding sub-transaction locally, and package the redo log of the corresponding sub-transaction and send it to the slave replica P2', and return a commit completion response to the coordinating node device C1. After the coordinating node device C1 receives the commit completion responses returned by the primary replicas P1 and P2 of all data partitions, if all primary replicas P1 and P2 return commit success, the transaction commit is completed.

[0221] Next, we will introduce the replica synchronization principle of the lightweight transaction-granularity replica synchronization mechanism. Figure 9 This is a schematic diagram of the principle of a lightweight transaction granularity replica synchronization mechanism provided by an embodiment of the present application, such as Figure 9As shown, under the lightweight transaction-granularity replica synchronization mechanism, assuming that transaction T1 involves writing (Write) data items X1 and Y1, the coordination node device 901 will send the write operation (such as writing data version X1) to the primary replica 911 of the data partition where X1 is located. The primary replica 911 locally modifies the data item X from version X0 to version X1. Before transaction T1 enters the preparation phase of the two-phase algorithm, the coordination node device 901 will package the operation log list ops of transaction T1 and send it to other coordination node devices 902 in the same coordination node group 900, so that the operation log list ops of transaction T1 will also be temporarily stored on other coordination node devices 902. Then, the coordination node device 901 sends a prepare request for transaction T1 to the primary replica 911 of the data partition where X1 is located and the primary replica 921 of the data partition where Y1 is located, so as to instruct the primary replicas 911 and 921 to perform data anomaly detection on the local sub-transactions of transaction T1 respectively and return corresponding prepare completion responses. When the transaction commit conditions of transaction T1 are met (i.e., all master replicas return a successful preparation and there are no data anomalies), the two-phase commit algorithm enters the commit phase. The coordination node device 901 sends a commit request for transaction T1 to master replicas 911 and 921. The master replica 911 commits the local sub-transaction of transaction T1, writes data item X1 to the disk, and packages the redo log of the sub-transaction (including the data item X1 written by transaction T1) and sends it to the slave replicas 912 and 913 in the replica group 910 of the data partition where it is located. Similarly, the master replica 921 also commits the local sub-transaction of transaction T1, writes data item Y1 to the disk, and packages the redo log of the sub-transaction (including the data item Y1 written by transaction T1) and sends it to the slave replicas 922 and 923 in the replica group 920 of the data partition where it is located. In this way, the data versions between the master and slave replicas can be kept consistent in each replica group while only maintaining the communication overhead of one round of replica synchronization in the commit phase.

[0222] In the embodiments of the present application, a lightweight, transaction-granular replica synchronization mechanism is proposed to improve the transaction processing performance of the entire distributed database system. The embodiments of the present application package the data items written by each transaction for replica synchronization only when each transaction is committed. This reduces the network overhead of replica synchronization for each transaction to one round, thereby minimizing the impact of replica synchronization on transaction performance.

[0223] It should be noted that after the target transaction is committed, the operation log list ops temporarily stored for the target transaction on each coordination node device in the coordination node group will also be released. That is, after the target transaction is committed, the context information of the target transaction will be released. Since the operation log list ops is also stored in the context information, the memory occupied by the operation log list ops will also be released along with the context information.

[0224] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0225] The method provided by the embodiment of the present application distributes sub-transactions to the master and slave node devices in a distributed database system. Then, in the preparation phase of the two-phase commit algorithm, the coordinating node device issues a preparation request, which only instructs the master and slave node devices to perform data anomaly detection but does not require data synchronization between the master and slave replicas. After the transaction commit conditions are met and the commit phase is entered, the coordinating node device issues a commit request, which instructs the master and slave node devices to locally commit the sub-transactions and synchronize the redo logs to the slave replica node devices. Therefore, only one round of communication is required in the commit phase to achieve data consistency between the master and slave replicas, thereby greatly reducing the number of synchronizations between the master and slave replicas in the system, compressing the replica synchronization overhead under the multi-replica mechanism, and thus minimizing the adverse effects of the multi-replica mechanism on the transaction processing performance in the system.

[0226] The lightweight, transaction-granular replica synchronization mechanism provided in the previous embodiment can also be considered a redo log-level replica synchronization mechanism. Transactions synchronize the redo log during the commit phase of the 2PC algorithm. It should be noted that this lightweight, transaction-granular replica synchronization mechanism is orthogonal to any concurrency control algorithm. This means that it can be organically combined with various concurrency control algorithms to ensure the correctness of transaction processing. For example, concurrency control algorithms include, but are not limited to, OCC (Optimistic Concurrency Control) and 2PL (Two-Phase Locking). The transaction processing process can be generally divided into three phases: the read-write phase, the prepare phase, and the commit phase. The following uses the combination of the lightweight, transaction-granular replica synchronization mechanism and the OCC concurrency control algorithm as an example to describe the transaction processing process when these two are combined.

[0227] Figure 10 This is a principle flow chart of a lightweight transaction-granularity replica synchronization mechanism combined with the OCC algorithm provided in an embodiment of the present application, as shown in 1000. Taking the target transaction as a distributed transaction as an example, it is assumed that the coordination node group includes coordination node devices C1 and C2, where the coordination node device C1 is responsible for coordinating the distributed transaction. At the same time, the distributed transaction involves operating two data partitions, and the replica group of data partition 1 includes the master replica P1 and the slave replica P1', and the replica group of data partition 2 includes the master replica P2 and the slave replica P2'.

[0228] Then, for any distributed transaction, in the read and write phase of the distributed transaction, the following process is executed in the system: the coordination node device C1 obtains the data node device corresponding to the read and write operation (i.e., database operation) according to the partition information table, that is, finds the primary replicas P1 and P2 of the data partition to which the data items of the read and write operation belong; then, the coordination node device C1 calls the remoteRW() function to send the read and write operation (i.e., sub-transaction) to the corresponding data node device, and the corresponding read and write operation is performed on the data node device. In other words, the coordination node device C1 calls the remoteRW() function to distribute different sub-transactions to the primary replicas P1 and P2 respectively, and the primary replicas P1 and P2 each perform the corresponding read and write operations, and at the same time calls the addToRWSet() function to maintain the read and write set of the sub-transaction (the read and write set includes a read set and a write set, both of which are data structures required to be maintained in the OCC algorithm); then, the data node devices, i.e., the primary replicas P1 and P2, return the sub-transaction execution result (i.e., the read and write result of the read and write operation) to the coordination node device C1.

[0229] Schematically, the pseudo code of the relevant functions in the reading and writing stages is as follows:

[0230]

[0231]

[0232] Secondly, in the preparation phase of the distributed transaction, the following process is executed in the system: the coordination node device C1 calls the replicateRWOp() function to back up the transaction read and write operations (i.e., the transaction operation log list ops) to other coordination node devices C2 in the same coordination node group; then, the coordination node device C1 calls the prepare() function to issue a prepare request for the target transaction to each data node device (i.e., the primary copy); after receiving the prepare request, the data node device locally calls the lockAndValidate() function to perform data anomaly detection on the sub-transaction and returns the result to the coordination node device, such as returning the anomaly detection result, or returning the prepare completion response corresponding to the anomaly detection result, which is not limited here.

[0233] Schematically, the pseudo code of the relevant functions in the preparation stage is as follows:

[0234]

[0235]

[0236] Finally, in the commit phase of the distributed transaction, the following process is executed in the system: If all data node devices return success, that is, the prepare completion response returned by all master replica node devices indicates successful preparation, then the transaction can be committed; otherwise, as long as any data node device returns Prepare failure, that is, the prepare completion response returned by any master replica node device indicates prepare failure, then the transaction will be rolled back; assuming that the transaction can be committed, the coordination node device C1 obtains the transaction commit timestamp tid, which can be a physical timestamp, a logical timestamp, or a combination of the two; then, the coordination node device calls the commit() function and sends a commit request to each data node device, that is, the master replica node device; then, the data node device calls the writeAndReplicate() function to write the data item on the Leader master replica and synchronize the Redo log to other Follower slave replicas in the replica group to which it belongs; then, the data node device replies to the coordination node device that Commit is completed, that is, the master replica node device returns a commit completion response to the coordination node device.

[0237] Schematically, the pseudo code of the relevant functions in the submission phase is as follows:

[0238]

[0239] In the previous embodiment, the transaction processing flow of the lightweight transaction-granularity replica synchronization mechanism provided by this application in combination with the OCC concurrency control algorithm is introduced in detail. In the embodiment of this application, the fast fault recovery algorithm within the system under the above-mentioned lightweight transaction-granularity replica synchronization mechanism will be introduced. The following will discuss the fault recovery algorithms for the three cases of primary and replica node device failure, coordination node device failure, and failure of both.

[0240] Figure 11 This is an interactive flow chart of a fault recovery process when a master and replica node device fails, as provided in an embodiment of the present application. Figure 11 As shown, this embodiment is applicable to a distributed database system. Assuming that during the execution of a target transaction, any master or replica node device involved in the target transaction fails, the failure recovery process includes the following steps:

[0241] 1101. The coordinating node device determines a target node device selected from at least one slave replica node device corresponding to a failed primary replica node device.

[0242] In some embodiments, each data node device (which can be a master replica node device or a slave replica node device) in a distributed storage cluster regularly detects node failures through a heartbeat mechanism, so that the master replica node device that fails can be discovered in time. When any master replica node device involved in the target transaction fails, the other data node devices that maintain a heartbeat connection with the master replica node device can discover the failure through the heartbeat mechanism. For example, when other data node devices still do not receive a heartbeat message from the master replica node device after exceeding the second target duration, or when other node devices send a heartbeat message to the master replica node device without receiving a reply after exceeding the third target duration, it can be discovered that the master replica node device has failed, wherein the second target duration and the third target duration can be the same or different, and the second target duration and the third target duration are both any values ​​greater than 0. The embodiments of the present application do not specifically limit this.

[0243] In some embodiments, after a master replica node device fails, the data partition where the failed master replica node device (hereinafter referred to as the failed node device) is located can be re-elected as the master. For example, in the replica group of the data partition where the failed node device is located, if the slave replica node device discovers that the master replica node device has failed through the heartbeat mechanism, it can notify other slave replica node devices to start voting to elect the next new master replica node device. That is, each slave replica node device in the replica group of the data partition where the failed node device is located will independently perform a re-master election operation, and finally vote to elect a slave replica node device with the highest number of votes as the new master replica node device. This newly elected master replica node device is the target node device involved in the embodiments of the present application.

[0244] In some embodiments, when electing a target node device, a random election can be performed to simplify the election process, or the node device with the lowest load can be preferentially selected to achieve load balancing within the system. The embodiments of the present application do not specifically limit the election method of the target node device.

[0245] Schematically, the target node device is randomly selected from the at least one slave replica node device, that is, one is randomly selected from each slave replica node device in the replica group of the data partition where the failed node device is located as the target node device.

[0246] Schematically, the target node device is the node device with the lowest load among the at least one slave replica node device, that is, the node device with the lowest load is selected as the target node device from each slave replica node device in the replica group of the data partition where the failed node device is located.

[0247] In some embodiments, after the target node device is selected from the replica group of the data partition where the faulty node device is located, the node identifier or device identifier of the master replica node device of the data partition is updated in the partition information table of each coordination node device in the coordination layer. For example, in the partition information table, the node identifier or device identifier of the master replica node device of the data partition is changed from the faulty node device to the target node device.

[0248] It should be noted that after the target node device is selected, it will prioritize entering the fault recovery process for the transaction that was originally being executed and is currently waiting for recovery, and will not directly execute the newly sent transaction operation. This is because the transaction that was originally being executed and is currently waiting for recovery is in a blocked state, and therefore needs to be recovered more urgently to ensure the execution success rate of this part of the transaction and reduce the possibility of these transactions being rolled back due to waiting timeout.

[0249] In some embodiments, after the target node device is elected and the partition information table is updated, the coordinating node device queries the updated partition information table to query the newly elected target node device for the data partition where the failed node device is located.

[0250] 1102. The coordinating node device determines a target sub-transaction corresponding to the target node device. The target sub-transaction refers to a sub-transaction that was originally executed by the primary and replica node devices but is waiting to be recovered due to a failure.

[0251] In some embodiments, the coordination node device takes all sub-transactions that were originally executed by the faulty node device but are waiting to be recovered due to the fault and that are coordinated by the coordination node device as target sub-transactions. Optionally, after the faulty node device goes down, among the transactions that are being run by the coordination node device, transactions that meet the following two conditions will be determined as transactions that need to be recovered (hereinafter referred to as transactions to be recovered): Ⅰ) The failure of the operated data node device (referring to the primary and secondary node devices) is sensed through the heartbeat mechanism; Ⅱ) When executing the operation, the operation times out and no result is returned. After the coordination node device has completed the determination and found all the transactions to be recovered on the coordination node device, for each transaction to be recovered, the operation log list ops temporarily stored in the context information of the transaction to be recovered is retrieved. Then, in the operation log list ops, the operation record involving the data partition where the faulty node device is located is determined as the target sub-transaction (or the database operation sequence considered to be the target sub-transaction, that is, the operation queue to be recovered). After traversing all transactions to be recovered, the target sub-transaction that needs to be redone by the target node device can be found after decomposing each transaction to be recovered.

[0252] 1103. The coordinating node device sends the to-be-recovered operation queue of the target sub-transaction to the target node device. The to-be-recovered operation queue includes at least one operation record corresponding to the target sub-transaction in the operation log list.

[0253] In some embodiments, the coordinating node device reads the updated partition information table, finds the node identifier or device identifier of the newly elected target node device in the data partition where the failed node device is located, and then queries the IP (Internet Protocol) address and communication port of the target node device based on the node identifier or device identifier of the target node device, and uses the database operation sequence of all target sub-transactions determined in the above step 1102 as the operation queue to be recovered of the target sub-transaction, and packages them and sends them to the IP address and communication port of the target node device.

[0254] It should be noted that since the faulty node device may process transactions sent from different coordination node devices at the same time, each coordination node device in the distributed coordination system can package and send the recovery operation sequence of all target sub-transactions to the target node device through the above steps 1101-1103.

[0255] 1104. The target node device receives the to-be-recovered operation queue of the target sub-transaction sent by any coordinating node device.

[0256] The target sub-transaction refers to a sub-transaction that was originally assigned by the coordination node device to the other master-replica node device for execution, but is waiting for recovery due to a failure.

[0257] It should be noted that, since in a distributed storage cluster, the same node device may serve as the master replica node device of a certain data partition and also serve as the slave replica node device of other data partitions, the target node device involved in the embodiment of the present application may be the same physical machine as the master replica node device responsible for processing the target transaction in the above-mentioned embodiments. In other words, when the master replica node device involved in the previous embodiment serves as the slave replica node device of another master replica node device, if the other master replica node device fails, the master replica node device is elected as the target node device, then at this time the master replica node device in the previous embodiment and the target node device in the embodiment of the present application may be the same physical machine. Of course, the master replica node device in the previous embodiment and the target node device in the embodiment of the present application may not be the same physical machine, that is, the two are independent physical machines, or, the master replica node device in the previous embodiment may also serve as the failure node device in the embodiment of the present application, and the embodiment of the present application does not make specific limitations on this.

[0258] In some embodiments, the target node device receives the queue of operations to be recovered of each target sub-transaction sent by each coordinating node device. It should be noted that each coordinating node device may package and send one or more target sub-transactions in the queue of operations to be recovered. Therefore, the target node device collects the queue of operations to be recovered of all target sub-transactions, which is equivalent to collecting all target sub-transactions to be recovered, so as to facilitate the redo of database operations of these target sub-transactions.

[0259] 1105. The target node device determines, based on the queue of operations to be recovered, from the target sub-transaction, a first sub-transaction that meets the transaction commit condition, a second sub-transaction that meets the transaction rollback condition, and a remaining third sub-transaction.

[0260] In some embodiments, in order to maintain data consistency, different recovery strategies are adopted for target subtransactions that are in different stages before being blocked by a failure. Optionally, the target subtransaction that has entered the commit stage (i.e., the first subtransaction) is redone first, and then the target subtransaction in other stages (such as the read-write stage or the prepare stage) (i.e., the third subtransaction) is redone. The target subtransaction that needs to be rolled back (i.e., the second subtransaction) does not need to be redone.

[0261] In some embodiments, for any target sub-transaction received in the queue of operations to be recovered, the target node device queries the preparation operation record of the parent transaction corresponding to the target sub-transaction in the queue of operations to be recovered, that is, queries the preparation operation record with the type field value of Prepare in the queue of operations to be recovered ops of the target sub-transaction.

[0262] Optionally, if the preparation operation record indicates that the parent transaction is in the preparation stage as the preparation completion state, the preparation operation record is recorded as<Prepare,True> , which means that the preparation was successful before the failure occurred and it was necessary to enter the commit phase of the 2PC algorithm. Therefore, the transaction commit conditions were met and the target subtransaction was determined as the first subtransaction.

[0263] Optionally, if the prepare operation record indicates that the parent transaction is in a prepare failure state during the prepare phase, the prepare operation record is recorded as<Prepare,False> , indicating that the transaction was prepared for failure before the failure occurred and that the target subtransaction (i.e., the other subtransactions decomposed from the parent transaction) needed to be rolled back. Therefore, the transaction rollback condition was met and the target subtransaction was determined as the second subtransaction.

[0264] Optionally, if the prepare operation record indicates that the parent transaction is in a state that is neither a prepare complete state nor a prepare failed state during the prepare phase, the prepare operation record is recorded as<Prepare,Null> , which means that before the failure occurred, the process was still waiting for the master and replica node devices to return a prepare completion response, or no prepare operation record with the type field value of Prepare was found in the operation queue to be recovered, which means that before the failure occurred, the process was in the read-write phase and had not entered the prepare phase. In this case, the target subtransaction is determined to be the third subtransaction.

[0265] In some embodiments, for each target sub-transaction, it is determined whether the target sub-transaction is the first sub-transaction and whether the target sub-transaction is the second sub-transaction based on the preparation operation record in its to-be-recovered operation queue. If it is neither the first sub-transaction nor the second sub-transaction, it is determined to be the third sub-transaction.

[0266] 1106. The target node device discards the operation record associated with the second sub-transaction.

[0267] In some embodiments, for the second sub-transaction that meets the transaction rollback conditions, the second sub-transaction needs to be rolled back. However, before the failure occurs, the operations performed on the faulty node device have not yet been synchronized to the target node device. This is due to the lightweight transaction granularity copy synchronization mechanism. The faulty node device that originally served as the master copy will only initiate copy synchronization during the commit phase. Since the second sub-transaction corresponds to the parent transaction that needs to be globally rolled back, it is impossible to enter the commit phase. Therefore, the second sub-transaction cannot be synchronized from the faulty node device that originally served as the master copy to the target node device that originally served as the slave copy. That is, at this time, the target node device still stores the data version before the second sub-transaction is modified. Therefore, there is no need to perform any modification operations. The operation records associated with the second sub-transaction can be directly discarded to complete the transaction rollback of the second sub-transaction.

[0268] 1107. The target node device redoes the first subtransaction based on the queue of operations to be recovered, and returns a commit completion response of the first subtransaction to the corresponding coordinating node device.

[0269] In some embodiments, for the first subtransaction that meets the transaction commit conditions, it means that the first subtransaction has entered the commit phase of the 2PC algorithm before the failure occurs, that is, the first subtransaction can definitely be committed successfully, so the target node device gives priority to redoing all detected first subtransactions.

[0270] In some embodiments, for any first sub-transaction, since the first sub-transaction has entered the commit phase of the 2PC algorithm before the failure occurs, there are two situations at this time. The first situation is that the failed node device has synchronized the redo log of the first sub-transaction to the target node device before the failure occurs. The second situation is that the failed node device has not yet synchronized the redo log of the first sub-transaction to the target node device before the failure occurs.

[0271] For the first case mentioned above, the faulty node device has synchronized the redo log of the first subtransaction to the target node device before the failure occurs. At this time, the target node device may have completed the replay of the redo log of the first subtransaction. At this time, there is no need to re-execute the database operation of the first subtransaction, because the new value to be written by the first subtransaction has been written to the disk with the replay of the redo log. At this time, the target node device only needs to create the context information of the first subtransaction in the memory, maintain the information required for concurrency control of the first subtransaction in the context information, and submit the first subtransaction, and return a commit completion response to the coordination node device responsible for coordinating the parent transaction of the first subtransaction. Optionally, the information required for concurrency control of the first sub-transaction refers to the information that needs to be maintained to ensure concurrency control under the constraints of the corresponding concurrency control algorithm. The information that needs to be maintained for different concurrency control algorithms is different. For example, the 2PL concurrency control algorithm needs to lock the data items of the operation, and the OCC concurrency control algorithm needs to maintain the read-write set of the transaction operation; or, the faulty node device has synchronized the redo log of the first sub-transaction to the target node device before the failure occurs, but the target node device has not yet completed the replay of the redo log of the first sub-transaction. At this time, the target node device only needs to replay the redo log of the first sub-transaction, and perform the above operations after the replay is complete to achieve fault recovery of the first sub-transaction. This will not be elaborated here.

[0272] For the second case mentioned above, the failed node device has not synchronized the redo log of the first sub-transaction to the target node device before the failure occurs. In this case, the target node device needs to traverse and execute each database operation to be recovered in the queue of operations to be recovered of the first sub-transaction from the beginning, while maintaining the information required for concurrency control of the first sub-transaction. Then, the first sub-transaction is committed, and a submission completion response is returned to the coordination node device responsible for coordinating the parent transaction of the first sub-transaction. The redo log of the first sub-transaction is generated based on each database operation to be recovered, and the generated redo log of the first sub-transaction is sent to each other slave replica node device of the replica group to which it belongs. It should be noted that since the first sub-transaction has completed the preparation phase of the 2PC algorithm and entered the submission phase of the 2PC algorithm, all database operations in the read and write phases of the first sub-transaction have obtained read and write results. Therefore, the data state (or the read data version and the written data version) after the execution of the first sub-transaction is completed is already determined.

[0273] It should be noted that in order to ensure that write-write conflicts do not occur, for any data item, in the transaction processing process, it is guaranteed that at most only one transaction that contains a write operation on the data item can enter the commit phase of the 2PC algorithm (this can be achieved by locking the data item and other mechanisms, which will not be expanded here). Therefore, there is no situation where multiple concurrent transactions enter the commit phase of the 2PC algorithm after performing write operations on the same data item. Suppose there is a transaction T1 that writes to data item X.<Write,X1> Transaction T2 performs a read operation on data item X<Read,X0> , and both transactions T1 and T2 have entered the commit phase of the 2PC algorithm, then based on the fault recovery algorithm of the embodiment of the present application, the execution results of transactions T1 and T2 will not change after recovery. In other words, the fault recovery algorithm of the embodiment of the present application can ensure that the execution results of the read and write operations of transactions that have entered the commit phase of the 2PC algorithm will not change after fault recovery, that is, there is no situation where transaction T2 reads version X0 before the fault occurs and reads version X1 after the fault occurs, and if such an inconsistency in the operation versions before and after fault recovery is detected, then transaction T2 can be directly rolled back.

[0274] In the above process, it is equivalent to redoing the first subtransaction based on the redo log playback if the target node device has not yet replayed the redo log of the first subtransaction, if the synchronized redo log is stored on the target node device; if the redo log is not stored on the target node device, then based on the queue of operations to be recovered, executing at least one operation record corresponding to the first subtransaction, maintaining the information required for concurrency control of the first subtransaction, submitting the first subtransaction, returning a commit completion response to the coordination node device responsible for coordinating the parent transaction of the first subtransaction, generating the redo log of the first subtransaction, and sending the redo log to the corresponding slave replica node device.

[0275] It should be noted that when submitting the first sub-transaction, the data items written by the first sub-transaction are written to the disk, and the information required for concurrency control of the first sub-transaction is released (such as releasing lock resources, clearing the stored read-write collection, etc.), and the context information of the first sub-transaction is released. These operations are not described in detail here.

[0276] Since the first subtransactions that have entered the commit phase are redone first, these first subtransactions are guaranteed to be committed. This greatly improves the execution success rate of the parent transactions of the first subtransactions, reduces the probability of these parent transactions being rolled back as a whole due to failures, and better ensures the high availability of the lightweight transaction-granularity replica synchronization mechanism.

[0277] 1108. For each coordination node group in the distributed database system, any coordination node device in the coordination node group sends a redo completion instruction to the target node device in response to the commit completion response of the first subtransaction.

[0278] The redo completion instruction is used to indicate that the redo of the first sub-transaction coordinated by the corresponding coordination node group is completed.

[0279] In some embodiments, since there are multiple coordination node groups in the distributed database system, each coordination node group may have a first sub-transaction that has entered the commit phase of the 2PC algorithm. Therefore, a redo progress variable is_commit can be set for each coordination node group. The redo progress variable is_commit is used to record the number of transactions of the first sub-transaction to be redone in the current coordination node group. Since the first sub-transaction represents the target sub-transaction to be recovered that has entered the commit phase, the redo progress variable is_commit actually represents the number of committed transactions to be redone in the coordination node group to which it belongs. Then, for the coordination node group, whenever any coordination node device receives a target sub-transaction The commit completion response of any first sub-transaction returned by the target node device indicates that the first sub-transaction entering the commit phase has been redone, and the redo progress variable is_commit is reduced by 1. In other words, the redo progress variable is_commit is assigned the value obtained by reducing 1 from the original value. When the redo progress variable is_commit is reduced to 0, it means that there is no unredoed first sub-transaction in the current coordination node group. At this time, any coordination node device in the coordination node group can send an additional redo completion instruction (denoted as commit_done) to the target node device, indicating that all the first sub-transactions entering the commit phase that are coordinated within this coordination node group have been redone.

[0280] 1109. When the target node device receives a redo completion instruction sent by any coordinating node device in the multiple coordinating node groups, the target node device redoes the third subtransaction based on the queue of operations to be recovered.

[0281] In some embodiments, if the target node device has received the redo completion instruction commit_done sent by at least one coordinating node device in each coordinating node group, that is, the target node device needs to receive the redo completion instruction commit_done sent by all coordinating node groups involved in operating data items on the data partition at the time of the failure, but each coordinating node group only needs at least one coordinating node device to return the redo completion instruction commit_done, without waiting for all coordinating node devices in each coordinating node group to return the redo completion instruction commit_done, and more than one coordinating node device in each coordinating node group may send the redo completion instruction commit_done. This is because for each coordinating node group, each coordinating node device in the coordinating node group temporarily stores the redo progress variable is_commit representing the number of transactions of all first sub-transactions to be redone in the coordinating node group. Therefore, when any coordinating node device in the coordinating node group learns that the redo progress variable is_commit has become 0, it indicates that all first sub-transactions that have entered the commit stage in the current coordinating node group have been redone.

[0282] After the target node device receives the redo completion instruction commit_done sent by all the coordination node groups involved in operating the data items on this data partition at the time of the failure, it means that all the first sub-transactions that have entered the commit node on this data partition in the entire distributed database system have been redone. Therefore, the third sub-transaction that did not enter the commit stage before the failure can be redone.

[0283] In some embodiments, the target node device executes at least one operation record corresponding to the third sub-transaction based on the queue of operations to be recovered. For example, the target node device traverses and executes each database operation to be recovered in the queue of operations to be recovered of the third sub-transaction from the beginning, while maintaining the information required for concurrency control of the third sub-transaction. If the third sub-transaction has entered the preparation phase of the 2PC algorithm before the failure occurs, then data anomaly detection for the third sub-transaction can be enabled to obtain an anomaly detection result, and a preparation completion response corresponding to the anomaly detection result can be returned to the coordination node device responsible for coordinating the parent transaction of the third sub-transaction. Alternatively, if the third sub-transaction has not entered the preparation phase before the failure occurs and is still in the read-write phase, then the target node device returns the sub-transaction execution result of the third sub-transaction to the coordination node device, waits for the preparation request of the parent transaction issued by the coordination node device, and after receiving the preparation request, enables data anomaly detection for the third sub-transaction to obtain an anomaly detection result, and returns a preparation completion response corresponding to the anomaly detection result to the coordination node device.

[0284] In some embodiments, after the target node device returns a prepare completion response, the parent transaction of the third sub-transaction may enter the commit phase, or it may detect that any sub-transaction of the parent transaction has failed to prepare and thus be globally rolled back. That is, the first sub-transaction will definitely be committed because it has entered the commit phase, but the third sub-transaction has not entered the commit phase (it has not yet been determined whether the preparation is successful) and therefore may be committed or rolled back.

[0285] In some embodiments, when the target node device receives the commit request of the parent transaction issued by the coordinating node device, the target node device commits the first sub-transaction, returns a commit completion response to the coordinating node device, generates a redo log for the third sub-transaction, and sends the generated redo log of the third sub-transaction to each of the other slave replica node devices in the replica group to which it belongs. It should be noted that when committing the third sub-transaction, the data items written by the third sub-transaction are written to the disk, and the information required for concurrency control of the third sub-transaction is released (such as releasing lock resources, clearing the stored read-write set, etc.), and the context information of the third sub-transaction is released. These operations are not described in detail here.

[0286] In some embodiments, upon receiving a rollback instruction for the third subtransaction, the target node device rolls back the third subtransaction. Rolling back the third subtransaction means restoring each data item modified by the third subtransaction to its pre-modified data version. The transaction rollback can be achieved using the rollback log of the third subtransaction. Optionally, the rollback instruction is triggered when a data item corresponding to the database operation involved in the third subtransaction changes, or when an anomaly detection result of the parent transaction corresponding to the third subtransaction indicates a data anomaly.

[0287] It should be noted that a constraint needs to be added to the third sub-transaction: that is, to ensure that the read and write results of the third sub-transaction remain consistent before and after recovery. Therefore, if it is detected that the data items corresponding to the database operations involved in the third sub-transaction have changed, for example, the read data items have changed (for example, version X0 was read before the failure, and version X1 was read after redoing), the current third sub-transaction needs to be rolled back to ensure that the transaction status remains consistent before and after failure recovery.

[0288] By adding the above constraints, it is possible to ensure that the transaction status of the third subtransaction remains consistent before and after fault recovery. The third subtransaction is an uncommitted transaction that has not entered the commit stage. Since the first subtransaction (a committed transaction that has entered the commit stage) is redone first, this part of the first subtransaction may have modified some data items, resulting in the data version read by the third subtransaction after the redo being inconsistent with the data version read before the redo. Therefore, by recording the data version read by the third subtransaction before the redo on the coordination node device (recorded in the operation log list ops of its parent transaction), and then after receiving the subtransaction execution result returned by the target node device after the redo, the coordination node device compares the data version recorded in the operation log list ops with the data version of the received subtransaction execution result, so that it can be determined whether the data item corresponding to the database operation involved in the third subtransaction has changed. It should be noted that in the operation log list ops, the data version recorded in the operation record of any database operation may be the old version data. If the old version data is recorded, it is considered that the third sub-transaction before the redo reads the old version data; in addition, there may be no record content in the operation record (that is, the data version is not recorded in the operation record), in which case it is considered that the third sub-transaction before the redo reads the new version data.

[0289] In the above steps 1107-1109, a possible implementation method is provided for the target node device to redo the first sub-transaction and the third sub-transaction based on the queue of operations to be recovered. By temporarily storing the operation log list ops on the coordination node device and utilizing the characteristics of the multi-copy mechanism in the distributed database system, it is ensured as much as possible that the transaction will not be rolled back due to node failure. Moreover, in the fault recovery process, only the sub-transaction being executed on the faulty node device is redone, and the entire parent transaction is not redone. This is equivalent to saving the time spent on redoing the corresponding sub-transaction on the non-faulty node device of the parent transaction, thereby greatly improving the transaction redo efficiency.

[0290] Furthermore, by giving priority to redoing the first subtransaction and then redoing the third subtransaction after the first subtransaction is redone, it can be ensured that the first subtransaction that can be committed is redone first, which greatly guarantees that the first subtransaction will not be rolled back due to a failure, and then the third subtransaction is redone. In addition, a constraint is added to ensure that the read and write results of the third subtransaction remain consistent before and after recovery. Therefore, if the third subtransaction can be successfully committed before and after the redo, its transaction consistency is greatly guaranteed.

[0291] The following describes the fault recovery process of an embodiment of the present application with reference to an example of a specific transaction.

[0292] Given any transaction, assuming that the transaction performs a total of N (N≥1) read and write operations on multiple data partitions, if a data node device (which may be the primary replica where the Mth operation is located, or the primary replica corresponding to other operations of this transaction) fails when executing the Mth (1≤M≤N)th operation. If this transaction is rolled back and restarted, then the first M operations of this transaction need to be redone, which will inevitably waste a lot of system resources. In order to make the transaction recovery efficiency as high as possible, in the event of a failure of a data node device (i.e., the primary replica node device), the operation log list ops temporarily stored by the transaction on the coordination node device can be used to redo only the operations that have been executed on the failed node device (i.e., the failed primary replica node device), thereby restoring the execution status of the transaction.

[0293] Illustratively, when the primary replica node device of a replica group to which a data partition belongs fails, a new primary replica node device is re-elected for that data partition within the replica group (i.e., a new primary replica node device is selected from the secondary replica nodes). This newly elected primary replica node device is called the target node device. Subsequently, database operations involving the target subtransaction for that data partition are redone on the target node device. Once the target subtransaction has been redone, the corresponding parent transaction can continue executing without being rolled back.

[0294] In one example, assuming that a primary replica node device (hereinafter referred to as the faulty node device) fails during the execution of the Mth operation, and the transaction performs K operations on the data partition corresponding to the faulty node device, then in the case of a traditional overall rollback and restart of the transaction, the first M operations need to be redone. However, under the fault recovery mechanism of the embodiment of the present application, only the K operations on the faulty node device need to be redone, thus saving a total of MK times the system overhead of redoing operations. By redoing only the database operations of the target subtransaction involving the faulty node device and not redoing the database operations on other healthy node devices, the fault recovery scheme can save the overhead of redoing database operations involving data items on healthy node devices, thereby reducing transaction redo time and improving transaction redo efficiency.

[0295] Figure 12 This is a principle flow chart of a fault recovery mechanism provided by an embodiment of the present application, such as Figure 12 FIG2 shows an example of executing a fast transaction failure recovery algorithm. Assume that transaction T1 involves writing data items X1 and Y1 and reading data item Z0, where data item X1 belongs to data partition 1, data item Y1 belongs to data partition 2, and data item Z0 belongs to data partition 3. Assume that when transaction T1 executes the Read(Z) operation, the primary replica node device 1201 of data partition 1 fails. Then, the target subtransaction Write(X1) involving data partition 1 needs to be redone, while the subtransactions Write(Y1) and Read(Z) on the remaining healthy node devices do not need to be redone. In other words, although transaction T1 operates on data items on data partitions 1, 2, and 3, when the primary replica node device 1201 of data partition 1 fails, it is only necessary to find the target sub-transaction Write (X1) of transaction T1 on data partition 1, and then resend the target sub-transaction Write (X1) to the new primary replica node device 1202 elected in data partition 1 for execution. After the Write (X1) operation on the new primary replica node device 1202 is redone, transaction T1 can continue to execute its subsequent operations without being rolled back.

[0296] Since only the target subtransactions on the failed node device are redone, this poses a challenge to ensuring data consistency before and after the redo. By prioritizing the redo of the first subtransaction that has entered the commit phase and adding a constraint to the third subtransaction that has not yet entered the commit phase to ensure that the read and write results of the third subtransaction remain consistent before and after recovery, we can ensure that after the recovery of any target subtransaction is completed, the transaction execution results (i.e., read and write results) will not be changed due to the failure. It should be noted that the redo of the target subtransaction uses logical redo, which performs data playback by executing database operations.

[0297] Figure 13 This is a schematic diagram of a transaction recovery process provided by an embodiment of the present application. Figure 13 As shown, an exemplary description of a transaction recovery process is provided. Assuming that in a distributed database system, coordination node device 1 is responsible for coordinating transactions T1 and T2, and coordination node device 2 is responsible for coordinating transactions T3 and T4. Transaction T1 involves operating data items of data partitions 1 and 3, transaction T2 involves operating data items of data partition 2, transaction T3 involves operating data items of data partitions 1 and 3, and transaction T4 is responsible for operating data items of data partitions 1 and 2. During the execution of the above transactions T1 to T4, the primary replica node device 1301 of data partition 1 fails. At this time, the transactions that need to be recovered include T1, T4, and T3. Since transaction T2 does not involve operating data items of data partition 1, transaction T2 does not need to be recovered. Next, assuming that among the transactions T1, T4, and T3 that need to be recovered, transaction T1 has entered the commit phase, while transactions T4 and T3 have not yet entered the commit phase, then after a new master replica node device 1302 is elected in data partition 1, in order to ensure the correctness of transaction recovery, the new master replica node device 1302 will give priority to redoing the target subtransaction (i.e., the first subtransaction) of transaction T1 on the data partition 1. Only after all the first subtransactions that have entered the commit phase have been redone can the target subtransaction (i.e., the third subtransaction) of transactions T4 and T3 on the data partition 1 be redone.

[0298] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0299] The method provided in the embodiment of the present application utilizes the characteristics of the multi-copy mechanism in a distributed database system. After any master copy node device fails, a new master copy node device, namely the target node device, is elected from the copy group. At the same time, since the operation log list is temporarily stored on the coordination node device, the target node device can redo each sub-transaction that is blocked due to the failure according to the queue of operations to be recovered split from the operation log list by the coordination node device, thereby ensuring as much as possible that the transaction will not be rolled back due to the node failure. Moreover, in the fault recovery process, only the sub-transaction being executed on the faulty node device is redone, and the entire parent transaction will not be redone. This is equivalent to saving the time spent on redoing the corresponding sub-transaction on the non-faulty node device of the parent transaction, thereby greatly improving the transaction redo efficiency.

[0300] Furthermore, in financial scenarios, this plays a crucial role in ensuring the reliability of data services in distributed database systems. For example, in flash sales, a massive influx of orders and transactions occurs simultaneously, leading to a surge in transaction volume. This also means a surge in concurrent transactions within the system. Consequently, the system load is generally heavy. A system failure will affect a large number of transactions, and if these transactions are forced to roll back due to the failure, economic losses will inevitably result. Therefore, the fault recovery mechanism described in the embodiments of this application has strong practical significance for enhancing the product competitiveness and technical influence of distributed database systems.

[0301] In the previous embodiment, the transaction failure recovery mechanism when a data node device (especially a master-replica node device) fails is introduced in detail. That is, after a master-replica node device fails, the corresponding data partition is re-elected as the master within the replica group, and the target sub-transaction involving the failed node device is redone to ensure the correctness of transaction recovery.

[0302] The following describes the transaction recovery process in two phases:

[0303] a) Master-replica switching phase: In the master-replica (Leader) switching phase, the master-replica Leader will be reselected among the healthy slave replicas in the replica group of the data partition to which the failed node device belongs.

[0304] b) Sub-transaction redo phase: On the newly elected primary replica node device (i.e., target node device), the target sub-transaction that has entered the commit phase (i.e., the first sub-transaction) is redone first, followed by the target sub-transaction that is in the read-write phase or the prepare phase (i.e., the third sub-transaction). This allows all transactions affected by the failure to continue executing without being rolled back due to the failure (although they may still be rolled back due to inconsistent data versions or data anomalies).

[0305] The above two stages ensure that when a data node device fails, the database operations on the failed node device are redone, thereby ensuring the correctness of transaction recovery.

[0306] The following will describe in detail a possible implementation method of fault recovery from the perspective of the processing logic of the coordination node device and the data node device at different stages.

[0307] The coordination node device is mainly responsible for coordinating transactions and maintaining some transaction metadata. In addition, the coordination node device will also record the data items of each operation in the operation log list ops (equivalent to marking the read and write results before redo). If a failure occurs, the data version can be compared during redo, that is, the sub-transaction execution result after redo is compared with the read and write results before redo recorded in the operation log list ops, and the data version of the operation result can be compared to see if it has changed (this is because when redoing a transaction, some transactions may read inconsistent value versions before and after redo. This type of anomaly can be discovered in time through comparison of the coordination node device). In addition, the coordination node device will also store the transactions that have been successfully prepared, that is, insert a preparation operation record into the transaction operation log list ops. The information of such transactions, namely the operation log list ops, will be synchronized between the coordination node devices in the same coordination node group. The synchronization method can be active synchronization or timed synchronization, which is not specifically limited here.

[0308] Data node devices include master and slave replica node devices. The master and slave replicas are divided according to data partitions, not physical machines. In other words, a data node device (referring to a physical machine) may serve as the master replica for one data partition while also serving as a slave replica for another data partition. During transaction execution, two threads, executor and checker, can be created on the data node device. The executor thread is responsible for reading and writing data items and generating read-write sets, which is equivalent to the transaction execution process. The checker thread is responsible for detecting failures in the data node device, which is equivalent to the check thread that maintains the heartbeat mechanism.

[0309] During the master-replica switching phase, the following operations are performed between the data node devices in the system:

[0310] When any data node device fails, all sub-transactions involving the failed node device are blocked. The Checker threads of other data node devices can detect that the data node device has failed through the heartbeat mechanism. For example, when other data node devices find that they cannot receive the heartbeat message of the failed node device, they will detect that the failed node device has failed.

[0311] In the case where the failed node device is the master replica node device of a certain data partition, the remaining healthy slave replica node devices in the replica group corresponding to the data partition call the switch_leader function to vote and elect a new master replica node device from the replica group based on the partition information table (also called partition metadata). For example, one of the healthy slave replica node devices can be randomly selected as the new master replica node device. For another example, a healthy slave replica node device with a lower load (such as a load below a preset threshold, or the load is the lowest in the replica group) is given priority as the new master replica node device, so as to achieve load balancing within the system as much as possible. After the new master election is completed, the updated partition information table can be synchronized between the data node devices. At the same time, it is also necessary to notify the various coordination node devices in the coordination layer to synchronize the updated partition information table. For example, the data node device notifies the coordination node device to update the partition information table by sending a partition update message. For example, the partition update message carries the updated partition information table.

[0312] Schematically, the pseudo code of the relevant functions involved in the master-replica switching phase is as follows:

[0313]

[0314]

[0315] During the sub-transaction redo phase, the coordination node device and data node device in the system perform the following operations respectively:

[0316] The coordinating node device determines each transaction to be recovered related to the failed node device, finds the target sub-transactions decomposed from each transaction to be recovered on the failed node device, and packages the queue of operations to be recovered (i.e., the database operations to be redone) for each target sub-transaction and sends it to the newly elected master replica node device. The newly elected master replica node device is the target node device involved in the previous embodiment. Optionally, the coordinating node device sends the queue of operations to be recovered for each target sub-transaction to the newly elected master replica node device through a timeout retransmission mechanism.

[0317] Optionally, the coordinating node device collects all target subtransactions (i.e., first subtransactions) to be redone that have entered the Commit phase for the data partition where the failed node device is located. Since there may be multiple coordinating node groups in the system, each coordinating node group may have first subtransactions that need to be redone. Therefore, a redo progress variable, denoted as is_commit, is set on each coordinating node group to record the number of first subtransactions to be redone in the current coordinating node group (equivalent to the number of committed transactions to be redone, corresponding to lines 13-16 of the following algorithm pseudocode). Then, each time a first subtransaction is redone, the redo progress variable is_commit is decremented by 1. When the redo progress variable is_commit is decremented to 0, any coordinating node device in the current coordinating node group can send an additional redo completion instruction (denoted as commit_done) to the new primary replica node device to notify its own coordinating node group that all first subtransactions in the group have been redone. If the new master replica node device receives the redo completion instruction commit_done from at least one coordinating node device in each coordinating node group, it means that all first sub-transactions in the system have been redone. It should be noted that since all first sub-transactions in the current coordinating node group are temporarily stored on the coordinating node devices in each coordinating node group, when a coordinating node device learns that the redo progress variable is_commit has become 0, it means that all first sub-transactions in the coordinating node group to which it belongs have been redone.

[0318] Optionally, the third subtransaction in other stages (such as the read-write stage or the preparation stage) needs to be redone from the beginning. For this part of the uncommitted third subtransaction, the data versions read before and after the redo may be inconsistent. This is because the first subtransaction that has entered the commit stage is redone first, and part of the first subtransaction may have modified the data items that the third subtransaction wants to read. In order to solve this problem of inconsistent data versions, the data version read before each transaction is redone can be recorded on the coordination node device. By querying the pre-redo data version temporarily stored by the parent transaction of the third subtransaction and then comparing it with the post-redo data version, it is possible to quickly find out whether there is an inconsistency. If the data version is inconsistent, the parent transaction of the third subtransaction is rolled back. Schematically, the operation log list ops of the transaction is recorded. If the old version of the data is recorded on the coordination node device, it is considered that the transaction before the redo read the old version of the data. If there is no record on the coordination node device, it is considered that the transaction before the redo read the new version of the data. Illustratively, the writeset and readset data structures can be used to temporarily store read-write sets converted from all database operations executed by any transaction. The method for temporarily storing the data version before redo is not specifically limited here.

[0319] For the newly elected master replica node device, also called the target node device involved in the previous embodiment, the target sub-transaction (i.e., the first sub-transaction) that has entered the Commit stage will be redone first according to the redo priority logic. This part of the first sub-transaction only needs to redo the Commit stage, and the redo cost is relatively low. Then, after the faulty node device has completed the redo of all first sub-transactions, the target sub-transaction (i.e., the third sub-transaction) in other stages (read-write stage or preparation stage) will be redone.

[0320] When the faulty node device is repaired and restored to normal, the redo log synchronization mechanism can be used to synchronize the incremental data generated on the new master replica node device during the fault recovery to the newly restored faulty node device in the form of redo logs. Then, the restored faulty node device can replay the incremental data according to the redo logs through physical replication, and can then continue to provide services as a slave replica node device.

[0321]

[0322]

[0323] In the above embodiments, we detailed the operations that the coordinating node and the newly elected primary and secondary node must perform during the primary-replica switching phase and the sub-transaction redo phase, respectively, when a data node device, such as a primary and secondary node device, fails. In the present embodiment, we will discuss in detail how to perform system recovery when a coordinating node device fails.

[0324] Figure 14 This is an interactive flow chart of a failure recovery process for coordinating node equipment failures provided by an embodiment of the present application, such as Figure 14 As shown, this embodiment is applicable to a distributed database system. Assuming that any coordination node group includes a coordination node device responsible for coordinating the target transaction and at least one other coordination node device, if any other coordination node device in the coordination node group fails, the coordination node device takes over the transaction originally executed on the other failed coordination node device. The failure recovery process includes the following steps:

[0325] 1401. The coordination node device queries the synchronization progress parameter of the operation log list of any transaction that was originally executed on other coordination node devices that have failed. The synchronization progress parameter is used to indicate whether the coordination node device has synchronized the entire operation log list of the transaction.

[0326] In some embodiments, the various coordination node devices within the same coordination node group will also maintain communication through a heartbeat mechanism. When the Checker thread of the coordination node device finds that it cannot receive the heartbeat message of another coordination node device, it confirms that the other coordination node device has failed, and broadcasts the failure of the other coordination node device within the coordination node group. Then, a coordination node device is selected in the coordination node group to replace the failed other coordination node device to continue coordinating the originally executed transaction. The embodiment of the present application is explained by taking the coordination node device that takes over the originally executed transaction as an example.

[0327] In some embodiments, since the information synchronization of the transaction operation log list ops between the coordination node devices is asynchronous, for example, there will inevitably be a certain delay under the scheduled sending mechanism, therefore, for the transaction originally being executed on other coordination node devices that have failed, the coordination node device will not store the full operation log list ops of the transaction. This operation log list ops is used to record all information about the database operations that have been executed by the transaction (i.e., operation records).

[0328] In some embodiments, the coordination node device maintains a synchronization progress parameter txn.complete_ops for each transaction, which is used to indicate whether the operation log list ops has been synchronized. Then, for each transaction originally being executed on other coordination node devices where the failure occurs, the synchronization progress parameter txn.complete_ops of the transaction is queried to determine whether the full operation log list ops of the transaction has been synchronized on the current coordination node device.

[0329] It should be noted that when the full operation log list of the transaction is not synchronized, it may be because the transaction itself has not completed all database operations, resulting in the operation log list itself being incomplete. For example, other coordination node devices fail during the read and write phases, and other coordination node devices do not have a full operation log list before the failure, and it is even more impossible to synchronize the full operation log list to this coordination node device. It is also possible that the read and write phases of the transaction itself have been completed, and other coordination node devices held a full operation log list before the failure, but have not had time to complete synchronization with this coordination node device. At this time, it is possible that part of the synchronized operation log list is stored on this coordination node device, but another part of the unsynchronized operation log list is lost.

[0330] In some embodiments, the synchronization progress parameter txn.complete_ops can be binary data, that is, when the synchronization progress parameter txn.complete_ops is 1, it indicates that the full operation log list ops of the transaction is stored on the coordination node device; when the synchronization progress parameter txn.complete_ops is 0, it indicates that the full operation log list ops of the transaction is not stored on the coordination node device. In this case, if the query results in the synchronization progress parameter txn.complete_ops = 1, the process proceeds to step 1402 below; if the query results in the synchronization progress parameter txn.complete_ops = 0, the process proceeds to steps 1403-1405 below.

[0331] In some embodiments, the synchronization progress parameter txn.complete_ops can be a Boolean data type, that is, when the synchronization progress parameter txn.complete_ops is True, it indicates that the full operation log list ops of the transaction is stored on the coordination node device; when the synchronization progress parameter txn.complete_ops is False, it indicates that the full operation log list ops of the transaction is not stored on the coordination node device. In this case, if the query results in the synchronization progress parameter txn.complete_ops = True, the process proceeds to step 1402 below; if the query results in the synchronization progress parameter txn.complete_ops = False, the process proceeds to steps 1403-1405 below.

[0332] 1402. When the synchronization progress parameter indicates that the entire operation log list of the transaction has been synchronized, the coordination node device coordinates the transaction based on the synchronized operation log list.

[0333] In some embodiments, when the synchronization progress parameter txn.complete_ops indicates that the coordination node device has synchronized the full operation log list ops of the transaction, it means that the coordination node device can directly use the synchronized full operation log list ops to continue to coordinate the transaction. Since the operation log list ops is complete and is also synchronized from other failed coordination node devices to the coordination node device, this means that the transaction has at least completed the read and write phases. At this time, the coordination node device queries the operation log list for a preparation operation record. If there is no preparation operation record, it means that the read and write nodes are completed and the preparation phase of the 2PC algorithm has not yet begun before a failure occurs. The coordination node device starts the preparation phase of the 2PC algorithm, that is, sends a preparation request to each master and replica node device of the transaction. The subsequent coordination process is similar to the coordination process when no failure occurs in the aforementioned embodiment, and will not be repeated here. In addition, if there is a preparation operation record, assuming that the preparation operation record is<Prepare,Null> , indicating that it has entered the preparation stage and is still waiting for the preparation completion response of each master and replica node device, then notify each master and replica node device to resend the preparation completion response to this replica node device, and then continue to execute the subsequent coordination process. Assume that the preparation operation record is<Prepare,True> , indicating that the preparation has been successful, then it directly enters the submission phase of the 2PC algorithm and takes over the coordination process of the subsequent submission phase. Assume that the preparation operation record is<Prepare,False> , indicating that the transaction is ready to fail and needs to be rolled back, the transaction rollback instruction is sent to each master and replica node device, and the coordination process of the subsequent rollback phase is taken over.

[0334] 1403. When the synchronization progress parameter indicates that the entire operation log list of the transaction has not been synchronized, the coordination node device notifies the terminal that initiated the transaction to resend the request statement of the transaction.

[0335] In some embodiments, when the synchronization progress parameter txn.complete_ops indicates that the current coordination node device has not synchronized the full operation log list ops of the transaction, it means that the current coordination node device does not locally store the full operation log list ops of the transaction. At this time, it may be because the transaction itself has not completed all database operations, resulting in the operation log list ops itself not being complete. For example, other coordination node devices fail during the read and write phases, and other coordination node devices do not have a full operation log list ops before the failure, and it is even more impossible to synchronize the full operation log list ops to the current coordination node device. It is also possible that the read and write phases of the transaction itself have been completed, and other coordination node devices held a full operation log list ops before the failure, but have not had time to complete synchronization with the current coordination node device. At this time, it is possible that part of the synchronized operation log list ops is stored on the current coordination node device, but another part of the unsynchronized operation log list ops is lost.

[0336] In this case, the coordination node device can notify the application client on the terminal that initiated the transaction, so that the application client can resend the request statement of the transaction (for example, resend the data request of the transaction, or re-initiate the transaction). For example, it can make the application client only resend the database operation sequence that has not yet been synchronized. In other words, since part of the synchronized operation log list ops has been stored on this coordination node device, it only needs to notify the application client to send the database operation sequence that has not yet been synchronized to obtain all the operation information of the transaction, which can save communication overhead.

[0337] 1404. The terminal resends the request statement of the transaction to the coordination node device.

[0338] In some embodiments, the application client on the terminal receives a notification to resend the request statement of the transaction. It should be noted that this is just resending the request statement, which does not mean notifying the user side of the transaction execution failure and re-initiating the transaction. Therefore, the transaction has not been confirmed to have failed, but is only attempting to recover from the failure. Therefore, resending the request statement at this time does not mean re-initiating the transaction after the transaction is rolled back. The transaction is still in the execution process and may be submitted successfully or may be rolled back later.

[0339] In some embodiments, the application client resends the request statement of the transaction to the coordination node device, such as resending the data request of the transaction, or re-initiating the transaction (but without user-side perception), which can simplify the processing logic.

[0340] In some embodiments, the application client only resends the database operation sequences that have not yet been synchronized. In other words, since the coordination node device has already stored a partially synchronized operation log list ops, it only needs to notify the application client to send the database operation sequences that have not yet been synchronized in order to obtain all the operation information of the transaction, which can save communication overhead. Optionally, when the coordination node device sends a notification message to the application client, it carries the latest synchronized database operation in the notification message, so that the application client sends all the database operation sequences that have not yet been synchronized after the latest synchronized database operation in the transaction to the coordination node device.

[0341] In an example, suppose a transaction performs a total of N (N≥1) operations, but the coordination node device only synchronizes the operation log list ops containing the operation records of the first M (1≤M≤N) operations. Then the coordination node device only needs to notify the application client to resend the database operation sequence from the M+1th to the Nth operation, which can greatly save communication overhead.

[0342] 1405. The coordination node device coordinates the transaction based on the request statement returned by the terminal.

[0343] In some embodiments, after the coordination node device receives the request statement returned by the terminal, it can obtain the database operation sequence that has not yet been synchronized based on the request statement, and then notify each master and replica node device to redo the database operation sequence that has not yet been synchronized. After the redo of the database operation sequence that has not yet been synchronized is completed, it will continue to coordinate the transaction execution phase.

[0344] It should be noted that the embodiment of the present application takes the example of other coordination node devices in the same coordination node group failing and the current coordination node device taking over the blocking transaction. Assuming that the current coordination node device fails, other coordination node devices can also take over the blocking transaction in a similar manner, which will not be elaborated here.

[0345] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0346] The method provided in the embodiment of the present application synchronizes the operation log list of transactions between the various coordination node devices in the coordination node group at regular intervals, so that when any coordination node device fails, for the transactions that need to be recovered, the other coordination node devices can use the temporarily stored operation log list to continue to coordinate the transactions, thereby quickly realizing fault recovery when the coordination node device fails, thereby ensuring as much as possible that the transaction will not be rolled back due to the failure of the coordination node device.

[0347] The following summarizes the transaction failure recovery mechanism when failures occur at different times and on different nodes.

[0348] Figure 15 This is a schematic diagram of the principle of a transaction execution process provided by an embodiment of the present application. As shown in 1500, the entire transaction execution process can be divided into the following five stages: ① Read and write stage; ② Preparation stage, but the transaction operation log list ops synchronization is not completed; ③ Preparation stage, but the transaction operation log list ops synchronization is completed; ④ Commit stage, synchronization between the master and slave copies is not completed; ⑤ Commit stage, synchronization between the master and slave copies is completed.

[0349] In the following, Figure 15 Based on the different stages ① to ⑤ of the transaction shown, the transaction failure recovery mechanism when the coordination node device fails is described in detail.

[0350] The coordination node device is responsible for coordinating and managing the entire life cycle of a transaction. Before the end of the entire life cycle of a transaction, the coordination node device may fail at any time. Assuming that at a certain moment, a coordination node device in the distributed database system fails, and the other coordination node devices in the coordination node group where the failed node device is located are all in an active state, then any active node device can take over from the failed node device to continue coordinating the originally executed transaction. The key to such coordination is that the active node device must have the complete operation data and execution status of the transaction. The above operation data and execution status can be identified by the operation log list ops of the transaction. The operation data is reflected as the data record of the database operation, and the execution status is reflected as the prepare operation record and commit operation record.

[0351] Next, when the coordination node device fails, the office is in the above Figure 15 The fault conditions are divided into different stages from ① to ⑤, and different fault recovery strategies are adopted for different situations:

[0352] The transaction is in stage ①. The coordinating node device is coordinating the transaction to perform read and write operations on each master and replica node device. If the coordinating node device fails at this time, the other coordinating node devices do not have complete operation information of the transaction to be recovered (that is, the transaction being executed). That is, since the read and write operations have not been completed, it is impossible to synchronize the full operation log list ops. At this time, other coordinating node devices cannot directly take over the failed node device to continue coordinating the transaction to be recovered. Therefore, it is necessary to notify the client to re-initiate the transaction to be recovered. The new coordinating node device combines the operation information of the transaction to be recovered that has been synchronized, that is, the currently synchronized operation log list ops, and continues to execute the transaction to be recovered from the database operation that has not been executed.

[0353] The transaction is in stage ②. The transaction to be recovered has ended the read-write stage and entered the preparation stage. The full operation log list ops has been generated, but the full operation log list ops has not been fully synchronized between the coordinating node devices. If the coordinating node device fails at this time, it is still necessary to notify the client to re-initiate the transaction to be recovered. The new coordinating node device can obtain the complete operation information of the transaction based on the request statement returned by the client, that is, complete the operation records of the database operations that have not been synchronized in the synchronized operation log list ops, and obtain the full operation log list ops. Then, combined with the metadata of the data shard, that is, the partition information table, the list of primary and secondary nodes participating in the transaction to be recovered can be obtained, so the new coordinating node device can continue to coordinate the transaction.

[0354] The transaction is in phase ③. The coordinating node device is coordinating the transaction to be recovered to perform the Prepare phase of the 2PC algorithm. It has not yet decided whether to commit or abort the transaction to be recovered. Because the operation log list ops must be temporarily stored on at least one other coordinating node device before starting the Prepare phase, the operation log list ops representing the transaction to be recovered has been fully synchronized between the coordinating node devices. If the coordinating node device fails at this time, another coordinating node device is selected from the coordinating node group where the failed node device is located. The complete operation information, i.e., the full operation log list ops, temporarily stored on it can continue to coordinate the transaction to be recovered for two-phase commit.

[0355] When the transaction is in stage ④, the coordinating node device has coordinated the transaction to be recovered to complete the Prepare stage of the 2PC algorithm, and has decided to commit or abort the transaction to be recovered. The full operation log list ops of the transaction to be recovered has also been completely synchronized between the coordinating node devices. If the coordinating node device fails at this time, another coordinating node device is selected in the coordinating node group where the failed node device is located. Through the temporary complete operation information on it, that is, the full operation log list ops, the coordination of the transaction to be recovered can continue to proceed to the Commit stage of the 2PC algorithm.

[0356] When the transaction is in stage ⑤, the coordinating node device has received the synchronization success message (i.e., the submission completion response) returned by all primary and replica node devices. If the coordinating node device fails at this time, the transaction to be recovered is already in the successful submission state, so it does not need to be recovered.

[0357] In general, when a coordination node device fails, if the transaction to be recovered on the failed node device has its full operation log list ops synchronized to other active node devices in the coordination node group, then the active node device containing the full operation log list ops of the transaction to be recovered can take over the coordination work of the failed node device; if the active node device does not store the complete operation information of the transaction to be recovered, that is, the full operation log list ops has not been generated, or the full operation log list ops has been generated but not synchronized, the client needs to resend the request statement of the transaction to be recovered to the new coordination node device, so that through logical redo or other methods, the unsynchronized operation information can be completed in the operation log list ops before the coordination of the transaction can be continued.

[0358] Furthermore, when a coordinating node device fails, other active coordinating node devices need to quickly detect the failure and, as much as possible, continue executing the transactions (i.e., transactions to be recovered) that the failed node device was originally responsible for coordinating. Therefore, a heartbeat mechanism can be used between coordinating node devices to quickly detect failures. In addition, when a transaction enters the Prepare phase of the 2PC algorithm, transaction metadata (i.e., the full operation log list, ops) can be synchronized between coordinating node devices to ensure the high availability of the coordinating node devices.

[0359] Schematically, the process of fault detection and transaction recovery is as follows:

[0360] Fault Sensing: The fault sensing mechanism between coordinating nodes is the same as that between data nodes. Optionally, a Checker thread is created on each coordinating node. This Checker thread periodically sends heartbeat messages to other coordinating nodes to maintain its activity. If other coordinating nodes do not receive a heartbeat message from a coordinating node for a period of time, the coordinating node is considered to have failed. Other active coordinating nodes attempt to take over the coordination of transactions to be recovered from the failed node.

[0361] Schematically, the Checker thread on the coordinating node device periodically calls the Check() function and sends heartbeat messages to other coordinating node devices to maintain the active state. When the current coordinating node device discovers that another coordinating node device has failed, the active coordinating node device can call the txn_recovery() function to attempt to take over the transaction currently executing on the failed node device, i.e., the transaction to be recovered (corresponding to line 6 of the pseudo code of Algorithm 1 below).

[0362] Coordination node device switching: The key to maintaining high availability of coordination node devices is the synchronization of transaction operation information, namely the operation log list ops, between coordination node devices. When other active coordination node devices discover that a coordination node device has failed, they can search locally for the operation information of the transaction to be recovered, such as searching for the synchronization progress parameter txn.complete_ops of the operation log list ops of the transaction to be recovered. The active coordination node device can use the partition information table and the operation log list ops of the transaction to be recovered to restore the data needed to coordinate the transaction to be recovered in memory, including at least the list of master and replica nodes involved in the transaction to be recovered. After the data needed to coordinate the transaction to be recovered is restored, it can be considered that the coordination node device switching process has been completed for the transaction to be recovered.

[0363] Schematically, the active coordinating node device calls the get_backup_txns() function according to the node ID or device ID of the faulty node device to obtain the list {Ti} of transactions being executed on the faulty node device (corresponding to the second line of the pseudocode of Algorithm 2 below), which is equivalent to the new coordinating node device obtaining the list of each transaction to be recovered on the faulty node device.

[0364] Fault recovery: After the active coordination node device has recovered the data needed to coordinate the transaction to be recovered in memory, it can continue to coordinate the transaction to be recovered for operations such as preparation or submission.

[0365] Instructively, for any transaction txn in the above-obtained list of transactions to be recovered {Ti}, when the synchronization progress parameter txn.complete_ops of the operation log list ops is Boolean data, if the synchronization progress parameter txn.complete_ops of the transaction txn is True, it means that the complete operation information of the transaction txn, that is, the full operation log list ops, is stored on the active coordination node device, and the transaction can be directly recovered through the full operation log list ops; if the synchronization progress parameter txn.complete_ops of the transaction txn is False, lse, if the active coordinating node device does not have the complete operation information of the transaction txn, that is, the stored operation log list ops is incomplete, then the active coordinating node device needs to call the request_ops_from_client() function to request the client to send the complete operation information of the transaction txn again, such as requesting to re-initiate the transaction txn, or requesting only the database operation sequence that has not been synchronized. The transaction can be recovered only after the active coordinating node device obtains the complete operation information and completes the full operation log list ops (corresponding to lines 4-9 of the pseudo code of Algorithm 2 below).

[0366] Next, based on the data items read and written by transaction txn recorded in the operation log list ops and the partition information table of the data partition in the coordination node device, the master and replica node devices involved in transaction txn can be obtained, and then the master and replica node devices are added one by one to the master and replica node list txn.datanodes related to transaction txn (corresponding to lines 7-8 of the pseudo code of Algorithm 2 below).

[0367] Next, the active coordinating node device calls the recover() function to recover the transaction txn (corresponding to line 9 of the pseudo code of Algorithm 2 below). Based on the transaction status txn.status of the transaction to be recovered at the time of the failure, the transaction recovery strategy of the transaction txn can be determined:

[0368] If the transaction txn is in the read / write phase at the time of the failure, the failed coordinating node device has not yet coordinated the transaction txn to complete the read / write operations on each master / replica node device. Therefore, the active coordinating node device needs to call the redo_unfinished_ops() function during recovery to continue executing the unfinished read / write operations on the corresponding master / replica node devices before entering the two-phase commit (corresponding to line 3 of the pseudocode of Algorithm 3 below).

[0369] If the transaction txn is in the Prepare phase of the 2PC algorithm at the time of failure, the coordinating node device has not yet decided to commit or abort the transaction txn. Therefore, the active coordinating node device can call the redo_2PC() function during recovery. That is, transaction recovery requires redoing the entire 2PC process (corresponding to line 5 of the pseudo code of Algorithm 3 below).

[0370] If the transaction txn is in the Commit phase of the 2PC algorithm at the time of failure, the coordinating node device has already decided to commit or abort the transaction txn. Therefore, the active coordinating node device can call the redo_commit() function during recovery. That is, transaction recovery only needs to redo the Commit phase in the 2PC algorithm (corresponding to line 7 of the pseudo code of Algorithm 3 below).

[0371] Schematically, the pseudo code for failure recovery of a failed node is as follows:

[0372]

[0373]

[0374] In the above embodiments, combined with the pseudocode of the relevant algorithms, a detailed description is provided of the fault recovery mechanism for when a coordinating node device fails at different times during transaction execution. In this case, another active coordinating node device in the coordinating node group takes over the transaction to be recovered and continues to coordinate the transaction to be recovered. Below, we summarize the fault recovery strategies for different fault timings and locations. Table 1 shows a summary of the fault occurrence scenarios and corresponding fault recovery strategies, as shown in Table 1:

[0375] Table 1

[0376]

[0377] The following will analyze the situation where both the coordination node device and the data node device (ie, the primary and replica node devices) fail, based on the above-mentioned failure recovery process when the coordination node device or the data node device fails alone.

[0378] When both the coordinating node device and the data node device fail, the transactions to be recovered can be divided into three categories based on the device types of the failed node devices involved. Different failure recovery strategies are adopted for different types of transactions to be recovered:

[0379] Considering the transactions to be recovered that only involve data node device failures, since the transactions to be recovered caused by the coordination node device failure only need to switch to the active coordination node device to continue execution, it will not affect the recovery operation of the transactions to be recovered that only involve data node device failures. Therefore, for this type of transactions to be recovered that only involve data node device failures, the fault recovery strategy for the case where only the data node device fails can be used for recovery.

[0380] Considering the transactions to be recovered that only involve the failure of the coordination node device, since the transactions to be recovered caused by the data node device failure can continue to be executed only after the master copy of the data partition involved is switched, it will not affect the recovery operation of the transactions to be recovered that only involve the failure of the coordination node device. Therefore, for this type of transactions to be recovered that only involve the failure of the coordination node device, the fault recovery strategy for the case where only the coordination node device fails can be used for recovery.

[0381] When the transaction to be recovered involves both data node and coordination node failures, it is necessary to consider the impact of both types of failures on the recovery process. The following discussion will be categorized based on the stage (① to ⑤) at which the transaction execution is at the time of the failure:

[0382] When a failure occurs, the transactions to be recovered are in phase ①. The coordinating node is coordinating read and write operations on the various data nodes. After a failure occurs, the other active data nodes and other active coordinating nodes can promptly detect the failure through the heartbeat mechanism. However, the time it takes for the two types of nodes to complete the switchover from the failed node to the active node may differ. Since the read and write operations of the transaction to be recovered have not been completed, the coordinating node device first requests the client to resend the request statement of the transaction to be recovered after the switch is completed. After receiving the request statement returned by the client, it obtains the complete database operation sequence of the transaction to be recovered, and based on the locally synchronized operation log list ops, it compares the two to find the queue of operations to be recovered that were not completed before the failure. At this time, the corresponding data node device is immediately notified to try to execute the read and write operations that were not completed before the failure. However, this process must be executed normally after all relevant data partitions are switched to the primary (that is, the switch from the failed primary copy to the active primary copy is completed). If the data partition involved in a read or write operation is not switched to the primary, the coordinating node device needs to resend the queue of operations to be recovered for the target sub-transaction of the transaction to be recovered on the data partition multiple times until the data partition is switched to the primary and the queue of operations to be recovered for the target sub-transaction is successfully executed. At this time, the target sub-transaction of the transaction to be recovered is successfully recovered. After all the target sub-transactions of the transaction to be recovered are successfully recovered, the entire transaction to be recovered is successfully recovered.

[0383] When the failure occurs, the transaction to be recovered is in phase 2, and the full operation log list ops for the transaction to be recovered has not yet been fully synchronized between the coordinating nodes. After the failure occurs, other active data nodes and other active coordinating nodes can promptly detect the failure through the heartbeat mechanism. The data partition involved in the failure is then switched to the primary. The coordinating node completes the switchover task first and then requests the client's request statement for the transaction to be recovered. Based on the returned request statement, the full operation log list ops is completed. After both processes are completed, the transaction to be recovered is successfully recovered and the two-phase commit process continues.

[0384] When the failure occurred, the pending transaction was in phase ③, and the pending transaction operations were fully synchronized across the coordinating nodes. After the failure, the other active data nodes and other active coordinating nodes were able to promptly detect the failure through the heartbeat mechanism. Both types of nodes promptly switched from the failed node to the active node. After both types of nodes were switched, the pending transaction was successfully recovered and the two-phase commit was repeated.

[0385] When the failure occurred, the transaction to be recovered was in phase ④. The coordinating node had already coordinated the transaction to be recovered, completing the Prepare phase of the 2PC algorithm, and had already decided to commit or abort the transaction. The transaction's operational information, namely the full operation log list (ops), was also fully synchronized between the coordinating nodes. After the failure occurred, the other active data nodes and other active coordinating nodes were able to promptly detect the failure through the heartbeat mechanism. Both types of nodes promptly switched from the failed node to the active node. After both types of nodes were switched, the transaction to be recovered was successfully recovered and the Commit phase of the two-phase commit was resumed.

[0386] When the failure occurs, the transaction to be recovered is in stage ⑤. Since the transaction to be recovered has been successfully submitted, no recovery is required.

[0387] Through the above analysis, it can be seen that under various failure scenarios, the transaction recovery strategy designed in the embodiments of the present application can utilize the information of the client and other active node devices to correctly recover the transaction to be recovered. Therefore, the transaction fast recovery algorithm provided by the embodiments of the present application can redo the transaction that was being executed when the failure occurred, so that the transaction will not be rolled back due to node failure (whether it is a failure of the coordination node device, a failure of the data node device, or a failure of both types of node devices).

[0388] Based on the descriptions of the various embodiments described above, the embodiments of this application, on the one hand, propose a lightweight, transaction-granular replica synchronization mechanism that can improve the situation where replica synchronization affects transaction processing performance, minimize the impact of replica synchronization on transaction performance within the system, and thus ensure the performance of distributed transaction processing. On the other hand, a fast transaction failure recovery algorithm is designed under this lightweight, transaction-granular replica synchronization mechanism if any node fails at any time. This algorithm ensures that transactions will not be rolled back due to node failures, improves the efficiency of transaction redo, and thus improves the availability of the distributed database system.

[0389] Figure 16 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of the present application. Figure 16 As shown, the device is a coordination node device of a distributed database system, and the device includes:

[0390] Determination module 1601, used to determine the master and replica node devices corresponding to the database operations executed in the target transaction;

[0391] A distribution module 1602 is configured to distribute the sub-transactions of the target transaction on the primary and replica node devices to the primary and replica node devices;

[0392] A sending module 1603 is configured to send a prepare request to the master and replica node devices, where the prepare request is used to instruct the master and replica node devices to perform data anomaly detection on the sub-transaction;

[0393] The sending module 1603 is also used to send a commit request to the master replica node device when the transaction commit conditions are met. The commit request is used to instruct the master replica node device to commit the sub-transaction and send the redo log of the sub-transaction to the corresponding slave replica node device.

[0394] The device provided by the embodiment of the present application distributes sub-transactions to the master and replica node devices in a distributed database system. Then, in the preparation phase of the two-phase commit algorithm, the coordinating node device issues a preparation request, which only instructs the master and replica node devices to perform data anomaly detection but does not require data synchronization between the master and slave replicas. After the transaction commit conditions are met and the commit phase is entered, the coordinating node device issues a commit request, which instructs the master and replica node devices to locally commit the sub-transactions and synchronize the redo logs to the slave replica node devices. Therefore, only one round of communication is required in the commit phase to achieve data consistency between the master and slave replicas, thereby greatly reducing the number of synchronizations between the master and slave replicas in the system, compressing the replica synchronization overhead under the multi-replica mechanism, and thus minimizing the adverse effects of the multi-replica mechanism on the transaction processing performance in the system.

[0395] In one possible implementation, the determining module 1601 is configured to:

[0396] Determine the data partition to which the data item corresponding to the database operation belongs;

[0397] Based on the partition information table, the master and replica node devices corresponding to the data partition are queried and obtained. The partition information table is used to record the corresponding relationship between the data partition and the master and replica node devices.

[0398] In one possible implementation, the coordination node device stores an operation log list of the target transaction, where the operation log list includes operation records of database operations currently executed by the target transaction;

[0399] based on Figure 16 The device is composed of a device, which also includes: an adding module for adding an operation record of the database operation executed by the sub-transaction in response to the sub-transaction execution result returned by the master-copy node device, in the operation log list, wherein the operation record represents the operation type of the database operation and the data items involved in the operation.

[0400] In a possible implementation, in the distributed database system, the coordinating node device and at least one other coordinating node device constitute a coordinating node group, and the sending module 1603 is further configured to:

[0401] At intervals of a first target duration, a stored operation log list of at least one transaction is sent to the at least one other coordination node device in the coordination node group.

[0402] In one possible implementation, the sending module 1603 is further configured to:

[0403] When the operation records of the sub-transactions of the target transaction are all added to the operation log list and the operation log list has been synchronized to any other coordination node device, the preparation request is sent to the master-copy node device.

[0404] In one possible implementation, the operation log list is also used to store at least one of the preparation operation record or the submission operation record of the target transaction, where the preparation operation record is used to record the status of the target transaction in the preparation phase, and the submission operation record is used to record the status of the target transaction in the submission phase.

[0405] In a possible implementation, the determining module 1601 is further configured to: if the primary and secondary node devices fail, determine a target node device selected from at least one secondary node device corresponding to the primary and secondary node devices;

[0406] The determination module 1601 is further configured to: determine a target sub-transaction corresponding to the target node device, where the target sub-transaction is a sub-transaction originally executed by the primary and replica node devices but is waiting to be recovered due to a failure;

[0407] The sending module 1603 is further configured to send the to-be-recovered operation queue of the target sub-transaction to the target node device, where the to-be-recovered operation queue includes at least one operation record corresponding to the target sub-transaction in the operation log list.

[0408] In one possible implementation, the target node device is randomly selected from the at least one slave replica node device; or, the target node device is the node device with the lowest load among the at least one slave replica node device.

[0409] In one possible implementation, in the distributed database system, the coordination node device and at least one other coordination node device constitute a coordination node group. If any other coordination node device in the coordination node group fails, the coordination node device takes over the transaction originally being executed on the other coordination node device that failed. Figure 16 The device is composed of:

[0410] A query module is used to query the synchronization progress parameter of the operation log list of any transaction that was originally executed on the other coordination node device that has failed. The synchronization progress parameter is used to indicate whether the coordination node device has synchronized the operation log list of the entire transaction;

[0411] A coordination module, configured to coordinate the transaction based on the synchronized operation log list when the synchronization progress parameter indicates that the operation log list of the entire transaction has been synchronized;

[0412] The coordination module is also used to notify the terminal that initiated the transaction to resend the request statement of the transaction when the synchronization progress parameter indicates that the operation log list of the entire transaction has not been synchronized; and coordinate the transaction based on the request statement returned by the terminal.

[0413] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0414] It should be noted that the transaction processing apparatus provided in the above embodiments uses the division of the aforementioned functional modules as an example only when processing transactions. In actual applications, the aforementioned functions can be assigned to different functional modules as needed, that is, the internal structure of the node device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the transaction processing apparatus provided in the above embodiments and the transaction processing method embodiments are based on the same concept. The specific implementation process is detailed in the transaction processing method embodiments and will not be repeated here.

[0415] Figure 17 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of the present application. Please refer to Figure 17 , the device is a master-copy node device of a distributed database system, and the device includes:

[0416] An execution module 1701 is configured to execute a database operation corresponding to a sub-transaction of a target transaction on the primary and replica node devices in response to the sub-transaction of the target transaction.

[0417] A detection module 1702 is configured to perform data anomaly detection on the sub-transaction in response to the prepare request of the target transaction;

[0418] A commit module 1703 is configured to commit the sub-transaction in response to the commit request of the target transaction;

[0419] The sending module 1704 is configured to send the redo log of the sub-transaction to the corresponding slave replica node device, so that the slave replica node device redoes the sub-transaction when replaying the redo log.

[0420] The device provided by the embodiment of the present application executes the sub-transaction after receiving the sub-transaction distributed by the coordinating node device in a distributed database system, enters the preparation phase of the two-phase commit algorithm when receiving a prepare request, and the master-replica node device only performs data anomaly detection but does not need to synchronize data between the master and slave replicas. When receiving a commit request, it enters the commit phase of the two-phase commit algorithm, and the master-replica node device locally commits the sub-transaction and synchronizes the redo log to the slave replica node device. Therefore, only one round of communication in the commit phase is required to achieve data consistency between the master and slave replicas, thereby greatly reducing the number of synchronizations between the master and slave replicas in the system, compressing the replica synchronization overhead under the multi-replica mechanism, and thus minimizing the adverse effects of the multi-replica mechanism on the transaction processing performance in the system.

[0421] In one possible implementation, when the master replica node device serves as a slave replica node device of another master replica node device, if the other master replica node device fails, the master replica node device is elected as the target node device, based on Figure 17 The device is composed of:

[0422] a receiving module, configured to receive a queue of operations to be recovered of a target sub-transaction sent by any coordinating node device, wherein the target sub-transaction is a sub-transaction originally assigned by the coordinating node device to the other primary and replica node devices for execution but is awaiting recovery due to a failure;

[0423] a determination module configured to determine, based on the queue of operations to be recovered, from the target subtransaction, a first subtransaction that meets the transaction commit condition, a second subtransaction that meets the transaction rollback condition, and a remaining third subtransaction;

[0424] a redo module, configured to redo the first subtransaction and the third subtransaction based on the queue of operations to be recovered;

[0425] The discarding module is configured to discard the operation record associated with the second sub-transaction.

[0426] In one possible implementation, the determining module is configured to:

[0427] In the queue of operations to be recovered, query the preparation operation record of the parent transaction corresponding to any target sub-transaction;

[0428] If the prepare operation record indicates that the parent transaction is in a prepare-completed state during the prepare phase, the target subtransaction is determined as the first subtransaction;

[0429] If the prepare operation record indicates that the parent transaction is in a prepare failure state during the prepare phase, the target subtransaction is determined as a second subtransaction;

[0430] If the prepare operation record indicates that the state of the parent transaction in the prepare phase is neither the prepare complete state nor the prepare fail state, the target subtransaction is determined as the third subtransaction.

[0431] In one possible implementation, based on Figure 17 The redo module includes:

[0432] a first redo unit, configured to redo the first subtransaction based on the queue of operations to be recovered;

[0433] The second redo unit is used to redo the third sub-transaction based on the queue of operations to be recovered when receiving a redo completion instruction sent by any coordination node device in the multiple coordination node groups in the distributed database system. The redo completion instruction is used to indicate that the redo of the first sub-transaction coordinated by the corresponding coordination node group is completed.

[0434] In one possible implementation, the first redo unit is configured to:

[0435] When the target node device has completed replaying the redo log of the first subtransaction, maintaining information required for concurrency control of the first subtransaction and committing the first subtransaction; or

[0436] In a case where the target node device has not yet replayed the redo log of the first subtransaction, at least one operation record corresponding to the first subtransaction is executed based on the queue of operations to be recovered, information required for concurrency control of the first subtransaction is maintained, and the first subtransaction is committed.

[0437] In one possible implementation, the second redo unit is configured to:

[0438] Execute at least one operation record corresponding to the third subtransaction based on the queue of operations to be recovered, and maintain information required for concurrency control of the third subtransaction;

[0439] In response to a commit request for the third subtransaction, commit the third subtransaction, and send a redo log of the third subtransaction to at least one slave replica node device corresponding to the target node device;

[0440] In response to the rollback instruction for the third sub-transaction, the third sub-transaction is rolled back.

[0441] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0442] It should be noted that the transaction processing apparatus provided in the above embodiments uses the division of the aforementioned functional modules as an example only when processing transactions. In actual applications, the aforementioned functions can be assigned to different functional modules as needed, that is, the internal structure of the node device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the transaction processing apparatus provided in the above embodiments and the transaction processing method embodiments are based on the same concept. The specific implementation process is detailed in the transaction processing method embodiments and will not be repeated here.

[0443] Figure 18 This is a schematic diagram of the structure of a node device provided in an embodiment of the present application. The node device 1800 may have relatively large differences due to different configurations or performance. The node device 1800 includes one or more processors (Central Processing Units, CPU) 1801 and one or more memories 1802, wherein the memory 1802 stores at least one computer program, and the at least one computer program is loaded and executed by the one or more processors 1801 to implement the transaction processing methods provided in the above-mentioned embodiments. Optionally, the node device 1800 also has components such as a wired or wireless network interface, a keyboard, and an input and output interface for input and output. The node device 1800 also includes other components for realizing device functions, which are not described here.

[0444] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including at least one computer program. The at least one computer program can be executed by a processor in a node device to implement the transaction processing method described in each of the above embodiments. For example, the computer-readable storage medium includes ROM (Read-Only Memory), RAM (Random-Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage device.

[0445] In an exemplary embodiment, a computer program product or computer program is also provided, including one or more program codes stored in a computer-readable storage medium. One or more processors of a node device can read the one or more program codes from the computer-readable storage medium and execute the one or more program codes, so that the node device can perform the transaction processing method of the above-described embodiment.

[0446] Those skilled in the art will understand that all or part of the steps to implement the above embodiments can be completed by hardware, or can be completed by instructing relevant hardware through a program. Optionally, the program is stored in a computer-readable storage medium. Optionally, the above-mentioned storage medium is a read-only memory, a disk or an optical disk, etc.

[0447] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A transaction processing method, characterized in that: The method is performed by a coordination node device of a distributed database system, and includes: Determine the primary and secondary node devices corresponding to the database operations executed by the target transaction; Distributing the sub-transactions of the target transaction on the master and replica node devices to the master and replica node devices; Sending a prepare request to the master and replica node devices, wherein the prepare request is used to instruct the master and replica node devices to perform data anomaly detection on the sub-transaction; If the transaction commit conditions are met, sending a commit request to the master replica node device, wherein the commit request is used to instruct the master replica node device to commit the sub-transaction and send the redo log of the sub-transaction to the corresponding slave replica node device; If the master and replica node devices fail, the method further includes: Determine a target node device selected from at least one slave node device corresponding to the master and replica node devices; Determine a target sub-transaction corresponding to the target node device, where the target sub-transaction is a sub-transaction originally executed by the primary and replica node devices but waiting to be recovered due to a failure; Sending a to-be-recovered operation queue of the target subtransaction to the target node device, the to-be-recovered operation queue including at least one operation record corresponding to the target subtransaction in the operation log list, so that the target node device determines, from the target subtransaction based on the received to-be-recovered operation queue, a first subtransaction that meets a transaction commit condition, a second subtransaction that meets a transaction rollback condition, and a remaining third subtransaction, and redoes the first subtransaction and the third subtransaction based on the to-be-recovered operation queue; and discards the operation record associated with the second subtransaction.

2. The method according to claim 1, characterized in that The master and replica node devices corresponding to the database operations involved in the target transaction include: Determine the data partition to which the data item corresponding to the database operation belongs; Based on the partition information table, the master and replica node devices corresponding to the data partitions are queried and obtained. The partition information table is used to record the corresponding relationship between the data partitions and the master and replica node devices.

3. The method according to claim 1, characterized in that The coordination node device stores an operation log list of the target transaction, where the operation log list includes operation records of database operations currently executed by the target transaction; After distributing the sub-transactions of the target transaction on the master and replica node devices to the master and replica node devices, the method further includes: In response to the sub-transaction execution result returned by the master-copy node device, an operation record of the database operation executed by the sub-transaction is added to the operation log list, where the operation record represents the operation type of the database operation and the data items involved in the operation.

4. The method according to claim 3, characterized in that In the distributed database system, the coordination node device and at least one other coordination node device constitute a coordination node group, and the method further includes: At intervals of a first target duration, a stored operation log list of at least one transaction is sent to the at least one other coordination node device in the coordination node group.

5. The method according to claim 4, characterized in that The sending of a preparation request to the master and replica node devices includes: When the operation records of the sub-transactions of the target transaction are all added to the operation log list and the operation log list has been synchronized to any other coordination node device, the preparation request is sent to the master and replica node devices.

6. The method according to any one of claims 3 to 5, characterized in that The operation log list is further used to store at least one of the preparation operation record or the submission operation record of the target transaction, the preparation operation record is used to record the status of the target transaction in the preparation stage, and the submission operation record is used to record the status of the target transaction in the submission stage.

7. The method according to claim 1, characterized in that The target node device is randomly selected from the at least one slave replica node device; or, the target node device is the node device with the lowest load among the at least one slave replica node device.

8. The method according to claim 1, characterized in that In the distributed database system, the coordinating node device and at least one other coordinating node device constitute a coordinating node group. If any other coordinating node device in the coordinating node group fails, the coordinating node device takes over the transaction originally executed on the other failed coordinating node device. The method further includes: For any transaction originally being executed on the other coordination node device that has failed, query the synchronization progress parameter of the operation log list of the transaction, where the synchronization progress parameter is used to indicate whether the coordination node device has synchronized the operation log list of the entire transaction; When the synchronization progress parameter indicates that the operation log list of the entire transaction has been synchronized, coordinating the transaction based on the synchronized operation log list; When the synchronization progress parameter indicates that the operation log list of the entire transaction has not been synchronized, the terminal that initiated the transaction is notified to resend the request statement of the transaction; and the transaction is coordinated based on the request statement returned by the terminal.

9. A transaction processing method, characterized in that: The method is executed by a master and replica node device of a distributed database system, and includes: In response to a sub-transaction of the target transaction on the primary and replica node devices, executing a database operation corresponding to the sub-transaction; In response to a prepare request of the target transaction, performing data anomaly detection on the sub-transaction; Committing the sub-transaction in response to a commit request of the target transaction; Sending the redo log of the sub-transaction to the corresponding slave replica node device, so that the slave replica node device redoes the sub-transaction when replaying the redo log; When the master replica node device serves as a slave replica node device of another master replica node device, if the other master replica node device fails, the master replica node device is elected as the target node device, the method further includes: Receive a to-be-recovered operation queue of a target sub-transaction sent by any coordinating node device, where the target sub-transaction is a sub-transaction originally assigned by the coordinating node device to the other primary and replica node devices for execution but is waiting to be recovered due to a failure; Based on the queue of operations to be recovered, determining, from the target subtransaction, a first subtransaction that meets a transaction commit condition, a second subtransaction that meets a transaction rollback condition, and a remaining third subtransaction; Based on the queue of operations to be recovered, the first sub-transaction and the third sub-transaction are redone; and operation records associated with the second sub-transaction are discarded.

10. The method according to claim 9, characterized in that The determining, based on the queue of operations to be recovered, from the target subtransaction, a first subtransaction that meets a transaction commit condition, a second subtransaction that meets a transaction rollback condition, and a remaining third subtransaction includes: In the queue of operations to be recovered, query the preparation operation record of the parent transaction corresponding to any target sub-transaction; If the prepare operation record indicates that the parent transaction is in a prepare-completed state during the prepare phase, determining the target subtransaction as the first subtransaction; If the prepare operation record indicates that the parent transaction is in a prepare failure state during the prepare phase, determining the target subtransaction as a second subtransaction; If the prepare operation record indicates that the state of the parent transaction in the prepare phase is neither a prepare complete state nor a prepare failed state, the target subtransaction is determined to be the third subtransaction.

11. The method according to claim 9 or 10, characterized in that Redoing the first sub-transaction and the third sub-transaction based on the to-be-recovered operation queue includes: Redoing the first subtransaction based on the queue of operations to be recovered; Upon receiving a redo completion instruction sent by any coordination node device in the multiple coordination node groups in the distributed database system, the third sub-transaction is redone based on the queue of operations to be recovered. The redo completion instruction is used to indicate that the redo of the first sub-transaction coordinated by the corresponding coordination node group is completed.

12. The method according to claim 11, characterized in that Redoing the first sub-transaction based on the to-be-recovered operation queue includes: When the target node device has completed replaying the redo log of the first subtransaction, maintaining information required for concurrency control of the first subtransaction and committing the first subtransaction; or In a case where the target node device has not yet replayed the redo log of the first subtransaction, based on the queue of operations to be recovered, at least one operation record corresponding to the first subtransaction is executed, information required for concurrency control of the first subtransaction is maintained, and the first subtransaction is committed.

13. The method according to claim 11, characterized in that The redoing of the third sub-transaction based on the to-be-recovered operation queue includes: executing, based on the queue of operations to be recovered, at least one operation record corresponding to the third subtransaction, and maintaining information required for concurrency control of the third subtransaction; In response to a commit request for the third subtransaction, commit the third subtransaction, and send a redo log of the third subtransaction to at least one slave replica node device corresponding to the target node device; In response to the rollback instruction for the third sub-transaction, the third sub-transaction is rolled back.

14. A transaction processing device, characterized in that: The device is a coordination node device of a distributed database system, and the device includes: A determination module, configured to determine the primary and secondary node devices corresponding to the database operations executed by the target transaction; A distribution module, configured to distribute the sub-transactions of the target transaction on the master and replica node devices to the master and replica node devices; A sending module, configured to send a prepare request to the master and replica node devices, wherein the prepare request is used to instruct the master and replica node devices to perform data anomaly detection on the sub-transaction; The sending module is further configured to send a commit request to the master replica node device when a transaction commit condition is met, wherein the commit request is used to instruct the master replica node device to commit the sub-transaction and send the redo log of the sub-transaction to the corresponding slave replica node device; The determination module is further configured to determine, if a failure occurs in the primary and secondary node devices, a target node device selected from at least one secondary node device corresponding to the primary and secondary node devices; The determining module is further configured to determine a target sub-transaction corresponding to the target node device, where the target sub-transaction is a sub-transaction originally executed by the primary and replica node devices but waiting to be recovered due to a failure; The sending module is further configured to send a to-be-recovered operation queue of the target sub-transaction to the target node device, the to-be-recovered operation queue including at least one operation record corresponding to the target sub-transaction in the operation log list, so that the target node device determines, based on the received to-be-recovered operation queue, a first sub-transaction that meets a transaction commit condition, a second sub-transaction that meets a transaction rollback condition, and a remaining third sub-transaction from the target sub-transaction, and redoes the first sub-transaction and the third sub-transaction based on the to-be-recovered operation queue; and discards the operation record associated with the second sub-transaction.

15. The device according to claim 14, characterized in that The determining module is used for: Determine the data partition to which the data item corresponding to the database operation belongs; Based on the partition information table, the master and replica node devices corresponding to the data partitions are queried and obtained. The partition information table is used to record the corresponding relationship between the data partitions and the master and replica node devices.

16. The device according to claim 14, characterized in that The coordination node device stores an operation log list of the target transaction, where the operation log list includes operation records of database operations currently executed by the target transaction; The device further comprises: An adding module is used to add an operation record of the database operation executed by the sub-transaction in the operation log list in response to the sub-transaction execution result returned by the master-copy node device, wherein the operation record represents the operation type of the database operation and the data items involved in the operation.

17. The device according to claim 16, characterized in that In the distributed database system, the coordination node device and at least one other coordination node device constitute a coordination node group, and the sending module is further configured to: At intervals of a first target duration, a stored operation log list of at least one transaction is sent to the at least one other coordination node device in the coordination node group.

18. The device according to claim 17, characterized in that The sending module is further used for: When the operation records of the sub-transactions of the target transaction are all added to the operation log list and the operation log list has been synchronized to any other coordination node device, the preparation request is sent to the master and replica node devices.

19. The device according to any one of claims 16 to 18, characterized in that The operation log list is further used to store at least one of the preparation operation record or the submission operation record of the target transaction, the preparation operation record is used to record the status of the target transaction in the preparation stage, and the submission operation record is used to record the status of the target transaction in the submission stage.

20. The device according to claim 14, characterized in that The target node device is randomly selected from the at least one slave replica node device; or, the target node device is the node device with the lowest load among the at least one slave replica node device.

21. The device according to claim 14, characterized in that In the distributed database system, the coordinating node device and at least one other coordinating node device constitute a coordinating node group. If any other coordinating node device in the coordinating node group fails, the coordinating node device takes over the transaction originally executed on the other coordinating node device that has failed. The apparatus further includes: a query module, configured to query a synchronization progress parameter of an operation log list of any transaction originally being executed on the other coordination node device that has failed, wherein the synchronization progress parameter is used to indicate whether the coordination node device has synchronized the operation log list of the entire transaction; A coordination module, configured to coordinate the transaction based on the synchronized operation log list when the synchronization progress parameter indicates that the operation log list of the entire transaction has been synchronized; The coordination module is further configured to notify the terminal that initiated the transaction to resend the request statement of the transaction when the synchronization progress parameter indicates that the operation log list of the entire transaction has not been synchronized; and coordinate the transaction based on the request statement returned by the terminal.

22. A transaction processing device, characterized in that: The device is a master-replica node device of a distributed database system, and the device includes: An execution module, configured to execute a database operation corresponding to a sub-transaction of a target transaction on the primary and replica node devices in response to the sub-transaction of the target transaction; a detection module, configured to perform data anomaly detection on the sub-transaction in response to a prepare request of the target transaction; a commit module, configured to commit the sub-transaction in response to a commit request of the target transaction; A sending module, configured to send the redo log of the sub-transaction to a corresponding slave replica node device, so that the slave replica node device redoes the sub-transaction when replaying the redo log; When the master replica node device serves as a slave replica node device of another master replica node device, if the other master replica node device fails, the master replica node device is elected as the target node device, the apparatus further includes: A receiving module, configured to receive a queue of operations to be recovered of a target sub-transaction sent by any coordinating node device, wherein the target sub-transaction is a sub-transaction originally assigned by the coordinating node device to the other primary and replica node devices for execution but is waiting to be recovered due to a failure; a determination module configured to determine, based on the queue of operations to be recovered, from the target subtransactions, a first subtransaction that meets a transaction commit condition, a second subtransaction that meets a transaction rollback condition, and a remaining third subtransaction; a redo module, configured to redo the first sub-transaction and the third sub-transaction based on the queue of operations to be recovered; A discarding module is configured to discard the operation record associated with the second sub-transaction.

23. The device according to claim 22, characterized in that The determining module is used for: In the queue of operations to be recovered, query the preparation operation record of the parent transaction corresponding to any target sub-transaction; If the prepare operation record indicates that the parent transaction is in a prepare-completed state during the prepare phase, determining the target subtransaction as the first subtransaction; If the prepare operation record indicates that the parent transaction is in a prepare failure state during the prepare phase, determining the target subtransaction as a second subtransaction; If the prepare operation record indicates that the state of the parent transaction in the prepare phase is neither a prepare complete state nor a prepare failed state, the target subtransaction is determined to be the third subtransaction.

24. The device according to claim 22 or 23, characterized in that The redo module includes: a first redo unit, configured to redo the first subtransaction based on the queue of operations to be recovered; The second redo unit is used to redo the third sub-transaction based on the queue of operations to be recovered when a redo completion instruction is received from any coordination node device in the multiple coordination node groups in the distributed database system, and the redo completion instruction is used to indicate that the redo of the first sub-transaction coordinated by the corresponding coordination node group is completed.

25. The device according to claim 24, characterized in that The first redo unit is used for: When the target node device has completed replaying the redo log of the first subtransaction, maintaining information required for concurrency control of the first subtransaction and committing the first subtransaction; or, In a case where the target node device has not yet replayed the redo log of the first subtransaction, based on the queue of operations to be recovered, at least one operation record corresponding to the first subtransaction is executed, information required for concurrency control of the first subtransaction is maintained, and the first subtransaction is committed.

26. The device according to claim 24, characterized in that The second redo unit is used for: executing, based on the queue of operations to be recovered, at least one operation record corresponding to the third subtransaction, and maintaining information required for concurrency control of the third subtransaction; In response to a commit request for the third subtransaction, commit the third subtransaction, and send a redo log of the third subtransaction to at least one slave replica node device corresponding to the target node device; In response to the rollback instruction for the third sub-transaction, the third sub-transaction is rolled back.

27. A node device, characterized in that: The node device includes one or more processors and one or more memories, wherein at least one computer program is stored in the one or more memories, and the at least one computer program is loaded and executed by the one or more processors to implement the transaction processing method according to any one of claims 1 to 8 or claims 9 to 13.

28. A storage medium, characterized in that The storage medium stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the transaction processing method according to any one of claims 1 to 8 or claims 9 to 13.

29. A computer program product, characterized in that The computer program product includes at least one computer program, and the at least one computer program is loaded and executed by a processor to implement the transaction processing method according to any one of claims 1 to 8 or claims 9 to 13.

Images