CN109002462B - Method and system for realizing distributed transaction - Google Patents
Method and system for realizing distributed transaction Download PDFInfo
- Publication number
- CN109002462B CN109002462B CN201810564968.5A CN201810564968A CN109002462B CN 109002462 B CN109002462 B CN 109002462B CN 201810564968 A CN201810564968 A CN 201810564968A CN 109002462 B CN109002462 B CN 109002462B
- Authority
- CN
- China
- Prior art keywords
- execution
- execution chain
- transaction
- chain
- failure
- 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.)
- Active
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to a method and a system for realizing distributed things, wherein the method comprises the following steps: when the distributed object request is executed, generating an execution chain for all the operations; according to the sequence of the execution chain, related sub-services are sequentially called, related data are sent, and feedback is waited; and after receiving the feedback message of the sub-service, refreshing the database record of the execution chain, if the feedback message is successful, executing the next step in the execution chain, and if the feedback message is a failure message, reversely executing the reverse operation according to the execution chain. The invention can relieve the blockage problem of the subsystem of the participant; because the failure condition of things is recorded in the whole process, the modification and the cancellation of failure operation can be realized, and the consistency of the system can be effectively ensured; the invention combines reasonable recorded data and proper cluster disaster recovery configuration, can effectively avoid the problem of single-point failure and enhance the robustness of the system.
Description
[ technical field ] A method for producing a semiconductor device
The invention belongs to the technical field of information processing, and particularly relates to a method and a system for realizing distributed transactions.
[ background of the invention ]
In the field of traditional OLTP systems, we are faced with the need for transaction consistency in many scenarios, such as the most classical case of Bob transferring Smith. In traditional enterprise development, the system is often in the form of a single application, and does not span multiple databases. However, a large internet platform is often formed by a series of distributed systems, development languages and technical stations are relatively complex, especially today with the prevalence of SOA and microservice architectures, a function that looks simple may need to call multiple "services" inside and operate multiple databases or shards to implement, and the situation is often complex. A single technical solution has not been able to cope with and satisfy these complex scenarios.
Referring to a distributed system, it is necessary to refer to distributed transactions. A distributed transaction is a transaction that runs in a distributed environment, for which each operational step of the transaction is a service running on a different machine. How to ensure consistency between runs and systems on different machines is a concern for distributed transactions.
Referring to distributed transactions, 2PC, and two-phase commit are easily contemplated. The nodes participating in a transaction in a two-phase commit scheme can be divided into two roles, one being a coordinator, typically the initiator of the transaction, one being a participant in the service, and one providing the service.
Two-phase commit (Two-phase-commit) in the prior art refers to an algorithm designed to keep all nodes under a distributed system architecture consistent when a transaction is committed in the field of computer networks and databases, as shown in fig. 1-2. The two phases are: the first stage is as follows: preparation phase (voting phase) and second phase: commit phase (execute phase)
A preparation stage: the transaction coordinator (transaction manager) sends a Prepare message to each participant (resource manager) that either directly returns a failure (entry validation failure) or executes the transaction locally, writes local redo and undo logs, but does not commit the transaction, leading to a "do everything has, formerly east wind" state.
The preparation phase can be further divided into the following three steps:
(1) the coordinator node asks all participant nodes if a commit operation (vote) can be performed and starts waiting for the responses of the participant nodes.
(2) The participant performs all transaction operations until the query is initiated and writes undo and redo information to the log.
(3) Each participant node responds to a query initiated by the coordinator node. If the transaction operation of the participant node is actually performed as
If the user works, the user returns a system 'consent' message; zeta returns a "terminate" message if the participant node's transaction operation actually fails to execute.
A submission stage: if the coordinator receives the failure message or timeout of the participants, a Rollback (Rollback) message is directly sent to each participant; otherwise, sending a Commit (Commit) message; and the participator executes the commit or rollback operation according to the instruction of the coordinator, and releases all lock resources used in the transaction processing process.
The process of the commit phase is discussed separately in the following two cases.
When the response messages obtained by the coordinator from all the participant nodes are yes, as shown in fig. 1:
(1) the coordinator node issues a "formal commit" request to all participant nodes.
(2) The participant node formally completes the transaction operation and releases the resources occupied during the entire transaction.
(3) Participant nodes send 'done' messages to coordinator nodes
(4) The coordinator node completes the transaction after receiving the 'completion' message fed back by all the participating combination nodes
If any participant node returns a reject message "no" in the first phase, as in fig. 2, or the coordinator node fails to obtain response messages for all nodes before the query times out:
(1) the coordinator node sends a request for a "rollback" operation to all participant nodes
(2) And the participant node executes rollback by using the previously written undo information and releases the system resources occupied in the whole transaction period.
(3) The participant node sends a "rollback complete" message to the coordinator node.
(4) And after receiving the 'rollback completion' message fed back by all the participant nodes, the coordinator node cancels the transaction.
Regardless of the final result, the second phase ends the current transaction.
The two-phase commit in the prior art has the following disadvantages:
(1) the problem of synchronous blocking. During execution, all participating nodes are transaction blocking. When a participant possesses a public resource, application nodes with other third parties accessing the public resource will have to be in a blocking state.
(2) A single point of failure. Due to the importance of the coordinator, once the coordinator fails, the participants are blocked all the time.
(3) The data is not consistent. In the second phase, when a local network failure occurs during the process of sending the commit request to the participants, only a part of the participating groups receive the commit request, and the other part of the coordinators do not receive the commit request. The whole system has inconsistent data.
Therefore, the following technical problems are urgently needed to be solved:
(1) the execution chain is generated by performing topological sequencing on a series of operations in the distributed transaction, and then the operations are sequentially executed according to the execution chain, so that the occupation of common resources in the whole system can be effectively reduced, and the problem of synchronous blocking is solved.
(2) Because the execution chain is stored in a reasonable data structure and the execution information is also stored in each sub-service, the influence of system faults on the consistency of the whole system can be effectively avoided.
(3) By matching with the data record of the execution chain, the execution record of the sub-service and cluster disaster tolerance, the node function can be quickly recovered when the system node fails, and the problem of single-point failure is avoided.
[ summary of the invention ]
In order to solve the above problems in the prior art, the present invention provides a method for implementing distributed transactions, which is characterized in that the method includes the following steps:
1) when the distributed transaction request is executed, generating an execution chain for all the operations;
2) according to the sequence of the execution chain, related sub-services are sequentially called, related data are sent, and feedback is waited;
3) after receiving the feedback message of the sub-service, refreshing the database record of the execution chain, if the feedback message is successful, executing the next step in the execution chain, and skipping to the step 2), if the feedback message is a failure message, reversely executing the reverse operation according to the execution chain;
saving the execution chain by adopting a data structure, wherein the data structure comprises a relational database and/or a non-relational database;
after receiving the call request, the sub-service records the call information, processes the call request, feeds back success/failure information after the execution is finished, and refreshes a local call record;
the data structure comprises a unique identification ID, transaction data, upstream and downstream operation identifications, a current operation node, a node execution state and node execution node information;
the data structure is stored and updated through a cache system; in the step 1), when a distributed transaction request is executed, firstly, topological sorting is performed on all operations contained in the request, a reverse operation is configured for each operation, and finally, an execution chain which is composed of all the operations and meets the topological sorting is generated;
in the step 3), in the process of executing the reverse operation, if a certain operation fails, it indicates that the execution of the current transaction fails, and refreshes the database record of the execution chain, and marks it as a transaction failure.
In order to solve the above problems in the prior art, the present invention provides a system for implementing distributed transactions, which is characterized in that the system comprises:
the execution chain generation module is used for generating an execution chain for all the operations when the distributed transaction request is executed;
the service calling module is used for calling related sub-services in sequence according to the sequence of the execution chain, sending related data and waiting for feedback;
the feedback receiving and processing module refreshes the database record of the execution chain after receiving the feedback message of the sub-service, if the feedback message is successful, the next step in the execution chain is executed, and if the feedback message is a failure message, the reverse operation is reversely executed according to the execution chain;
saving the execution chain by adopting a data structure, wherein the data structure comprises a relational database and/or a non-relational database;
after receiving the call request, the sub-service records the call information, processes the call request, feeds back success/failure information after the execution is finished, and refreshes a local call record;
the data structure comprises a unique identification ID, transaction data, upstream and downstream operation identifications, a current operation node, a node execution state and node execution node information;
and the data structure is stored and updated through a cache system.
When executing the distributed transaction request, the execution chain generation module firstly performs topological sorting on all operations contained in the request, configures a reverse operation for each operation, and finally generates an execution chain which is composed of all the operations and meets the topological sorting.
And the transaction marking module is used for indicating that the transaction is failed to be executed if a certain operation fails in the process of executing the reverse operation, refreshing the database record of the execution chain and marking the database record as the transaction failure.
The beneficial effects of the invention include: the problem of blocking of the participant subsystem can be alleviated; because the failure condition of the transaction is recorded in the whole process, the modification and the cancellation of the failure operation can be realized, and the consistency of the system can be effectively ensured; the invention combines reasonable recorded data and proper cluster disaster recovery configuration, can effectively avoid the problem of single-point failure and enhance the robustness of the system.
[ description of the 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, are not intended to limit the invention, but include:
FIG. 1 is a diagram illustrating the success of two-phase commit in the prior art.
FIG. 2 is a diagram illustrating a failure of a two-phase commit in the prior art.
Fig. 3 is a schematic diagram of an execution chain of the present invention.
Fig. 4 is a flow chart of an implementation method employing aspects of the present invention.
[ detailed description ] embodiments
The present invention will now be described in detail with reference to the drawings and specific embodiments, wherein the exemplary embodiments and descriptions are provided only for the purpose of illustrating the present invention and are not to be construed as limiting the present invention.
Transaction: a transaction refers to a series of operations that are either all performed or none performed. Transaction processing can ensure that data-oriented resources are not permanently updated unless all operations within a transactional unit are successfully completed. By combining a set of related operations into one unit that either all succeeds or all fails, error recovery can be simplified and the application can be made more reliable.
ACID: it refers to the abbreviation of the four basic elements of a database transaction that executes correctly. Atomicity (Atomicity) that a series of operations in an entire transaction either all succeed or all fail and do not stay in some intermediate state; consistency (Consistency): the running of the transaction does not affect the consistency of the data in the database, for example, if a + b is 10, b is changed. Isolation (Isolation): the state of interleaved execution does not occur for more than two transactions, as this may result in data inconsistencies. Durability (durabilty): the persistence of the transaction means that after the transaction is successfully executed, the change of the transaction to the database is persistently stored in the database, and the transaction cannot be rolled back without any reason.
CAP principle: the principle of CAP is also called CAP theorem, and it is worth mentioning that in a distributed system, Consistency, Availability, and Partition tolerance cannot be obtained simultaneously. Consistency, in a distributed environment, Consistency deserves the characteristic of keeping Consistency among a plurality of copy data, and all data changes are synchronous; availability (Availability): the distributed system is required to be available all the time, has good responsiveness and returns results in a limited time; partition tolerance: the distributed system still needs to be able to provide the service satisfying the consistency and availability to the outside when encountering the failure of any network partition, unless the entire network environment is failed.
BASE theory: BASE is an abbreviation for the three phrases basic Available, Soft state, and eventuality consistency. The BASE theory is the result of the balance between consistency and usability in the CAP principle, and the BASE theory is derived from the summary of large-scale internet distributed practice and is evolved gradually based on the CAP theorem, and the core idea is as follows: strong consistency cannot be achieved in time, but each application can adopt a proper mode to enable the system to achieve final consistency according to the service characteristics of the application. Basically, available: meaning that the distributed system allows for the loss of partial availability when an unpredictable failure occurs, rather than the system being unavailable. Soft state: the value allows for intermediate states of data in the system, and there may be delays in synchronizing data between data copies of different nodes without affecting the overall availability of the system. Final consistency: although some data copies eventually reach a consistent state after some time of synchronization.
Topological sorting: topological sorting is carried out on a Directed Acyclic Graph (DAG) G, all vertexes in the G are arranged into a linear sequence, so that any pair of vertexes u and v in the Graph, and if an edge (u, v) belongs to E (G), u appears before v in the linear sequence. Generally, such a linear sequence becomes a sequence satisfying a Topological Order (Topological Order), abbreviated as a Topological sequence.
Distributed transactions often involve multiple operations that need to be performed on different network nodes and there are dependencies between the operations. We can order these operations in a topological order, resulting in a sequence of these operations that satisfies the topological order, and design a reverse operation for each operation. We can refer to this sequence as an execution chain.
A data structure is elaborated for the execution chain to save and transfer the execution chain. The data structure contains a series of data such as unique identification ID, transaction data, upstream and downstream operation identification, current operation node, node execution state, node execution node information and the like. The data structure is stored and updated by means of an efficient cache system. The efficient cache system refers to some non-relational memory databases, such as Redis, by means of which a subscription function is published, each service corresponds to one topic and only consumes messages of the own topic, but each service can publish messages of other topics.
The sub-services are then invoked step by step in the order of the execution chain. And after receiving the call request, the sub-service records the call information, processes the request, feeds back success and failure information after the execution is finished, and refreshes the local call record. The local call record refers to call information recorded when the request is started to be processed, and is a local call log. And after receiving the feedback information, if the feedback information is successful, the calling party continues to execute the next step until the execution of the execution chain is completed, if the feedback information is failed, the reverse operation is called reversely, and if the reverse operation is called in failure, the transaction is directly marked as failed. Wherein each step in the execution chain is an operation that is performed by a particular service provider.
System execution flow
1. When the distributed transaction is executed, all operations contained in the request are subjected to topological sorting, a reverse operation is configured for each operation, and finally an execution chain which is composed of all the operations and meets the topological sorting is generated.
2. Reasonable data structures are designed and stored for the execution chain, wherein the reasonable data structures can be stored by a relational database or a NOSQL-type non-relational database and an efficient cache system.
3. And according to the sequence of the execution chain, sequentially calling the related sub-services, sending related data and waiting for feedback. The related data refers to transaction data, and comprises unique identification of the transaction, service data and upstream and downstream node information.
4. After receiving the request, the sub-service makes a call record first, and then executes the request. If the call is successful, the call success is fed back to the caller, if the call failure is failed, a call failure message is fed back to the caller, the local call record is updated, and the rollback is executed.
5. And after receiving the feedback message of the sub-service, the caller refreshes the database record of the execution chain, if the database record is successful, the next step in the execution chain is executed, and if the database record is a failure message, the caller reversely executes the reverse operation according to the execution chain.
6. In the process of executing the reverse operation, if a certain operation fails, the transaction execution failure is directly indicated, and the database record of the execution chain is refreshed and marked as failure.
A system call is broken down into a chain of execution, containing operations on multiple services. If the step fails, the rollback is carried out according to the reverse operation in the execution chain, and if the rollback still fails, the rollback operation is directly terminated, and the log is recorded.
7. For a failed transaction, the system is required to process automatically or manually.
In addition, the invention also discloses a system for realizing distributed transaction, which comprises:
the execution chain generation module is used for generating an execution chain for all the operations when the distributed transaction request is executed;
the service calling module is used for calling related sub-services in sequence according to the sequence of the execution chain, sending related data and waiting for feedback;
and the feedback receiving and processing module refreshes the database record of the execution chain after receiving the feedback message of the sub-service, if the feedback message is successful, the next step in the execution chain is executed, and if the feedback message is a failure message, the reverse operation is reversely executed according to the execution chain.
And saving the execution chain by adopting a data structure, wherein the data structure comprises a relational database and/or a non-relational database.
When executing the distributed transaction request, the execution chain generation module firstly performs topological sorting on all operations contained in the request, configures a reverse operation for each operation, and finally generates an execution chain which is composed of all the operations and meets the topological sorting.
The data structure comprises a unique identification ID, transaction data, upstream and downstream operation identifications, a current operation node, a node execution state and node execution node information;
and the data structure is stored and updated through a cache system.
The system also comprises a transaction marking module, and in the process of executing the reverse operation, if a certain operation fails, the transaction is indicated to fail to execute, and the database record of the execution chain is refreshed and marked as transaction failure.
In the scheme of the invention, the cache needs to be reasonably used, the message structure is skillfully and meticulously designed, and the problem of blocking of the subsystem of the participant can be relieved in the execution of the distributed transaction by combining reasonable flow calculation.
The technology related to the scheme of the invention is mature, and is easy to develop and implement.
Because the failure condition of the transaction is recorded in the whole process, the modification and the cancellation of the failure operation can be realized, and the consistency of the system can be effectively ensured.
The scheme of the invention combines reasonable recorded data and proper cluster disaster recovery configuration, can effectively avoid the problem of single-point failure and enhance the robustness of the system.
The embodiments in the present specification are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, embodiments of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
Embodiments of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a transmitter of a general purpose computer, special purpose computer, embedded transmitter, or other programmable data transmission terminal device to produce a machine, such that the instructions, which execute via the transmitter of the computer or other programmable data transmission terminal device, create a system for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data transmission terminal to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction system which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data transmission terminal device to cause a series of operational steps to be performed on the computer or other programmable terminal device to produce a computer implemented transmission such that the instructions which execute on the computer or other programmable terminal device provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present invention have been described, additional variations and modifications of these embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the embodiments of the invention.
Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal 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 terminal. 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 terminal that comprises the element.
The method and system for implementing distributed transaction provided by the present invention are introduced in detail, and the principle and implementation manner of the present invention are explained by applying specific examples, and the description of the above embodiments is only used to help understanding the method and core idea of the present invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.
Claims (3)
1. A method for implementing a distributed transaction, the method comprising the steps of:
1) when the distributed transaction request is executed, generating an execution chain for all the operations;
2) according to the sequence of the execution chain, related sub-services are sequentially called, related data are sent, and feedback is waited;
3) after receiving the feedback message of the sub-service, refreshing the database record of the execution chain, if the feedback message is successful, executing the next step in the execution chain, and skipping to the step 2), if the feedback message is a failure message, reversely executing the reverse operation according to the execution chain;
saving the execution chain by adopting a data structure, wherein the data structure comprises a relational database and/or a non-relational database;
after receiving the call request, the sub-service records the call information, processes the call request, feeds back success/failure information after the execution is finished, and refreshes a local call record;
the data structure comprises a unique identification ID, transaction data, upstream and downstream operation identifications, a current operation node, a node execution state and node execution node information;
the data structure is stored and updated through a cache system;
in the step 1), when a distributed transaction request is executed, firstly, topological sorting is performed on all operations contained in the request, a reverse operation is configured for each operation, and finally, an execution chain which is composed of all the operations and meets the topological sorting is generated;
in the step 3), in the process of executing the reverse operation, if a certain operation fails, it indicates that the transaction execution fails, and refreshes the database record of the execution chain, marks it as a transaction failure, and performs automatic or manual processing.
2. A system for implementing distributed transactions, the system comprising:
the execution chain generation module is used for generating an execution chain for all the operations when the distributed transaction request is executed;
the service calling module is used for calling related sub-services in sequence according to the sequence of the execution chain, sending related data and waiting for feedback;
the feedback receiving and processing module refreshes the database record of the execution chain after receiving the feedback message of the sub-service, if the feedback message is successful, the next step in the execution chain is executed, and if the feedback message is a failure message, the reverse operation is reversely executed according to the execution chain;
saving the execution chain by adopting a data structure, wherein the data structure comprises a relational database and/or a non-relational database;
after receiving the call request, the sub-service records the call information, processes the call request, feeds back success/failure information after the execution is finished, and refreshes a local call record;
the data structure comprises a unique identification ID, transaction data, upstream and downstream operation identifications, a current operation node, a node execution state and node execution node information;
the data structure is stored and updated through a cache system;
the execution chain generation module performs topological sorting on all operations contained in the request when executing the distributed transaction request, configures a reverse operation for each operation, and finally generates an execution chain which is composed of all the operations and meets the topological sorting;
and the transaction marking module is used for indicating that the transaction is failed to be executed if a certain operation fails in the process of executing the reverse operation, refreshing the database record of the execution chain, marking the database record as the transaction failure and performing automatic or manual processing.
3. A computer-readable storage medium storing a plurality of computer program instructions which, upon execution, implement the method of claim 1.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810564968.5A CN109002462B (en) | 2018-06-04 | 2018-06-04 | Method and system for realizing distributed transaction |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810564968.5A CN109002462B (en) | 2018-06-04 | 2018-06-04 | Method and system for realizing distributed transaction |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109002462A CN109002462A (en) | 2018-12-14 |
| CN109002462B true CN109002462B (en) | 2020-11-27 |
Family
ID=64572890
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810564968.5A Active CN109002462B (en) | 2018-06-04 | 2018-06-04 | Method and system for realizing distributed transaction |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109002462B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109799981B (en) * | 2018-12-19 | 2022-09-09 | 成都多用科技有限公司 | Integrated system and method based on execution chain |
| CN109819023B (en) * | 2018-12-29 | 2021-09-14 | 杭州励飞软件技术有限公司 | Distributed transaction processing method and related product |
| CN111813786A (en) * | 2019-04-12 | 2020-10-23 | 阿里巴巴集团控股有限公司 | Defect detecting/processing method and device |
| CN110413447A (en) * | 2019-06-27 | 2019-11-05 | 苏州浪潮智能科技有限公司 | A kind of big data cluster resetting method and system |
| CN111277639B (en) * | 2020-01-16 | 2022-08-09 | 中国建设银行股份有限公司 | Method and device for maintaining data consistency |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103514028A (en) * | 2012-06-14 | 2014-01-15 | 北京新媒传信科技有限公司 | Method and device for processing distributed transactions |
| CN104424018A (en) * | 2013-08-23 | 2015-03-18 | 阿里巴巴集团控股有限公司 | Distributed calculating transaction processing method and device |
| CN105721337A (en) * | 2014-12-04 | 2016-06-29 | 中国移动通信集团公司 | Distributed transaction processing method and device in software definition network |
| CN106557514A (en) * | 2015-09-29 | 2017-04-05 | 中兴通讯股份有限公司 | A kind of distributed transaction rollback method and device |
| CN106775959A (en) * | 2016-12-06 | 2017-05-31 | 上海亿账通互联网科技有限公司 | Distributed transaction processing method and system |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7725446B2 (en) * | 2005-12-19 | 2010-05-25 | International Business Machines Corporation | Commitment of transactions in a distributed system |
| JP2010224935A (en) * | 2009-03-24 | 2010-10-07 | Olympus Corp | Distributed processing system |
| US8868514B2 (en) * | 2011-01-07 | 2014-10-21 | Microsoft Corporation | Transaction support for distributed data |
| CN103345502B (en) * | 2013-07-01 | 2017-04-26 | 曙光信息产业(北京)有限公司 | Transaction processing method and system of distributed type database |
| CN103577588A (en) * | 2013-11-12 | 2014-02-12 | 西安雷迪维护系统设备有限公司 | Implement method for distributed transactions in cloud data base |
| CN104793988B (en) * | 2014-01-20 | 2019-01-22 | 阿里巴巴集团控股有限公司 | The implementation method and device of integration across database distributed transaction |
| US10296371B2 (en) * | 2014-03-17 | 2019-05-21 | International Business Machines Corporation | Passive two-phase commit system for high-performance distributed transaction execution |
| CN104216955B (en) * | 2014-08-20 | 2017-12-26 | 百度在线网络技术（北京）有限公司 | A kind of operation data and the method, apparatus and distributed system for managing affairs |
| CN104866403B (en) * | 2015-05-13 | 2016-09-21 | 上海钢富电子商务有限公司 | Distributed task scheduling processing system and method |
| CN106503132B (en) * | 2016-10-19 | 2019-07-16 | 广州快塑电子科技有限公司 | A kind of distributed transaction management method and system |
-
2018
- 2018-06-04 CN CN201810564968.5A patent/CN109002462B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103514028A (en) * | 2012-06-14 | 2014-01-15 | 北京新媒传信科技有限公司 | Method and device for processing distributed transactions |
| CN104424018A (en) * | 2013-08-23 | 2015-03-18 | 阿里巴巴集团控股有限公司 | Distributed calculating transaction processing method and device |
| CN105721337A (en) * | 2014-12-04 | 2016-06-29 | 中国移动通信集团公司 | Distributed transaction processing method and device in software definition network |
| CN106557514A (en) * | 2015-09-29 | 2017-04-05 | 中兴通讯股份有限公司 | A kind of distributed transaction rollback method and device |
| CN106775959A (en) * | 2016-12-06 | 2017-05-31 | 上海亿账通互联网科技有限公司 | Distributed transaction processing method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109002462A (en) | 2018-12-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109002462B (en) | Method and system for realizing distributed transaction | |
| CN108459919B (en) | Distributed transaction processing method and device | |
| CN109739935B (en) | Data reading method and device, electronic equipment and storage medium | |
| US9348641B2 (en) | System and method for performing a transaction in a massively parallel processing database | |
| US20220004542A1 (en) | Method and apparatus for updating database by using two-phase commit distributed transaction | |
| CN103995691B (en) | Service state consistency maintenance method based on transactions | |
| CN105988862A (en) | Distributed transaction processing method and device | |
| EP3193256A1 (en) | A fault-tolerant data processing computer system and method for implementing a distributed two-tier state machine | |
| CN108845866B (en) | Method and apparatus for processing distributed transactions | |
| CN110837505B (en) | State data storage method, state data synchronization device and storage medium | |
| US20230110826A1 (en) | Log execution method and apparatus, computer device and storage medium | |
| CN115098229A (en) | Transaction processing method, device, node equipment and storage medium | |
| Moser et al. | Asynchronous fault-tolerant total ordering algorithms | |
| Pandey et al. | LIFT-A new linear two-phase commit protocol | |
| CN109408201B (en) | Transaction management method based on distributed database | |
| CN111143041B (en) | Data consistency method, distributed coordinator and central coordinator | |
| CN110532069B (en) | Distributed transaction submitting method and device | |
| CN111625323A (en) | Distributed task processing method, device, equipment and computer readable storage medium | |
| Fan et al. | Method of maintaining data consistency in microservice architecture | |
| CN112162988A (en) | Distributed transaction processing method and device and electronic equipment | |
| Hahm | Distributed Systems | |
| Manikandan et al. | An efficient non blocking two phase commit protocol for distributed transactions | |
| WO2023124431A1 (en) | Database processing method and related device | |
| CN114169889A (en) | Alliance chain transaction system and method based on Avalanche consensus | |
| CN117675185A (en) | Cryptographic protocol transaction management method, medium and device based on transaction message |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |