A method and system for distributed transaction processing of asymmetric multi-replicas

Abstract

The application relates to the technical field of database partitioning, in particular to a distributed transaction processing method and system of asymmetric multi-copy, a plurality of copy tables of a data table are divided into a plurality of partitions according to different partitioning methods, the partitions of the plurality of copy tables are obtained, the plurality of partitions are unevenly distributed on a plurality of data nodes, and the data of the main table is reconstructed by the shard data in the plurality of partitions of the same copy table; the asymmetric multi-copy mechanism has the advantages of a data partitioning system and a non-partitioning system and a query optimization mechanism; the data can be recovered through the Raft mechanism to ensure the safety of the data; the Raft mechanism can guarantee the data consistency between the main table and the plurality of copy tables; meanwhile, the transaction conflict problem can be solved in the cross-copy transaction, and the global order of the transaction is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of database partitioning, and particularly relates to a distributed transaction processing method and system of asymmetric multi-copy. BACKGROUND

[0002] A distributed database must partition and store data tables in a distributed manner, and in order to meet the requirements of data high availability and scalability, the data tables need to be replicated in multiple copies. Partitioning is mainly for scalability, and different partitions are allocated to different CPUs or different nodes on a distributed system. Therefore, large data sets can be distributed across multiple processors or nodes, and query loads can be distributed across multiple processors or nodes. For queries running on a single partition, each node can independently execute queries on itself. Multi-copy replication of a database is mainly for high availability, that is, the same data copy is replicated to different processors or different nodes according to a certain strategy to obtain fault tolerance and read performance level scalability. Therefore, as long as there is one available data copy, the data can be recovered, and by distributing to different processors or nodes, the same data can be simultaneously accessed by external access on multiple processors or nodes. However, large and complex queries may span multiple partitions or multiple nodes for parallel processing, and data access between multiple partitions becomes an important factor affecting system performance, especially the additional data network transmission cost caused by the two-phase transaction commit of distributed transactions.

[0003] At present, the partition multi-copy mechanism of most distributed database systems adopts a symmetric multi-copy mechanism, that is, the primary data and the copy data of the database table adopt the same data partition algorithm, and each partition copy is allocated to multiple processors or multiple nodes according to the same strategy. The symmetric multi-copy mechanism makes the transaction consistency processing of the distributed system simple, all data partitions have idempotency, data partition multi-copies also have idempotency, transaction scheduling and processing have the same consistency, the primary data partition and the corresponding copy partition data are exactly the same, the data partitions are evenly distributed to different processors or nodes, and the distributed transaction processing across partitions or nodes becomes very inefficient, and the additional data transmission across nodes or partitions in the two-phase transaction commit of the distributed system is inevitable. (Lu, et al., 2019) proposed a non-symmetric multi-copy replication mechanism, which effectively improved the distributed transaction processing performance of the distributed system. The non-symmetric copy replication mechanism realizes a mechanism in which full data nodes and partial data nodes coexist, and the full data copy node converges all partitions of the same data table and is allocated on one node of the cluster. However, the partial data copy node only contains part of the data partition copy, which can be either a primary partition or a secondary index partition. In this way, for cross-partition transaction query problems, the full data node is allocated for processing without the need for distributed transaction processing across partitions or nodes, especially for the two-phase transaction commit of the distributed system, which eliminates the performance bottleneck of distributed transaction processing. For single-copy transactions, parallel queries can be performed on the corresponding data partitions of multiple partial copy nodes, improving system performance. However, this non-symmetric data copy mechanism requires the same partition method for data tables and data copies, only the node allocation method of the data partition copy is different. For OLTP and OLAP mixed transactions, multi-index partitioning, and data re-partitioning, the non-symmetric multi-copy replication mechanism cannot be optimized. SUMMARY

[0004] Therefore, the purpose of the present application is to provide a non-symmetric multi-copy distributed transaction processing method and system that can solve the technical problems raised in the background art.

