CN112182103A - Distributed database and method for realizing cross-node transaction strong consistency - Google Patents
Distributed database and method for realizing cross-node transaction strong consistency Download PDFInfo
- Publication number
- CN112182103A CN112182103A CN202011016270.3A CN202011016270A CN112182103A CN 112182103 A CN112182103 A CN 112182103A CN 202011016270 A CN202011016270 A CN 202011016270A CN 112182103 A CN112182103 A CN 112182103A
- Authority
- CN
- China
- Prior art keywords
- transaction
- data
- node
- participants
- commit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/275—Synchronous replication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a distributed database and a method for realizing cross-node transaction strong consistency, wherein the distributed database adopts a framework with separated storage and calculation, and comprises the following steps: the distributed database introduces a transaction negotiation and transaction compensation mechanism among the data nodes as participants, and when a local system failure causes that the participants cannot normally receive a transaction control message of the coordination node as the coordinator, the transactions are judged to be submitted or rolled back through mutual state confirmation among the participants so as to avoid the problem of data inconsistency.
Description
Technical Field
The invention relates to the technical field of distributed databases, in particular to a distributed database and a method for realizing cross-node transaction strong consistency.
Background
Distributed database management systems are an important part of distributed systems in practical applications. Database management systems were widely used since the eighties of the last century, where initially the databases were deployed on one computer and all transactions were processed in this one stand-alone database. With the rapid expansion of the data volume and the service volume, a single machine cannot meet the requirements of data storage and data processing capacity, and a distributed database system becomes a preferred framework for various application deployments. For a database, a transaction is a vital capability, and ACID properties of the transaction, namely atomicity, consistency, isolation and durability, are generally required to be satisfied. Compared with a stand-alone database, the difficulty of supporting the ACID in a distributed environment is high, and faults such as message delay, loss, node failure or network partitioning can affect the correct execution of the transaction, so that data inconsistency, damage or loss and the like are caused. Therefore, the correctness of the transaction in the distributed environment is ensured, and the method has important significance for the large-scale application of the transaction in the real environment.
Two-phase Commit (2 PC for short) is a common solution for distributed transactions, i.e. the Commit process of a transaction is divided into Two phases to be processed: a preparation phase and a commit phase. The initiator of the transaction is called Coordinator (Coordinator) and the executor of the transaction is called Participant (Participant). The core idea of the algorithm is as follows: and the participants inform the coordinator of the success or failure of the transaction operation, and the coordinator uniformly records the operation results of all the participants and indicates the participants to carry out final submission or rollback according to the results. One of the main problems with this algorithm is: due to a single point of failure of the coordinating node, or a local network problem, some participants may not receive the transaction control message of the coordinator, resulting in data inconsistency between nodes.
In response to the problem in the two-phase Commit scheme, there is also a three-phase Commit scheme that introduces a timeout mechanism in the coordinator and participants and adds a Pre-Commit phase in the prepare phase. In the algorithm, when a transaction enters a real commit stage, if a participant cannot receive a commit or rollback command sent by both coordination due to a coordination node or network failure, the participant will continue to execute transaction commit after waiting for timeout, and therefore, one of the defects of the algorithm is that the problem of data consistency still cannot be solved.
Disclosure of Invention
In order to overcome the defects of the prior art, the invention aims to provide a distributed database and a method for realizing strong consistency of cross-node transactions thereof, which judge whether a transaction should be submitted or rolled back through mutual state confirmation among participants by introducing a transaction negotiation and transaction compensation mechanism among the participants under the condition that the participants cannot normally receive transaction control messages of the coordinator due to local system failure, thereby effectively avoiding the problem of data inconsistency.
To achieve the above and other objects, the present invention provides a distributed database, which employs a framework with separate storage and computation, and comprises: the distributed database introduces a transaction negotiation and transaction compensation mechanism among the data nodes as participants, and when a local system fault causes that the participants cannot normally receive transaction control information of the coordination nodes as the coordinators, the transactions are confirmed through mutual states among the participants, so that the transactions are judged to be submitted or rolled back, and the problem of data inconsistency is avoided.
Preferably, the data nodes include a master data node and slave data nodes, each master data node has a plurality of slave data nodes, the master data node synchronizes data to the slave nodes through synchronization logs, the cataloging nodes also include a master node and a slave node, and the coordinating node has no slave node.
Preferably, in the Pre-Commit phase, the coordination node packs the information of all participants and issues the information to all related participants in the Pre-Commit command.
Preferably, a timeout time is set for the transaction, and if no expected transaction operation instruction is received within the timeout time, the participants communicate with each other to perform transaction state negotiation according to a transaction negotiation mechanism.
Preferably, the transaction negotiation mechanism is as follows:
if one participant is in the rolling or backing state, the transaction should be rolled back;
if there is one participant in the COMMIT state, the transaction should COMMIT.
Preferably, after confirming the state of the transaction on each participant through the transaction negotiation, each participant needs to compensate the transaction locally according to a transaction compensation mechanism.
Preferably, for the case that the coordinator is normal and the participants are abnormal, the transaction compensation mechanism is as follows:
if the participated data nodes are abnormal in the preparation stage, the coordinating node cannot receive the reply of preparation submission, and the coordinating node does not send the submission command but sends a rollback command to other participated data nodes; and after recovery, the abnormal data node performs rollback through negotiation to other participating data nodes according to a transaction negotiation mechanism.
If the participated data node is abnormal in the commit stage, judging whether the participated data node should be committed or not by acquiring the transaction state from other participated data nodes according to the transaction negotiation mechanism after the participated data node is recovered, and making corresponding action.
Preferably, for the case that the coordinator is abnormal, the participants are normal, or both the coordinator and the participants are abnormal, the transaction compensation mechanism is as follows:
if the data nodes are abnormal before the preparation stage, none of the participating data nodes receives a preparation submission command, and all the data nodes are in a DOING state after recovery and need to roll back the transaction;
if the data nodes are abnormal after the preparation phase, all the data nodes participating in the transaction are in a WAIT-COMMIT state after being recovered, and the transaction should be submitted after all the data nodes participating in the transaction carry out transaction state negotiation according to a transaction negotiation mechanism;
if the data node in the COMMIT or rollback phase is abnormal, part of the data nodes participating in the transaction may have already been committed or rolled back, and the node in the WAIT-COMMIT state performs a corresponding COMMIT or rollback action after performing transaction state negotiation according to a transaction negotiation mechanism.
In order to achieve the above object, the present invention further provides a method for implementing strong consistency of cross-node transactions of a distributed database, comprising the following steps:
step S1, the coordinating node initiates the start, submit or rollback instruction of the affair to each data node;
step S2, when the system has a local failure and the data node as a participant cannot normally receive the transaction control message of the coordinating node as a coordinator, a transaction negotiation and transaction compensation mechanism between the participants is introduced, and whether the transaction should be committed or rolled back is determined by the mutual state confirmation between the participants, so as to avoid the problem of data inconsistency.
Preferably, in step S1, in the Pre-Commit phase, the coordinator packages the information of all participants and issues the packaged information to all relevant participants in the Pre-Commit command.
Compared with the prior art, the distributed database and the method for realizing the cross-node transaction strong consistency thereof of the invention judge whether the transaction should be submitted or rolled back through the mutual state confirmation of the transaction negotiation between the participants under the condition that the system has a local fault and the participants cannot normally receive the transaction control message of the coordinator by introducing the transaction negotiation and the transaction compensation mechanism between the participants, and compensate the transaction locally, thereby effectively avoiding the problem of data inconsistency, ensuring the strong consistency of the transaction and ensuring the correctness of business logic.
Drawings
FIG. 1 is a system architecture diagram of a distributed database according to the present invention;
FIG. 2 is a diagram illustrating successful execution of a transaction in accordance with an embodiment of the present invention;
FIG. 3 is a diagram illustrating transaction failure rollback in an embodiment of the present invention;
FIG. 4 is a diagram illustrating a transaction state switch of a data node according to an embodiment of the present invention;
FIG. 5 is a flowchart of the steps of a method for achieving strong consistency of distributed database across node transactions according to the present invention.
Detailed Description
Other advantages and capabilities of the present invention will be readily apparent to those skilled in the art from the present disclosure by describing the embodiments of the present invention with specific embodiments thereof in conjunction with the accompanying drawings. The invention is capable of other and different embodiments and its several details are capable of modification in various other respects, all without departing from the spirit and scope of the present invention.
Before explaining the present invention in detail, some concepts and terms related to the present invention will be introduced:
one, two phase commit, comprising:
Pre-Commit phase: all transaction operations have been successfully performed, ready to commit
And a Commit stage: performing a true commit, releasing lock resources associated with a transaction, etc
Second, transaction state
DOING: the transaction is in progress and no ready-to-commit command has been received
WAIT-COMIMT: the node has received the ready-to-commit command and confirmed that it can commit
COMMITTED: the transaction has committed
ROLLBACKED: the transaction has rolled back
FIG. 1 is a system architecture diagram of a distributed database according to the present invention. As shown in fig. 1, the distributed database of the present invention adopts a framework with separate storage and computation, and includes three different types of nodes: the data management system comprises a coordination node, a data node and a cataloging node, wherein the coordination node is responsible for distributing requests to the data nodes needing to participate, the data node is responsible for accessing and storing data, the cataloging node stores system metadata and partition related information, and each type of node can be horizontally expanded. In order to ensure the high reliability of the system, each main data node is provided with a plurality of slave data nodes, the main data node synchronizes data to the slave nodes through a synchronization log, the catalogue nodes also comprise main nodes and slave nodes, and the coordination nodes do not keep states and do not have slave nodes because of only intermediate operation processing. In the system architecture, a transaction is initiated by a coordinating node and issued to one or more data node groups for operation, the coordinating node is equivalent to the coordinator in the prior art, the data node is equivalent to the participant in the prior art, the transaction operation is only issued to a main node in the data node group, the distributed database introduces a transaction negotiation and transaction compensation mechanism among the participants, and when the participant cannot normally receive a transaction control message of the coordinator due to local failure of the system, the transaction is judged to be submitted or rolled back through mutual state confirmation among the participants so as to avoid the problem of data inconsistency.
In a normal work flow, the coordinating node uniformly initiates the start, submission or rollback instruction of the transaction to each data node. After the transaction operation is completed, the coordinating node issues a commit instruction, each data node performs final preparation before submission, then returns a successful response to the coordinating node, the coordinating node issues the commit instruction after receiving successful responses ack of all the data nodes, and each data node completes the transaction submission after receiving the instruction, wherein the process is shown in fig. 2; if any data node returns an error in the precompimit stage, the coordinating node issues a rollback instruction to all data nodes, and after receiving the instruction, each data node rolls back the transaction, and the process is shown in fig. 3.
In the whole transaction execution process, the data node enters different states according to the current execution stage: the transaction enters a DOING state in the execution process, enters a WAIT-COMMIT state after receiving the preCommit and successfully completing the preparation of submission, enters a COMMITTED state when the transaction is submitted, and enters a ROLLBACKED state when the transaction is rolled back. The state transition is shown in fig. 4.
In the invention, in order to avoid that each participant can not determine the transaction state due to the failure of part of nodes, a negotiation mechanism among the participants is provided. A timeout time may be set for the transaction within which the participants may communicate with each other for transaction state negotiation without receiving the desired transaction operation instructions. Based on the state transition conclusion of the data node, the transaction negotiation mechanism between the participants is as follows:
if one participant is in the rolling or backing state, the transaction should be rolled back;
second, if there is one participant in the COMMIT state, the transaction should COMMIT.
In order to enable transaction state coordination among the participants, each participant needs to know the information of the other participants involved in the transaction. Therefore, in the invention, in the Pre-Commit stage, the coordinator packs the information of all participants and issues the information to all related participants in the Pre-Commit instruction, therefore, as long as the participants successfully receive the information, the information of other participants can be known.
After confirming the state of the transaction on each participant through negotiation, each participant needs to compensate the transaction locally (if completed, the transaction is not needed), and the transaction compensation mechanism of the invention is as follows:
firstly, for the case that the coordinator is normal and the participants are abnormal:
1. if the participated data nodes are abnormal in the preparation stage, the coordinating node cannot receive the reply of preparation submission, and the coordinating node does not send the submission command but sends a rollback command to other participated data nodes; and after recovery, the abnormal data node performs rollback through negotiation to other participating data nodes according to a transaction negotiation mechanism. Specifically, when the coordinating node issues the rollback instruction, the data node is in the backing state before processing, and is in the rolled state after processing, so that the negotiation result between the abnormal data node and other participants is that the transaction should be rolled back.
2. If the participated data node is abnormal in the commit stage, after the participated data node is recovered, whether the participated data node should be committed can be judged by acquiring the transaction state from other participated data nodes according to the transaction negotiation mechanism, and corresponding action is taken. If the data node A is abnormal in the COMMIT stage, the data node A negotiates with the data nodes B, C and D respectively after the data node A returns to normal, the data node A is processed according to the transaction states of the data nodes B, C and D, and the data node A COMMITs as long as one of the data nodes B, C and D is a COMMIT, and the data node A does not involve a coordinating node but processes the data node A by itself.
Secondly, for the case that the coordinator is abnormal, the participants are normal, or both the coordinator and the participants are abnormal:
1. if the exception is made before the prepare phase, none of the participating data nodes receives the prepare commit command, and all data nodes are in the DOING state after recovery, so that the transaction is rolled back. The narrative states that no coordination is required between data nodes in the DOING state, because in the case where a data node is in the DOING state, no response message for the Pre-Commit must be sent to the coordinating node.
2. If the data nodes participating in the transaction are abnormal after the preparation phase, all the data nodes participating in the transaction are in a WAIT-COMMIT state (can be determined according to a transaction log) after recovery, and the transaction should be submitted after all the data nodes participating in the transaction negotiate the transaction state according to a transaction negotiation mechanism.
3. If the data nodes participating in the transaction are abnormal in the COMMIT or rollback phase and may already COMMIT or rollback, the nodes in the WAIT-COMMIT state perform corresponding COMMIT or rollback actions after performing transaction state negotiation according to the transaction negotiation mechanism.
FIG. 5 is a flowchart of the steps of a method for achieving strong consistency of distributed database across node transactions according to the present invention. As shown in fig. 5, the method for implementing strong consistency of cross-node transactions of a distributed database according to the present invention includes the following steps:
step S1, the coordinating node initiates the start, commit or rollback instruction of the transaction to each data node in a unified manner. Specifically, after the transaction operation is completed, the coordinating node issues a commit instruction, each data node performs final preparation before submission, then returns a successful response to the coordinating node, the coordinating node issues the commit instruction after receiving successful responses ack of all the data nodes, and each data node completes the transaction submission after receiving the instruction.
Step S2, when the system has a local failure and the data node as a participant cannot normally receive the transaction control message of the coordinating node as a coordinator, a transaction negotiation and transaction compensation mechanism between the participants is introduced, and whether the transaction should be committed or rolled back is determined by the mutual state confirmation between the participants, so as to avoid the problem of data inconsistency.
Preferably, in order to enable transaction state coordination between the participants, each participant needs to know the information of the other participants involved in the transaction. Therefore, in step S1, in the Pre-Commit phase, the coordinator needs to package the information of all participants and issue the packaged information to all relevant participants in the Pre-Commit command, so that the participants can know the information of other participants as long as they successfully receive the message.
In order to avoid that each participant can not determine the transaction state due to the failure of part of nodes, a transaction negotiation mechanism among the participants is provided. Preferably, in step S2, a timeout period is set for the transaction, and in case that no expected transaction operation command is received within the timeout period, the participants can communicate with each other to perform transaction status negotiation. Based on the state transition conclusion of the data node, the transaction negotiation mechanism between the participants is as follows:
if one participant is in the rolling or backing state, the transaction should be rolled back;
second, if there is one participant in the COMMIT state, the transaction should COMMIT.
After the transaction status of each participant is confirmed through transaction negotiation between the participants, each participant needs to compensate the transaction locally (if the transaction status is completed, the transaction compensation mechanism is specifically as follows:
firstly, for the case that the coordinator is normal and the participants are abnormal:
1. if the participated data nodes are abnormal in the preparation stage, the coordinating node cannot receive the reply of preparation submission, and the coordinating node does not send the submission command but sends a rollback command to other participated data nodes; and the abnormal data nodes roll back after recovery by negotiating with other participating data nodes according to a transaction negotiation mechanism.
2. If the participated data node is abnormal in the commit stage, after the participated data node is recovered, whether the participated data node should be committed can be judged by acquiring the transaction state from other participated data nodes according to the transaction negotiation mechanism, and corresponding action is taken.
Secondly, for the case that the coordinator is abnormal, the participants are normal, or both the coordinator and the participants are abnormal:
1. if the exception is made before the prepare phase, none of the participating data nodes receives the prepare commit command, and all data nodes are in the DOING state after recovery, so that the transaction is rolled back.
2. If the data nodes are abnormal after the preparation phase, all the data nodes participating in the transaction are in the WAIT-COMMIT state after recovery, and the transaction should be submitted after all the data nodes participating in the transaction negotiate the transaction state according to a transaction negotiation mechanism.
3. If the data nodes participating in the transaction are abnormal in the COMMIT or rollback phase and may already COMMIT or rollback, the nodes in the WAIT-COMMIT state perform corresponding COMMIT or rollback actions after performing transaction state negotiation according to the transaction negotiation mechanism.
In summary, the distributed database and the method for implementing strong consistency of cross-node transactions thereof in the present invention introduce a transaction negotiation and transaction compensation mechanism between participants, and determine whether a transaction should be submitted or rolled back through mutual state confirmation of transaction negotiation between the participants when a system local failure occurs, which results in that the participants cannot normally receive transaction control messages of the coordinator, and compensate the transaction locally, thereby effectively avoiding the problem of data inconsistency, ensuring strong consistency of transactions, and ensuring correctness of business logic.
The foregoing embodiments are merely illustrative of the principles and utilities of the present invention and are not intended to limit the invention. Modifications and variations can be made to the above-described embodiments by those skilled in the art without departing from the spirit and scope of the present invention. Therefore, the scope of the invention should be determined from the following claims.
Claims (10)
1. A distributed database employing a framework that is separate from storage and computation, comprising: the distributed database introduces a transaction negotiation and transaction compensation mechanism among the data nodes as participants, and when a local system fault causes that the participants cannot normally receive transaction control information of the coordination nodes as the coordinators, the transactions are confirmed through mutual states among the participants, so that the transactions are judged to be submitted or rolled back, and the problem of data inconsistency is avoided.
2. The distributed database of claim 1, wherein: the data nodes comprise a master data node and slave data nodes, each master data node comprises a plurality of slave data nodes, the master data node synchronizes data to the slave nodes through synchronization logs, the cataloging nodes also comprise a master node and slave nodes, and the coordinating node has no slave nodes.
3. The distributed database of claim 1, wherein: in the Pre-Commit stage, the coordinating node packs the information of all participants and issues the information to all related participants in the Pre-Commit instruction.
4. The distributed database of claim 3, wherein: setting a timeout time for the transaction, and if the expected transaction operation instruction is not received within the timeout time, the participants communicate with each other to carry out transaction state negotiation according to a transaction negotiation mechanism.
5. The distributed database of claim 4, wherein the transaction negotiation mechanism is as follows:
if one participant is in the rolling or backing state, the transaction should be rolled back;
if there is one participant in the COMMIT state, the transaction should COMMIT.
6. The distributed database of claim 5, wherein: after confirming the state of the transaction on each participant through transaction negotiation, each participant needs to compensate the transaction locally according to a transaction compensation mechanism.
7. The distributed database of claim 6, wherein for the case where the coordinator is normal and the participants are abnormal, the transaction compensation mechanism is as follows:
if the participated data nodes are abnormal in the preparation stage, the coordinating node cannot receive the reply of preparation submission, and the coordinating node does not send the submission command but sends a rollback command to other participated data nodes; and after recovery, the abnormal data node performs rollback through negotiation to other participating data nodes according to a transaction negotiation mechanism.
If the participated data node is abnormal in the commit stage, judging whether the participated data node should be committed or not by acquiring the transaction state from other participated data nodes according to the transaction negotiation mechanism after the participated data node is recovered, and making corresponding action.
8. The distributed database of claim 6, wherein for the case where the coordinator is abnormal, the participants are normal, or both the coordinator and the participants are abnormal, the transaction compensation mechanism is as follows:
if the data nodes are abnormal before the preparation stage, none of the participating data nodes receives a preparation submission command, and all the data nodes are in a DOING state after recovery and need to roll back the transaction;
if the data nodes are abnormal after the preparation phase, all the data nodes participating in the transaction are in a WAIT-COMMIT state after being recovered, and the transaction should be submitted after all the data nodes participating in the transaction carry out transaction state negotiation according to a transaction negotiation mechanism;
if the data node in the COMMIT or rollback phase is abnormal, part of the data nodes participating in the transaction may have already been committed or rolled back, and the node in the WAIT-COMMIT state performs a corresponding COMMIT or rollback action after performing transaction state negotiation according to a transaction negotiation mechanism.
9. A method for realizing cross-node transaction strong consistency of a distributed database comprises the following steps:
step S1, the coordinating node initiates the start, submit or rollback instruction of the affair to each data node;
step S2, when the system has a local failure and the data node as a participant cannot normally receive the transaction control message of the coordinating node as a coordinator, a transaction negotiation and transaction compensation mechanism between the participants is introduced, and whether the transaction should be committed or rolled back is determined by the mutual state confirmation between the participants, so as to avoid the problem of data inconsistency.
10. The method of claim 9, wherein the method comprises the steps of: in step S1, in the Pre-Commit stage, the coordinator packages the information of all participants and issues the packaged information to all relevant participants in the Pre-Commit command.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011016270.3A CN112182103A (en) | 2020-09-24 | 2020-09-24 | Distributed database and method for realizing cross-node transaction strong consistency |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011016270.3A CN112182103A (en) | 2020-09-24 | 2020-09-24 | Distributed database and method for realizing cross-node transaction strong consistency |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112182103A true CN112182103A (en) | 2021-01-05 |
Family
ID=73955465
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011016270.3A Pending CN112182103A (en) | 2020-09-24 | 2020-09-24 | Distributed database and method for realizing cross-node transaction strong consistency |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112182103A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113297173A (en) * | 2021-05-24 | 2021-08-24 | 阿里巴巴新加坡控股有限公司 | Distributed database cluster management method and device and electronic equipment |
| CN113420035A (en) * | 2021-02-05 | 2021-09-21 | 阿里巴巴集团控股有限公司 | Data processing method, system, device, electronic equipment and computer storage medium |
| CN114116144A (en) * | 2022-01-24 | 2022-03-01 | 北京万里开源软件有限公司 | Lightweight global transaction manager and control method thereof |
| CN114722062A (en) * | 2022-05-05 | 2022-07-08 | 北京理工大学 | Self-adaptive distributed transaction submission method |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110196760A (en) * | 2018-07-12 | 2019-09-03 | 腾讯科技（深圳）有限公司 | Distributed transaction consistency implementation method and device |
| CN110795506A (en) * | 2019-10-23 | 2020-02-14 | 广州巨杉软件开发有限公司 | Distributed database management method and device based on distributed logic timestamp |
-
2020
- 2020-09-24 CN CN202011016270.3A patent/CN112182103A/en active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110196760A (en) * | 2018-07-12 | 2019-09-03 | 腾讯科技（深圳）有限公司 | Distributed transaction consistency implementation method and device |
| CN110795506A (en) * | 2019-10-23 | 2020-02-14 | 广州巨杉软件开发有限公司 | Distributed database management method and device based on distributed logic timestamp |
Non-Patent Citations (2)
| Title |
|---|
| 巨杉数据库官方文档V3.4: "二阶段提交", 《HTTP://DOC.SEQUOIADB.COM/CN/SEQUOIADB-CAT_ID-1600139301-EDITION_ID-304》 * |
| 追梦男生: "【SequoiaDB】4 巨杉数据库SequoiaDB整体架构", 《HTTPS://WWW.CNBLOGS.COM/ALEN-LIU-SZ/P/12975566.HTML》 * |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113420035A (en) * | 2021-02-05 | 2021-09-21 | 阿里巴巴集团控股有限公司 | Data processing method, system, device, electronic equipment and computer storage medium |
| CN113297173A (en) * | 2021-05-24 | 2021-08-24 | 阿里巴巴新加坡控股有限公司 | Distributed database cluster management method and device and electronic equipment |
| CN113297173B (en) * | 2021-05-24 | 2023-10-31 | 阿里巴巴新加坡控股有限公司 | Distributed database cluster management method and device and electronic equipment |
| CN114116144A (en) * | 2022-01-24 | 2022-03-01 | 北京万里开源软件有限公司 | Lightweight global transaction manager and control method thereof |
| CN114116144B (en) * | 2022-01-24 | 2022-07-26 | 北京万里开源软件有限公司 | Lightweight global transaction manager and control method thereof |
| CN114722062A (en) * | 2022-05-05 | 2022-07-08 | 北京理工大学 | Self-adaptive distributed transaction submission method |
| CN114722062B (en) * | 2022-05-05 | 2024-07-02 | 北京理工大学 | Self-adaptive distributed transaction submitting method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112182103A (en) | Distributed database and method for realizing cross-node transaction strong consistency | |
| US9940183B2 (en) | Commit-one-phase distributed transactions with multiple starting participants | |
| US6889253B2 (en) | Cluster resource action in clustered computer system incorporation prepare operation | |
| CN105988862A (en) | Distributed transaction processing method and device | |
| CN102073540A (en) | Distributed affair submitting method and device thereof | |
| US20130132458A1 (en) | System and method for managing participant order in distributed transactions | |
| CN115098229A (en) | Transaction processing method, device, node equipment and storage medium | |
| CN105701159A (en) | Data synchronization device and method | |
| WO2009081657A1 (en) | Node system, server switching method, server device, and data transfer method | |
| US6873987B1 (en) | Method, system and program products for recovering from failures within a shared nothing distributed computing environment | |
| CN112148436B (en) | Decentralised TCC transaction management method, device, equipment and system | |
| US20090193286A1 (en) | Method and System for In-doubt Resolution in Transaction Processing | |
| US20090193280A1 (en) | Method and System for In-doubt Resolution in Transaction Processing | |
| CN109361777A (en) | Synchronous method, synchronization system and the relevant apparatus of distributed type assemblies node state | |
| CN110427427B (en) | Method for realizing global transaction distributed processing through pin bridging | |
| CN113905054B (en) | RDMA (remote direct memory access) -based Kudu cluster data synchronization method, device and system | |
| CN112596801A (en) | Transaction processing method, device, equipment, storage medium and database | |
| CN113297173B (en) | Distributed database cluster management method and device and electronic equipment | |
| US20240211488A1 (en) | Transaction commitment systems, methods, and apparatuses based on distributed database systems | |
| CN113726828B (en) | High concurrency trusted blockchain system and method supporting micro-services | |
| WO2015196692A1 (en) | Cloud computing system and processing method and apparatus for cloud computing system | |
| WO2022206426A1 (en) | Distributed transaction processing method and system, and related device | |
| CN107181608A (en) | A kind of method and operation management system for recovering service and performance boost | |
| CN114050989A (en) | Distributed test execution method based on cloud computing technology | |
| CN113918654A (en) | Block data submitting method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210105 |
|
| RJ01 | Rejection of invention patent application after publication |