CN114579406A - Method and device for realizing consistency of distributed transactions - Google Patents
Method and device for realizing consistency of distributed transactions Download PDFInfo
- Publication number
- CN114579406A CN114579406A CN202210277883.5A CN202210277883A CN114579406A CN 114579406 A CN114579406 A CN 114579406A CN 202210277883 A CN202210277883 A CN 202210277883A CN 114579406 A CN114579406 A CN 114579406A
- Authority
- CN
- China
- Prior art keywords
- node
- data
- transaction
- log
- command
- 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
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a method and a device for realizing consistency of distributed transactions, which are applied to a distributed transaction system, wherein the distributed transaction system comprises a coordination node and a data node cluster, the coordination node is used for distributing the transactions to the data nodes participating in the transactions to execute, and the method comprises the following steps: in the process of executing the transaction, the coordination node records a command sending log, and each data node records a transaction submitting log; when the coordination node and/or a certain data node fails and recovers, the coordination node acquires the transaction submission log recorded by each data node, judges whether the data is consistent by using the locally stored command sending log and the acquired transaction submission log, and synchronizes the data of the data nodes when judging that the data is inconsistent, so as to solve the problem of data inconsistency after the coordination node sends the submission command and both the coordination node and the data node fail and recover.
Description
Technical Field
The invention relates to the technical field of big data, in particular to a method and a device for realizing distributed transaction consistency.
Background
The existing transaction system mostly adopts a distributed architecture, the services with different functions are split to different servers, and the distributed transaction system is used, so that the distributed transaction system has the characteristics of low coupling and high cohesion, and has the advantages of high speed, high reliability, convenience in communication and the like.
Because the distributed architecture needs to span multiple services, the traditional transaction execution cannot guarantee data consistency, and the problem of transaction data consistency is generated, and currently, commonly used distributed transaction consistency solutions include a 2PC (two-phase commit) scheme and a 3PC (three-phase commit) scheme.
However, these two solutions cannot solve the problem of data inconsistency caused by down-time of both the coordinating node and the data node after the coordinating node in the distributed transaction system sends the commit command.
Disclosure of Invention
The purpose of the present invention is to provide a method and an apparatus for implementing distributed transaction consistency, which are provided to overcome the above-mentioned deficiencies in the prior art, and is implemented by the following technical solutions.
The first aspect of the present invention provides a method for implementing consistency of distributed transactions, which is applied to a distributed transaction system, where the distributed transaction system includes a coordinating node and a data node cluster, and the coordinating node is configured to distribute transactions to data nodes participating in the transactions for execution, and the method includes:
in the process of executing the transaction, the coordination node records a command sending log, and each data node records a transaction submitting log;
when the coordination node and/or a certain data node fails and recovers, the coordination node acquires the transaction submission log recorded by each data node, judges whether the data is consistent by using the locally stored command sending log and the acquired transaction submission log, and keeps the data of each data node consistent by resending the command when the data is inconsistent.
In some embodiments of the present application, the coordinating node logging command sending comprises:
and after the coordination node sends a transaction submitting command to each data node participating in the transaction, generating a command sending log by using the transaction identifier and the node identifier of each data node participating in the transaction.
In some embodiments of the present application, each data node records a transaction commit log, including:
and after receiving the transaction submitting command sent by the coordination node, the data node executes local transaction submitting operation and generates a transaction submitting log by using the transaction identifier, the node identifier of the data node and the successful submitting identifier.
In some embodiments of the present application, determining whether the data is consistent by using the locally stored command sending log and the obtained transaction commit log includes:
acquiring a transaction identifier contained in a command sending log with the log time closest to the current system time and node identifiers of data nodes participating in the transaction; aiming at each node identifier, searching a transaction submission log which simultaneously contains the transaction identifier and the node identifier from the obtained transaction submission log; if the condition that the searching of a certain node identifier fails exists, determining that the data are inconsistent; and if the searching is successful aiming at each node identifier, determining that the data are consistent.
In some embodiments of the present application, synchronizing data of a data node includes:
and retransmitting the transaction submitting command to the data node corresponding to the node identifier which fails to be searched so as to ensure that the data of the data node is consistent with other data nodes.
In some embodiments of the present application, the data node performs a local transaction commit operation, including:
and the data node submits the execution result of the local transaction to a database so as to update the data in the database.
In some embodiments of the present application, the method further comprises:
the coordination node clears a command sending log of a local record once every a preset time period;
and clearing the transaction submission log of the local record once every preset time period by each data node.
The second aspect of the present invention provides a distributed transaction consistency implementation apparatus, which is applied to a distributed transaction system, where the distributed transaction system includes a coordination node and a data node cluster, and the coordination node is configured to distribute a transaction to a data node participating in the transaction for execution; the device comprises a first recording module and a consistency module on a coordination node, and a second recording module on each data node;
the first recording module is used for recording a command sending log in the process of executing the transaction;
the second recording module is used for recording a transaction submission log in the process of executing the transaction;
and the consistency module is used for acquiring the transaction submission logs recorded by each data node after the coordination node and/or a certain data node fails and recovers, judging whether the data is consistent by using the locally stored command sending log and the acquired transaction submission logs, and keeping the data of each data node consistent by resending the command when the data is inconsistent.
Based on the method and the device for realizing the consistency of the distributed transactions in the first aspect and the second aspect, the invention has at least the following advantages or advantages:
according to the scheme, on the basis of not changing the original distributed architecture, the command is added to the coordination node to send the log record, the transaction submission log record is added to the data node, and therefore the coordination node and the data node record the execution condition of the transaction. Therefore, even if the coordination node and/or the data node fails, the data of the transmission log and the transaction submission log can be synchronized according to the command after recovery, so that the problem of data inconsistency after the coordination node transmits the submission command can be solved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the invention and not to limit the invention. In the drawings:
FIG. 1A is a flow diagram illustrating a preparation phase of a 2PC solution according to the present invention;
FIG. 1B is a schematic diagram illustrating a successful flow of the commit phase of a 2PC scheme according to the present invention;
FIG. 1C is a schematic diagram illustrating a failure flow of the commit stage of a 2PC scheme according to the present invention;
FIG. 2 is a flow chart illustrating a pre-commit phase of a 3PC scheme according to the present invention;
FIG. 3 is a flowchart of an embodiment of a distributed transaction coherency implementation method according to an exemplary embodiment of the present invention;
fig. 4 is a schematic structural diagram of a distributed transaction consistency implementation apparatus according to an exemplary embodiment of the present invention.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the invention, as detailed in the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present invention. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
In a distributed transaction, if data in multiple machines deployed in a distributed manner is desired to be consistent, then it is guaranteed that data writes at all nodes are either all performed or none performed. However, one machine cannot know the execution result of the local transaction in the other machine when executing the local transaction, and the node does not know whether the transaction should be committed (Commit) or rolled back (Rollback) at all.
Therefore, the execution of all distributed nodes (namely participants) is uniformly scheduled by introducing a component of a coordinator, the current node is made to know the task execution state of other nodes, and the execution commit or rollback is determined by means of notification and voting, so that the data consistency of the distributed transaction execution is ensured.
Currently, for the 2PC solution in the consistency solution, distributed transaction execution is divided into two phases: a preparation phase and a commit phase. Referring to fig. 1A, in an application scenario, an order service a needs to call a payment service B to pay, if the payment is successful, the shopping order is processed to be in a to-be-delivered state, otherwise, the shopping order needs to be processed to be in a failed state, where data nodes participating in a transaction include the order service a and the payment service B, and in a preparation phase, a coordinating node sends, to the data nodes participating in the transaction: the order service A and the payment service B send transaction preprocessing requests and start to wait for responses of the order service A and the payment service B, local transaction operations are executed for both the order service A and the payment service B, but the database local transactions are not really submitted after the execution is completed, and responses which can be processed (Yes) or cannot be processed (No) are returned to the coordination node.
And then entering a commit stage, as shown in fig. 1B, in this stage, if all the data nodes participating in the transaction return processable responses, after the coordinating node receives the processable responses returned by all the data nodes, it sends a commit command (commit) to each data node, and after each data node receives the commit command, it really executes a local transaction commit operation, and after the commit operation is completed, it releases the transaction resources occupied by the transaction execution device.
As shown in fig. 1C, at this stage, if any data node participating in the transaction feeds Back a response that cannot be processed, or the coordinating node does not receive responses fed Back by all data nodes after waiting for timeout, the coordinating node sends a rollback command (Roll Back) to the data nodes participating in the transaction, and after receiving the rollback command, each data node rolls Back the local transaction, thereby terminating the execution of the transaction and releasing the transaction resources.
For the 3PC scheme in the consistency solution, which is an improved version of the 2PC scheme, in addition to introducing a timeout mechanism, a pre-Commit stage (Can-Commit) is added, as shown in fig. 2, in the pre-Commit stage, the coordinating node issues a pre-Commit command to the data nodes participating in the transaction, inquires whether the transaction Commit operation Can be performed, and after receiving the pre-Commit command, each data node returns a Yes response and enters a prepare state if the transaction Can be successfully performed, otherwise returns a No response. If the coordinating node receives Yes responses returned by all the data nodes, the method enters a preparation phase, and the subsequent flow is as shown in the above-mentioned FIG. 1A to FIG. 1C.
It can be seen from the above-mentioned 2PC scheme and 3PC scheme that, in some extreme cases, the 2PC scheme and 3PC scheme still have a problem of inconsistent data, that is, after the coordination node issues the commit command, and the coordination node and the data node both fail and recover, assuming that 10 data nodes are involved in the transaction in total, one of the data nodes has not performed the local transaction commit operation when being down, and the other 9 data nodes have performed the local transaction commit operation, after the coordination node and the data node recover, the coordination node does not know whether each data node performs the commit operation or not, and needs to perform rollback to cancel the transaction, so as to issue a rollback command to each data node, since the data node that is down and recovered has not performed the commit operation yet, rollback can be implemented, but the other 9 data nodes have performed the commit operation, rollback cannot be achieved, resulting in data inconsistencies.
In order to solve the technical problem of data inconsistency caused by fault recovery of a coordination node and a data node, the embodiment of the application provides an improved method for realizing distributed transaction consistency on the basis of not changing an original architecture, namely, in the process of executing a transaction, the coordination node records a command sending log, and each data node records a transaction submitting log; when the coordination node and/or a certain data node fails and recovers, the coordination node acquires the transaction submission log recorded by each data node, judges whether the data is consistent by using the locally stored command sending log and the acquired transaction submission log, and keeps the data of each data node consistent by resending the command when the data is inconsistent.
The technical effects that can be achieved based on the above description are:
according to the scheme, on the basis of not changing the original distributed architecture, the command is added to the coordination node to send the log record, the transaction submission log record is added to the data node, and therefore the coordination node and the data node record the execution condition of the transaction. Therefore, even if the coordination node and/or the data node fails, the data of the transmission log and the transaction submission log can be synchronized according to the command after recovery, so that the problem of data inconsistency after the coordination node transmits the submission command can be solved.
In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.
The first embodiment is as follows:
fig. 3 is a flowchart of an embodiment of a distributed transaction consistency implementation method according to an exemplary embodiment of the present invention, which is applied to a distributed transaction system, where the distributed transaction system includes a coordinating node and a data node cluster, and the coordinating node is configured to distribute a transaction to data nodes participating in the transaction for execution. In the embodiment of the present application, the data consistency of the data node refers to the consistency of business data, transaction data, payment data, or purchase data.
As shown in fig. 3, the distributed transaction consistency implementation method includes the following steps:
step 301: in the process of executing the transaction, the coordination node records a command sending log, and each data node records a transaction submission log.
In the embodiment of the present invention, no matter the 2PC scheme or the 3PC scheme, because the data node actually performs the local transaction commit operation in the last phase, i.e., the commit phase, and the data node performs the local transaction commit operation only after receiving the commit command from the coordinator node, by adding the logs of the transaction execution conditions recorded in the coordinator node and the data node in the commit phase, i.e., the command send log is recorded in the coordinator node, and the transaction commit log is recorded in the data node.
In some embodiments, after the coordinating node sends a transaction commit command to each data node participating in the transaction, the command send log is generated by using the transaction identifier and the node identifier of each data node participating in the transaction. That is, the command transmission log of the coordinating node records which data nodes have been transmitted transaction commit commands and which transaction is specifically targeted.
In some embodiments, after receiving a transaction commit command sent by the coordinating node, the data node executes a local transaction commit operation, and generates a transaction commit log by using the transaction identifier, the node identifier of the data node, and the commit success identifier. That is, each time a data node performs a commit operation for a transaction, it generates a transaction commit log.
Wherein the transaction identification represents the transaction number currently processed.
It should be added that after the data node performs the local transaction commit operation, the data in the database is changed and cannot be reversed.
In other embodiments of the present application, to avoid an influence of log recording on node performance, only logs of a certain time length are recorded in a coordinating node and a data node, and a specific implementation process includes:
and clearing the command sending log of the local record once every preset time period for the coordination node.
And clearing the transaction submission log of the local record once every preset time period for each data node.
Step 302: when the coordination node and/or a certain data node fails and recovers, the coordination node acquires the transaction submission log recorded by each data node, judges whether the data is consistent by using the locally stored command sending log and the acquired transaction submission log, and keeps the data of each data node consistent by resending the command when the data is inconsistent.
After the coordination node and/or a data node simultaneously fails and recovers, the coordination node does not know the current state of each data node according to the execution condition of the transaction, and therefore whether the data are consistent or not is judged by obtaining a transaction submission log of the data node and comparing and analyzing the transaction submission log with a locally stored command sending log.
In an optional embodiment, the coordinating node sends a transaction identifier included in a log and node identifiers of data nodes participating in the transaction by obtaining a command whose log time is closest to the current system time, and then searches for a transaction commit log including both the transaction identifier and the node identifiers from the obtained transaction commit log for each node identifier, if a certain node identifier fails to be searched, it is determined that the data are inconsistent, and if the node identifiers are successfully searched, it is determined that the data are consistent.
If the node identifier is found to be failed, the data node corresponding to the node identifier does not execute the local transaction submitting operation after receiving the transaction submitting command, and for the node identifier which is found to be successful, the data node corresponding to the node identifier executes the local transaction submitting operation after receiving the transaction submitting command, so that the problem of data inconsistency exists among the data nodes participating in the same transaction.
In addition, if the search of each node identifier fails, it indicates that the corresponding data nodes have not executed the local transaction commit operation, and the data of the data nodes are consistent, or if the search of each node identifier succeeds, it indicates that the corresponding data nodes have executed the local transaction commit operation, and the data of the data nodes are also consistent.
Based on the above analysis, in a process of keeping data of each data node consistent by resending the command, in an optional embodiment, the data node resends the transaction commit command to the data node corresponding to the node identifier that fails to be searched, so that after receiving the transaction commit command, the data node executes a local transaction commit operation, and thus the data of the data node is kept consistent with other data nodes.
To this end, the data consistency implementation flow shown in fig. 3 is completed, and according to the scheme, on the basis of not changing the original distributed architecture, the command sending log record is added at the coordination node, and the transaction submitting log record is added at the data node, so that the coordination node and the data node record the execution condition of the transaction. Therefore, even if the coordination node and/or the data node fails, the data of the coordination node and the data node can be synchronized according to the command sending log and the transaction submitting log after recovery, and the problem of data inconsistency after the coordination node sends the submitting command can be solved.
Corresponding to the foregoing embodiment of the distributed transaction consistency implementation method, the present invention further provides an embodiment of a distributed transaction consistency implementation apparatus.
Fig. 4 is a schematic structural diagram of a distributed transaction consistency implementation apparatus according to an exemplary embodiment of the present invention, where the apparatus is configured to execute the distributed transaction consistency implementation method provided in any of the foregoing embodiments, and as shown in fig. 4, the distributed transaction consistency implementation apparatus includes a first recording module 410 and a consistency module 420 on a coordinating node, and a second recording module 430 on each data node;
the first recording module 410 is configured to record a command sending log during the process of executing the transaction;
the second recording module 430 is configured to record a transaction commit log during the process of executing the transaction;
the consistency module 420 is configured to, after the coordinating node and/or a data node fails and recovers, obtain a transaction commit log recorded by each data node, determine whether data is consistent by using a locally stored command sending log and the obtained transaction commit log, and when the data is determined to be inconsistent, keep the data of each data node consistent by resending the command.
In an optional implementation manner, the first recording module 410 is specifically configured to generate a command sending log by using the transaction identifier and the node identifier of each data node participating in the transaction after sending the transaction commit command to each data node participating in the transaction.
In an optional implementation manner, the second recording module 430 is specifically configured to execute a local transaction commit operation after receiving a transaction commit command sent by the coordinating node, and generate a transaction commit log by using the transaction identifier, the node identifier of the local data node, and the commit success identifier.
In an optional implementation manner, the second recording module 430 is specifically configured to, in the process of executing a local transaction commit operation, commit a local transaction execution result to a database, so as to update data in the database.
In an optional implementation manner, the consistency module 420 is specifically configured to, in a process of determining whether data is consistent by using a locally stored command sending log and an obtained transaction submitting log, obtain a transaction identifier included in the command sending log whose log time is closest to the current system time and a node identifier of each data node participating in the transaction; aiming at each node identification, searching a transaction submission log which simultaneously contains the transaction identification and the node identification from the acquired transaction submission log; if the condition that the searching of a certain node identifier fails exists, determining that the data are inconsistent; and if the searching is successful aiming at each node identifier, determining that the data are consistent.
In an optional implementation manner, the consistency module 420 is specifically configured to, in a process of keeping data of each data node consistent through a resending command mode, resend a transaction commit command to a data node corresponding to a node identifier that fails to find, so that the data of the data node is kept consistent with other data nodes.
In an alternative implementation, the apparatus further comprises (not shown in fig. 4):
the first clearing module on the coordination node is specifically used for clearing a command sending log of a local record every other preset time period;
and the second clearing module on the data node is specifically used for clearing the command sending log of the local record once every preset time period.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the invention. One of ordinary skill in the art can understand and implement it without inventive effort.
Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (10)
1. A distributed transaction consistency implementation method is applied to a distributed transaction system, the distributed transaction system comprises a coordination node and a data node cluster, the coordination node is used for distributing a transaction to data nodes participating in the transaction to execute, and the method comprises the following steps:
in the process of executing the transaction, the coordination node records a command sending log, and each data node records a transaction submitting log;
when the coordination node and/or a certain data node fails and recovers, the coordination node acquires the transaction submission log recorded by each data node, judges whether the data is consistent by using the locally stored command sending log and the acquired transaction submission log, and keeps the data of each data node consistent by resending the command when the data is inconsistent.
2. The method of claim 1, wherein the coordinating node logs command transmission logs, comprising:
and after the coordination node sends a transaction submitting command to each data node participating in the transaction, generating a command sending log by using the transaction identifier and the node identifier of each data node participating in the transaction.
3. The method of claim 1, wherein each data node records a transaction commit log, comprising:
and after receiving the transaction submitting command sent by the coordination node, the data node executes local transaction submitting operation and generates the transaction submitting log by using the transaction identifier, the node identifier of the data node and the submitting success identifier.
4. The method of claim 3, wherein the data node performs a local transaction commit operation comprising:
and the data node submits the execution result of the local transaction to a database so as to update the data in the database.
5. The method of claim 1, wherein determining whether the data is consistent with the obtained transaction commit log using the locally stored command send log comprises:
acquiring a transaction identifier contained in a command sending log with the log time closest to the current system time and node identifiers of data nodes participating in the transaction;
aiming at each node identifier, searching a transaction submission log which simultaneously contains the transaction identifier and the node identifier from the obtained transaction submission log;
if the searching of a certain node identifier fails, determining that the data are inconsistent;
and if the searching is successful aiming at each node identifier, determining that the data are consistent.
6. The method according to claim 5, wherein the keeping the data of each data node consistent by resending the command includes:
and retransmitting the transaction submission command to the data node corresponding to the node identifier failed in the search so as to keep the data of the data node consistent with other data nodes.
7. The method of claim 1, further comprising:
the coordination node clears a command sending log of a local record every other preset time period;
and clearing the transaction submission log of the local record once by each data node every a preset time period.
8. The device for realizing the consistency of the distributed transactions is applied to a distributed transaction system, the distributed transaction system comprises a coordination node and a data node cluster, and the coordination node is used for distributing the transactions to the data nodes participating in the transactions for execution;
the device comprises a first recording module and a consistency module on a coordination node, and a second recording module on each data node;
the first recording module is used for recording a command sending log in the process of executing the transaction;
the second recording module is used for recording a transaction submission log in the process of executing the transaction;
and the consistency module is used for acquiring the transaction submission logs recorded by each data node after the coordination node and/or a certain data node fails and recovers, judging whether the data is consistent by using the locally stored command sending log and the acquired transaction submission logs, and keeping the data of each data node consistent by resending the command when the data is inconsistent.
9. The apparatus according to claim 8, wherein the consistency module is specifically configured to, in a process of determining whether data is consistent by using a locally stored command sending log and an obtained transaction commit log, obtain a transaction identifier included in the command sending log whose log time is closest to a current system time and a node identifier of each data node participating in the transaction; aiming at each node identification, searching a transaction submission log which simultaneously contains the transaction identification and the node identification from the acquired transaction submission log; if the condition that the searching of a certain node identifier fails exists, determining that the data are inconsistent; and if the searching is successful aiming at each node identifier, determining that the data are consistent.
10. The apparatus according to claim 9, wherein the consistency module is specifically configured to, in a process of keeping data of each data node consistent through a resend command manner, resend a transaction commit command to a data node corresponding to a node identifier that fails to find, so that the data of the data node is kept consistent with other data nodes.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210277883.5A CN114579406A (en) | 2022-03-21 | 2022-03-21 | Method and device for realizing consistency of distributed transactions |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210277883.5A CN114579406A (en) | 2022-03-21 | 2022-03-21 | Method and device for realizing consistency of distributed transactions |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114579406A true CN114579406A (en) | 2022-06-03 |
Family
ID=81782724
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210277883.5A Pending CN114579406A (en) | 2022-03-21 | 2022-03-21 | Method and device for realizing consistency of distributed transactions |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114579406A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115658245A (en) * | 2022-12-22 | 2023-01-31 | 北京奥星贝斯科技有限公司 | Transaction submitting system, method and device based on distributed database system |
-
2022
- 2022-03-21 CN CN202210277883.5A patent/CN114579406A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115658245A (en) * | 2022-12-22 | 2023-01-31 | 北京奥星贝斯科技有限公司 | Transaction submitting system, method and device based on distributed database system |
| CN115658245B (en) * | 2022-12-22 | 2023-03-10 | 北京奥星贝斯科技有限公司 | Transaction submitting system, method and device based on distributed database system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4094752B2 (en) | Transaction processing method, apparatus for executing the same, and medium storing the processing program | |
| US11836154B2 (en) | Data synchronization method and device for databases, and storage medium | |
| JP6220851B2 (en) | System and method for supporting transaction recovery based on strict ordering of two-phase commit calls | |
| CN102317913B (en) | A kind of transaction recovery method and transaction recovery device | |
| JPH10214199A (en) | Process restarting method, and system for realizing process restart | |
| CN107612950B (en) | Method, device and system for providing service and electronic equipment | |
| CN110888718A (en) | Method and device for realizing distributed transaction | |
| CN112148436B (en) | Decentralised TCC transaction management method, device, equipment and system | |
| CN110413687B (en) | Distributed transaction fault processing method and related equipment based on node interaction verification | |
| EP0834122B1 (en) | Synchronisation procedure in a routing node | |
| US20180024896A1 (en) | Information processing system, information processing apparatus, and information processing method | |
| CN112995262B (en) | Distributed transaction submission method, system and computing equipment | |
| CN105138691A (en) | Method and system for analyzing user traffic | |
| CN114579406A (en) | Method and device for realizing consistency of distributed transactions | |
| CN110830582B (en) | Cluster owner selection method and device based on server | |
| US20020059316A1 (en) | Method and apparatus for improving message availability in a subsystem which supports shared message queues | |
| CN112632093A (en) | Work order processing method, device, system, storage medium and program product | |
| CN111143041B (en) | Data consistency method, distributed coordinator and central coordinator | |
| CN113515352B (en) | Distributed transaction different-library mode anti-transaction calling method and device | |
| US20090106781A1 (en) | Remote call handling methods and systems | |
| JP2002244887A (en) | Log collection system and method | |
| KR101672724B1 (en) | Middle-tier, data processing system including the same, and method of database transferring | |
| US20080208977A1 (en) | System and method for resolving a unit of work | |
| CN113742043A (en) | Asynchronous splitting method for server backend task | |
| CN110839064A (en) | Method and device for executing script by distributed system |
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 |