[0005] The non-symmetric multi-copy distributed transaction processing method of the present application comprises the following steps:

[0006] A plurality of copy tables of a data table are divided into several partitions according to different partition methods, obtaining the partitions of the plurality of copy tables, and the plurality of partitions of the copy tables are unevenly distributed on different data nodes, the full table data of the same copy table can be reconstructed by the plurality of partition data of the same copy table, or can be reconstructed by the partition data of other copy tables;

[0007] The primary table and the plurality of copy tables adopt different partition methods and index methods to adapt to different data query tasks;

[0008] The copy table of the master table and the copy table of the partition adopt different data query tasks and different index modes;

[0009] The master table and the plurality of copy tables maintain consistency through a Raft consensus algorithm;

[0010] The transaction of the same partition follows a serialization mechanism, and the timestamp of the transaction is provided by a hybrid logical clock (HLC), and the logical sequence of different transactions is ensured by using a transaction ID with global increment;

[0011] The transaction across different partitions uses a copy or a master table with full data for transaction processing.

[0012] Further, the master table adopts an OLTP transaction query task, and the plurality of copy partitions adopt an OLAP analysis query task; the master table adopts a primary key index, and the copy table adopts a secondary key index.

[0013] Further, the data consistency between the master table and the plurality of copy tables is achieved through an asymmetric copy Raft;

[0014] The transaction operation of all data of the master table, the copy table, and the partition of the copy table is initiated on the leader of the Raft of the master table, the copy table, and the partition of the copy table;

[0015] The asymmetric copy Raft is composed of virtual nodes of the leaders of the partition Rafts related to each copy table, and the virtual nodes are associated with the leaders of all partition Rafts of the related copy table; a plurality of virtual nodes constitute an asymmetric copy Raft.

[0016] Further, the data consistency between the master table and the plurality of copy tables is achieved through a symmetric copy Raft;

[0017] Each partition of the master table or the copy table has a corresponding Raft copy distributed in the same system cluster, and the leader of each Raft copy is registered in the virtual node of the corresponding copy table.

[0018] Further, the hybrid logical clock (HLC) includes two parts of WallTime and LogicTime, WallTime is the maximum physical time known by the node, if the physical time is less than or equal to WallTime, LogicTime is incremented by one on the basis of the original; if the physical time is greater than WallTime, LogicTime is reset to zero, and all HLC times are WallTime.LogicTime, which is abbreviated as HLC=Wt.Lt, then:

[0019] HLC1 >= HLC2 = Wt1.Lt1 >= Wt2.Lt2 = Wt1 > Wt2 | Wt1 = Wt2 & Lt1 >= Lt2

[0020] The message exchange between nodes is accompanied by the HLC time obtained when the message is generated, and when any node receives a message sent by another node, the WallTime of the current node and the LogicTime of the opposite node are added one;

[0021] If the WallTime of the opposite node is the largest, the LogicTime of the opposite node is added one;

[0022] If the WallTime of the local node is the largest, the LogicTime of the local node is added one;

[0023] The HLC time of the new event is updated to the local and used as the HLC time of the local event.

[0024] Further, the virtual node of any replica table receives the HLC time obtained when the message generated by the leader node associated with the replica virtual node is generated;

[0025] When the virtual node receives the message sent by all associated leader nodes, the maximum value of the HLC time of all associated leader nodes is taken as the HLC time of the virtual node, that is,

[0026] HLC VN = MAX{HLC1, HLC2, HLC3...}

[0027] Similarly, the HLC time of the virtual node cluster is taken as the maximum value of the HLC time of all virtual nodes as the HLC time of the current system.

[0028] Further, when the transaction of each replica table starts, the transaction coordinator thread creates a unique transaction ID, that is, UUID, and takes a timestamp as the commit timestamp of the transaction;

[0029] The transaction coordinator randomly allocates a transaction priority to the transaction, and when a transaction conflict occurs, the priorities of the two transactions are compared, and the one with the higher priority continues to execute, and the transaction with the lower priority is restarted;

[0030] The priority of the restarted transaction is improved.

[0031] The application also provides a non-symmetric multi-copy distributed transaction processing system, comprising a plurality of data nodes, each of which is used for storing all or part of data shards in a database table; the primary table, replica table or partition of all tables in the database is randomly allocated to different data nodes.

[0032] Further, the system is based on a Share-Nothing distributed system architecture.

[0033] Further, the data node is a general data node or a virtual node.

[0034] The beneficial effects of the present application are that the asymmetric multi-copy distributed transaction processing method and system of the present application:

[0035] (1) has the advantages of data partition systems and non-partition systems and query optimization mechanisms through the asymmetric multi-copy mechanism;

[0036] (2) can restore data through the Raft mechanism to ensure data security;

[0037] (3) can ensure data consistency between the master table and multiple copy tables through the Raft mechanism;

[0038] (4) can solve transaction conflict problems and ensure global transaction order in cross-copy transactions. BRIEF DESCRIPTION OF DRAWINGS

[0039] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope, and for those skilled in the art, other related drawings can also be obtained without creative labor:

[0040] Figure 1 It is a schematic diagram of the asymmetric copy distributed transaction processing system architecture of the present application;

[0041] Figure 2 It is a schematic diagram of the asymmetric copy data allocation mode of the present application;

[0042] Figure 3 It is a schematic diagram of the asymmetric copy multi-level Raft consensus mechanism of the present application;

[0043] Figure 4 It is a schematic diagram of the full table or partitioned Raft copy distributed architecture of the present application. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the following will combine the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are some of the embodiments of the present application, not all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0045] Therefore, the following detailed description of the embodiments of the application provided in the accompanying drawings is not intended to limit the scope of the application claimed, but merely represents selected embodiments of the application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor are within the scope of protection of the present application.

[0046] It should be noted that similar reference numbers and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. Meanwhile, in the description of the present application, the terms "first", "second", etc. are only used to distinguish the description, and cannot be understood as indicating or implying relative importance.

[0047] It should be noted that in this paper, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such process, method, article or device.

[0048] The asymmetric multi-copy distributed transaction processing system of the embodiment is based on a Share-Nothing distributed system architecture and is composed of N data nodes Node. In the database architecture design, there are mainly SharedEverthting, SharedNothing, and SharedDisk:

[0049] SharedNothing means that each processing unit has its own private CPU / memory / hard disk, etc., and there is no shared resource, similar to the MPP (massively parallel processing) mode, and the processing units communicate with each other through a protocol, and have better parallel processing and expansion capabilities. Typical representatives are DB2DPF and hadoop, each node is independent of each other, and each node processes its own data, and the processed results can be aggregated to the upper layer or transferred between nodes;

[0050] Each data node Node stores all or part of the data shards of the database table.

[0051] The data node Node here is a general data node, which can be a virtual node (such as a VoltDB CPU core-based partition virtual node) or an independent physical node.

[0052] AsFigure 1 As shown, this system consists of N data nodes, which collectively store the full data of three tables T1, T2, and T3, as well as the sharded data of each table. Specifically, data node Node 1 stores the full data of table T1, the sharded data T2.P1 of table T2, and the sharded data T3.P1 of table T3.

[0053] Data node Node2 stores the full table of table T2, the shard T1.P1 of table T1, and the shard data T3.P2 of table T3;

[0054] Other data nodes, Node3-NodeN, store similar data distribution structures.

[0055] The master tables of all tables in the database are randomly assigned to different nodes. The master tables are unsharded data tables such as T1 and T2.

[0056] To ensure even data distribution across different data nodes, various strategies can be employed. This invention is not limited to specific data distribution algorithms and strategies; general data distribution algorithms and strategies are suitable for distributing data across different nodes in this invention. Similarly, the partitioned data of each table replica follows the same data distribution algorithm and strategy.

[0057] For clarity and simplicity, it is assumed that the entire data of each single table can be stored on a single node; for example, the entire data of table T1 can be stored on data node Node1. When the total data of a single table exceeds the capacity of a single node, a strategy can be employed to partition the large table into large partitions that can be stored on a single node. Each large partition can be treated as a single table. For instance, if the total capacity of table T1 exceeds the storage capacity of data node Node1, T1 can be first divided into multiple partitions, each of which can be accommodated on a single node. Based on these partitions, data partitioning and allocation are performed using the asymmetric data replication distribution pattern described above. Therefore, this invention also defines an asymmetric data replication distribution architecture that allows for flexible table partitioning based on node capacity.

[0058] When defining a database table, it is necessary to determine the appropriate data partitioning method and specify the data storage nodes. The corresponding DML expression is as follows:

[0059] CREATE REPLICA <replica table name>LINK <primary table name>

[0060] PARTITION BY <Partition KEY>

[0061] HASH<number of partitions>|

[0062] RANGES(range1,range2,range3,…)|

[0063] PARTITIONS (partition1, partition2, partition3,...)

[0064] AT (node1, node2, node3,...)

[0065] Therefore, the present application defines an asymmetric multi-copy data distributed allocation mode, that is, the master table and its copy table of the same table can adopt different data partitioning methods and are unevenly distributed on different data nodes Node. Here, the data node Node is a general data node, which can be a virtual node, such as a VoltDB CPU core-based partition virtual node, or an independent physical node.

[0066] As shown in Figure 2 , the master table T1 and its two copy tables R1 and R2;

[0067] The copy table R1 is divided into three non-overlapping partitions T1.R1.P1, T1.R1.P2 and T1.R1.P3;

[0068] The copy table R2 is divided into six non-overlapping partitions T1.R2.P1, T1.R2.P2, T1.R2.P3, T1.R2.P4, T1.R2.P5 and T1.R2.P6.

[0069] In the distributed database system, the T1 master table and its three partitions T1.R1.P1, T1.R1.P2 and T1.R1.P3 of the copy table R1 and the six partitions T1.R2.P1-T1.R2.P6 of the copy table R2 are unevenly distributed to different nodes.

[0070] Obviously,

[0071] Therefore, the T1 master table data can be reconstructed by merging and reconstructing the partition T1.R1.P1, T1.R1.R1.P2 and T1.R1.R1.R1.P3 of the copy table R1, or by merging and reconstructing the six partitions T1.R2.P1-T1.R2.P6 of the copy table R2;

[0072] Of course, the data partitioning of the copy tables R1 and R2 can also be reconstructed by T1 master table data partitioning and mutual re-partitioning and merging of R1 and R2. Of course, the T1 master table data can be further partitioned and distributed to different distributed nodes.

[0073] It can be seen that the application defines a general data asymmetric copy partition and a distributed data allocation method of asymmetric copy partition. For example, as shown in the example analysis, the master table T1 and the copy tables R1 and R2 each use different data sharding methods to partition the respective data, and the data copy partitions are unevenly distributed to different nodes.

[0074] For the sake of simplicity and clarity, the following examples only use the master table T1 and its copy tables T1.P1, T1.P2 and T1.P3 for example.

[0075] The data table partition method can be a random partition, a Hash partition, a range partition, etc. It can also be a primary key partition or a secondary key partition. At the same time, it can also be split according to business functions, and the data belonging to the same Bounded Context in the business domain is placed together to form a data partition storage and copy mode suitable for different business types. Common relational database data sharding methods include row aggregation partitioning, column aggregation partitioning and row-column hybrid partitioning methods.

[0076] Different data copies can adapt to different data query tasks. For example, OLTP transaction data query tasks can be directly executed on the master copy, while OLAP analysis query tasks can be executed in parallel on the partition copy to improve efficiency.

[0077] For different index methods of data tables, there are primary key indexes and secondary key indexes. The application can use different index methods for data sharding of different copies, for example, the master copy can use primary key index sharding, and other copies can use different secondary key index sharding. Therefore, different data queries can execute query tasks on different data copies.

[0078] Similarly, if the data query needs to cross different partitions, it can be directly executed on the full table data copy, while the single partition query task can be directly executed within the partition.

[0079] As can be seen, the asymmetric multi-copy mechanism has the advantages of data partition systems and non-partition systems and query optimization mechanisms.

[0080] At the same time, the application provides two mechanisms to ensure the consistency and security of the master data and the copy data, specifically including an asymmetric copy mechanism and a symmetric copy mechanism.

[0081] The asymmetric copy mechanism of the application can effectively guarantee high reliability between the main data and the copy data. As long as one data copy remains complete, the damage of other copy data can be recovered through the data copy, thereby improving the security and reliability of system data. Meanwhile, as long as two copy data do not have overlapping data failure or error at the same time, data repair can be performed through mutual data. However, if the two copy data have overlapping data damage or failure at the same time, the system data cannot be completely recovered. In addition, the data consistency between the asymmetric copies is difficult to guarantee. For a high-reliability database system, the security and reliability of each copy itself are guaranteed, and the data recovery ability with data consistency is also guaranteed.

[0082] The application designs a hybrid data consensus mechanism-Hybrid-Raft for the asymmetric copy data distribution system architecture to process the data consistency problem of distributed transactions. The hybrid data consensus mechanism-Hybrid-Raft of the application is asymmetric copy Raft and symmetric copy Raft of each copy partition. The asymmetric copy Raft processes the data consistency transaction between asymmetric copies, and the symmetric copy Raft of the copy partition processes the data consistency transaction between symmetric copies of the copy partition.

[0083] (1) Asymmetric multi-copy Raft

[0084] As shown in Figure 3 , the main table and the copy table of each table must guarantee data consistency. The T1 main table and the copy tables R1 and R2 of T1 adopt different data partition methods to unevenly distribute the respective data to different data nodes. The T1 main table and the copy tables R1 and R2 guarantee data consistency through asymmetric copy Raft. All data read operations can be matched to different data copies according to the business type of the respective operation data to perform data read operations, but the data write operation will become more complex.

[0085] The application designs that all data transaction operations must return to the Leader of the asymmetric multi-copy Raft to initiate a write operation, and the asymmetric multi-copy Raft mechanism guarantees the data consistency of distributed transaction processing between asymmetric multi-copies. Raft first elects a unique Leader, and the Leader is responsible for managing the log. All data table addition and state change operations are completed through the Leader. The Leader accepts the log request of the user and distributes the log to other nodes in the system. When the Leader drops, Raft elects a new Leader.

[0086] The composition of the asymmetric replica Raft is composed of the leaders of the partition symmetric replica Raft related to each data replica. The leader of the T1 master table raft is associated with the virtual node T1.VN corresponding to the T1 master table, while the virtual node R1.VN corresponding to the T1 replica R1 is associated with the leader of the raft corresponding to all partitions of R1. Similarly, the virtual node R2.VN corresponding to the T1 replica R2 is associated with the leader of the raft corresponding to all partitions of R2. Multiple replica virtual nodes VN constitute an asymmetric replica Raft.

[0087] (2) Symmetric multi-replica Raft

[0088] As shown in Figure 4 , each table master or replica table partition has a corresponding raft replica, which is distributed in the same system cluster, and the corresponding raft replica is as shown in Figure 4 . Compared with the above asymmetric replica Raft, this kind of Raft is a symmetric replica Raft, that is, the data partition related to Raft is the same. For example, the raft replicas of the T1 master table are allocated to data nodes Node1, Node2 and Node3.

[0089] Similarly, the raft replicas of the partition P1 of the T2 replica table are also allocated to data nodes Node1, Node2 and Node3, and the raft replicas of the partition P2 of the T3 replica table are allocated to data nodes Node1, Node2 and NodeN.

[0090] Other data has a similar raft replica mechanism. The leader of each symmetric replica Raft must be registered in the corresponding replica table virtual node. For example, the leader of the T1 master table Raft must be registered to T1.VN, and the leader of the Raft of the partition T2.P1 of the T2 replica table must also be registered to the virtual node T2.PVN; similarly, the Raft leaders of the T2 replica partitions T2.P2 and T2.P3 also need to be registered to the virtual nodes T2.PVN corresponding to the T2 replica.

[0091] Asymmetric replica MVCC distributed transaction processing: simply consider a distributed database with only one table T1, and the asymmetric multi-replica data distribution system architecture can be abstracted as the coexistence of multiple independent T1 replica Raft clusters. As shown in Figure 3As shown, there are three independent Raft clusters, a T1 master table Raft cluster, a T1 replica table R1 partition Raft cluster, and a T1 replica table R2 partition Raft cluster. Each Raft cluster can be abstracted as a virtual node VirtualNode (VN). For a distributed database, transactions must be distributed on different replicas and executed in parallel. Therefore, the execution of a transaction can be on different replicas. This results in two conflicting transactions that can be executed independently on different replicas. Therefore, two-phase locking 2PL transaction conflict detection must be cross-replica.

[0092] The present application is based on an asymmetric replica hybrid RAFT data consensus mechanism, and implements a multi-replica transaction serializability mechanism through multi-version concurrency control MVCC. The present application obtains a transaction TID, i.e., a transaction timestamp, based on a hybrid logical clock HLC. Each data record in the database maintains a transaction ID-TID, which is the transaction TID of the latest record modified. Through this transaction TID, it can be detected whether the current committed transaction conflicts with other transactions. This transaction TID is obtained when a transaction is confirmed, and is based on a hybrid logical clock HLC.

[0093] Transaction timestamp TID based on hybrid logical clock HLC

[0094] The present application uses an HLC algorithm to provide a clock, thereby obtaining a confirmed transaction timestamp TID. The hybrid logical clock HLC mixes a physical clock PT and a logical clock LC. The HLC time is composed of two parts, WallTime generated by the physical clock PT and LogicTime generated by the logical clock LC. WallTime is the current known maximum physical time obtained by the node, and the order of two events is determined by first judging WallTime and then judging LogicTime.

[0095] When assigning an HLC time to an event generated by a local node, the WallTime part takes the maximum value of the current WallTime and the current physical time.

[0096] If the physical time is less than or equal to WallTime, LogicTime is incremented by one based on the original; if the physical time is greater than WallTime, LogicTime is reset to zero.

[0097] All HLC times are WallTime.LogicTime, abbreviated as HLC=Wt.Lt, then:

[0098] HLC1≥HLC2≡Wt1.Lt1≥Wt2.Lt2≡Wt1>Wt2|Wt1=Wt2&Lt1≥Lt2

[0099] The message exchange between nodes will be accompanied by the HLC time obtained when the message is generated. When any node receives a message sent by other nodes, the maximum value of the current node's WallTime, the WallTime of the peer HLC and the local physical time is taken.

[0100] If the three are equal, the maximum value of the current node's LogicTime and the peer LogicTime is taken plus one;

[0101] If the peer WallTime is the maximum, the peer LogicTime is taken plus one;

[0102] If the local WallTime is the maximum, the local LogicTime is taken plus one;

[0103] The new HLC time is updated to the local and used as the HLC time of the next local event.

[0104] In summary, WallTime represents the maximum physical time that the current node can perceive when the event occurs, while LogicTime represents the order of two events when WallTime is the same. The HLC algorithm can guarantee the following characteristics:

[0105] For events A, B, if HLC.A < HLC.B is met, then event A must occur before event B, that is, A precedes B.

[0106] WallTime must satisfy WallTime ≥ Node.pt. Node.pt is the local physical time of the node. HLC will only increase and will not be rolled back due to fluctuations in physical time.

[0107] If it is found that WallTime > Node.pt, then there must be an event X that has occurred to push the HLC of the current node forward.

[0108] WallTime-Node.pt is bounded, which must be less than a value ε. For any two events A and B, if A precedes B, then there must exist B.pt + ε ≥ A.pt. The size of the convergence bias ε will affect the conflict decision of the transaction.

[0109] HLC can meet the needs of global snapshot. This is because when an HLC is used as a snapshot time point, this time will cause all node HLCs to advance, so the events occurring after this time are not visible to the snapshot, thus ensuring the safety and effectiveness of the snapshot reading.

[0110] Any replica of a virtual node VN will receive the HLC time taken when the message from the associated leader node is produced. When the replica receives the message from all associated leader nodes, it takes the maximum of all the HLC times as the HLC time of the virtual node, i.e.

[0111] HLC VN = MAX{HLC1, HLC2, HLC3...}

[0112] Similarly, the HLC time of the virtual node cluster is the maximum of all the HLC times of the virtual nodes.

[0113] Therefore, a confirmed transaction TID is based on the next HLC time of the current HLC time of the virtual node cluster. Obviously, the confirmed transaction TID has global order, which guarantees the global order of transactions.

[0114] Specifically, all transaction parameters include UUID, TID, priority, and state (pending, aborted, committed).

[0115] The records in each replica partition can achieve the MVCC mechanism by recording + PID + priority. MVCC makes read-only transactions and read-write transactions not interfere with each other.

[0116] When a transaction starts, the transaction coordinator thread creates a unique transaction ID (UUID), and takes a timestamp TID as the commit timestamp of the transaction, which may be modified due to transaction conflicts. The coordinator randomly assigns a transaction priority, which is useful in transaction conflict arbitration, and the priority of the transaction may also change due to transaction restart. When a transaction conflict occurs, the priorities of the two transactions are compared, the high-priority transaction continues to execute, and the low-priority transaction is restarted. The priority of the restarted transaction will also be raised to avoid being always in competition and eventually being "starved". When restarted, the current transaction is stopped and a new transaction is started, at which time the initial PID and priority of the transaction may change. However, to the user, it is just a transaction.

[0117] Transaction atomicity

[0118] The initial state of the transaction is PENDING, all writes in the transaction process are written to the corresponding partition in the form of PID+priority, and when all records participating in the transaction are prepared success, the coordinator thread only needs to modify the state of the transaction record to COMMITED to return to the client, the modification of a single record raft can be guaranteed, and the atomicity of the transaction is guaranteed.

[0119] Two-phase transaction

[0120] The present application is a lock-free two-phase commit transaction model based on the transaction TID MVCC, and transaction conflicts are returned to the client as soon as possible by transaction restart or rollback for the client to decide the next step.

[0121] The specific execution process of the two-phase transaction of the present application is as follows:

[0122] Transaction records are generated, and the transaction state is PENDING, that is, BeginTransactoin.

[0123] The participating nodes write data in the form of WRITEPID+priority and return the candidate timestamp.

[0124] The maximum timestamp in the candidate timestamp and the transaction start timestamp are compared to determine whether the transaction state is modified to COMMITED or ABORTED, and the transaction isolation level. The SI isolation level can tolerate the inconsistency between the candidate and the commit timestamp, but for the SSI isolation level transaction, if the candidate and the commit timestamp are not equal, the transaction is restarted.

[0125] After the transaction is committed / rolled back, the residual WRITEPID+priority will be asynchronously cleaned up.

[0126] Finally, it should be pointed out that the above embodiments are only used to illustrate the technical solutions of the present application and are not limiting, although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced by equivalents without departing from the purpose and scope of the technical solutions of the present application, and they should be covered in the scope of the claims of the present application.

Claims

1. A method for distributed transaction processing of asymmetric multi-replicas, the method comprising: The method comprises the steps of: A plurality of copy tables of a data table are divided into a plurality of partitions according to different partition methods, and the plurality of partitions of the copy tables are unevenly distributed on different data nodes, and the full table data of the same copy table can be reconstructed by the plurality of partition data of the same copy table or by the partition data of other copy tables; The master table and the plurality of copy tables adopt different partition methods and index modes to adapt to different data query tasks; The master table and the plurality of copy tables maintain consistency through the Raft consensus algorithm; The same partition transaction follows a serialization mechanism, the transaction timestamp is provided by a hybrid logical clock HLC, and the use of a transaction ID with global increment ensures the logical sequence of different transactions; The transaction across different partitions uses a copy or master table with full data for transaction processing; The data consistency between the master table and the plurality of copy tables is realized through asymmetric copy Raft; The transaction operation of all data of the master table, the copy table and the partition of the copy table is initiated on the leader of the master table, the copy table and the partition Raft of the copy table; The asymmetric copy Raft is composed of virtual nodes formed by the leaders of the partition Rafts related to each copy table, and the virtual nodes are associated with the leaders of all partition Rafts of the related copy table; a plurality of virtual nodes constitute an asymmetric copy Raft; The data consistency between the master table and the plurality of copy tables is realized through symmetric copy Raft; Each partition of the master table or copy table has a corresponding Raft copy distributed in the same system cluster, and the leader of each Raft copy is registered in the virtual node of the corresponding copy table; The hybrid logical clock HLC includes WallTime and LogicTime, WallTime is the maximum physical time known by the node, if the physical time is less than or equal to WallTime, LogicTime is one more than the original; if the physical time is greater than WallTime, LogicTime is zero, and all HLC times are WallTime.LogicTime, abbreviated as HLC=Wt.Lt, then: HLC1≥HLC2≡Wt1.Lt1≥Wt2.Lt2≡Wt1>Wt2|Wt1=Wt2&Lt1≥Lt2 The exchange of messages between nodes is accompanied by the HLC time obtained when the message is generated, when any node receives the message sent by the other node, the WallTime of the current node and the LogicTime of the other node are taken; If the WallTime of the other node is the largest, the LogicTime of the other node is taken; If the WallTime of the local node is the largest, the LogicTime of the local node is taken; The HLC time of the new event is updated to the local node and used as the HLC time of a local event; The virtual node of any copy table will receive the HLC time obtained when the message is generated by the leader node associated with the copy virtual node; The virtual node takes the maximum value of the HLC time of all associated Leader nodes as the HLC time of the virtual node when receiving the messages sent by all associated Leader nodes, i.e. HLC VN = MAX{HLC1, HLC2, HLC3...} Similarly, the HLC time of the virtual node cluster takes the maximum value of the HLC time of all virtual nodes as the HLC time of the current system.

2. The method of claim 1, wherein: The OLTP transaction query task is used on the master table, and the OLAP analysis query task is used on the multiple-copy partition; the master table uses a primary key index, and the replica table uses a secondary key index.

3. The method of claim 1, wherein: When the transaction of each replica table starts, a transaction coordinator thread creates a unique transaction ID, i.e. UUID, and takes a timestamp as the commit timestamp of the transaction; The transaction coordinator randomly assigns a transaction priority to the transaction, and when a transaction conflict occurs, the priorities of the two transactions are compared, the one with the higher priority continues to execute, and the one with the lower priority is restarted; The priority of the restarted transaction is promoted.

4. A distributed transaction processing system implementing the method of distributed transaction processing of asymmetric multiple copies according to claim 1, characterized in that: The system comprises a plurality of data nodes, each of which is used to store all or part of data shards in a database table; the master table, replica table or partition of all tables in the database are randomly assigned to different data nodes.

5. The distributed transaction processing system of claim 4, wherein: The system is based on a Share-Nothing distributed system architecture.

6. The distributed transaction processing system of claim 4, wherein: The data nodes are general data nodes or virtual nodes.

Images