CN112671827A - Distributed transaction final consistency method - Google Patents
Distributed transaction final consistency method Download PDFInfo
- Publication number
- CN112671827A CN112671827A CN202011342691.5A CN202011342691A CN112671827A CN 112671827 A CN112671827 A CN 112671827A CN 202011342691 A CN202011342691 A CN 202011342691A CN 112671827 A CN112671827 A CN 112671827A
- Authority
- CN
- China
- Prior art keywords
- message
- service
- distributed transaction
- sent
- sending
- 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.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention provides a distributed transaction final consistency method, which comprises the steps of message pre-sending, service logic execution, service A message updating state updating, message sending, message consumption, service logic execution, service B message updating state updating, message confirmation service A, message confirmation service B and exception handling in sequence, and provides an independent message service and a corresponding message SDK, so that a relatively strong consistency scheme is simple to realize, and the system concurrency is increased; compared with a TCC scheme, the method has the advantages of small invasiveness, simple realization and low development and maintenance cost; the method can finish the final distributed transaction, and solves the problem that the existing final consistency scheme can not completely ensure consistency.
Description
Technical Field
The invention belongs to the technical field of transaction processing, and particularly relates to a distributed transaction final consistency method.
Background
With the popularity and popularity of distributed service architectures, the multiple logical operations originally performed in a monolithic application are now split into remote calls between multiple services. Although the services bring horizontal scaling capability to our system, the challenge is the problem of distributed transaction, multiple services use their own individually maintained databases, which are not in the same transaction, if a is successfully executed, B is failed to be executed, and a transaction a is already submitted and cannot be rolled back, the problem of inconsistency of data on both sides is finally caused; although XA distributed transactions based on two-phase commit have been known since early times, such schemes have resulted in poor performance due to the need for global locking of resources; therefore, a distributed transaction scheme of flexible transactions such as final consistency of messages, TCC (transmission control efficiency) and the like is gradually derived;
1. the message generator sends a message;
2. the MQ receives the message, persists the message and adds a record in the storage;
3. returning ACK to the producer;
4. the MQ pushes the message to the corresponding consumer, and then the consumer is waited to return ACK;
5. if the message consumer successfully returns the ACK within the designated time, the MQ considers that the message is successful and deletes the message in the storage, namely, the step 6 is executed; if the MQ does not receive the ACK within the specified time, considering that the message consumption fails, trying to push the message again, and repeatedly executing the steps 4, 5 and 6;
6. MQ deletes the message;
objective disadvantages of the prior art:
two-phase commit XA distributed transaction: the realization is complex and strong in consistency, and the concurrency performance is seriously influenced; TCC flexible transaction distributed scheme: the method has strong invasion to the microservice, each transaction of the microservice must realize 3 methods such as try, confirm and cancel, the development cost is high, and the cost of maintenance and modification in the future is also high; the existing common message final consistency scheme: there is a consistency problem; for example: taking order creation as an example, an order system creates an order (local transaction) first and then sends a message to downstream processing; if the order is successfully created, but the message is not sent out, all downstream systems cannot sense the event, and dirty data can occur; if the order message is sent first, then the order is created; there is a possibility that the message was successfully sent but failed at the time of order creation, at which point the downstream system believes that the order was created and dirty data may also appear.
Disclosure of Invention
In view of this, the present invention is directed to provide a distributed transaction final consistency method, which mainly solves the problem of transaction final consistency in such a scenario, where a request for transaction consistency exists between different services in a cloud computing distributed architecture.
In order to achieve the purpose, the technical scheme of the invention is realized as follows:
a distributed transaction final consistency method comprises the following steps
S1, pre-sending of the message: before executing local service logic, the service A firstly calls a message service interface through a message SDK and stores the message in a consumption service corresponding database;
s2, executing business logic: the service A executes business logic needing to guarantee transactions;
s3, service a updates the message status: the service A calls the message service to update the message state to CanSend through the SDK;
s4, message sent: a message sending task in the message service periodically acquires a message which can be sent but is not sent from a database of the message service and sends the message to a RabbitMQ;
s5, message consumption: the message consumer-service B registers the consumer to the RabbitMQ through the SDK, and receives and consumes the message when the message exists in the RabbitMQ;
s6, executing business logic: service B executes business logic within the transaction;
s7, service B updates message status: the service B calls the message service through the SDK according to the result of executing the service logic, and updates the message state to be complete or Failed;
s8, message confirmation service a: a message confirmation task A in the message service regularly acquires a message which is in a Created state and is not sent after time-out, and confirms whether the message can be sent to a message source end (namely, the service A);
s9, message confirmation service B: a message confirmation task B in the message service regularly acquires a message which is in a sent state and does not receive feedback after time out, and confirms whether the message is executed to a message target end (namely, the service B);
s10, exception handling: the information failure notification service in the information service periodically sends the information with the states of Sendfailed, AckFailed and Failed to an administrator, and finally the administrator manually processes the abnormity
Further, said step S1, when the state of the message is Created; the service A is synchronously called through the SDK, the message service stores the message in a local library and then returns the success or failure of storing the local library; if the message service fails to store the message, the message service is directly abnormal, and the service A does not execute logic downwards; if successful, execute step 2
Further, in the step S3, when the message status is cantend, the service a is called synchronously through the SDK, so as to ensure that the update status is successful, and if the update status fails, the step 8 performs bottom verification on the message status
Further, in the step S4, the message sending task is a timing task, and the timing time needs to be configured by itself; when the state of the acquired message is CanSended; the message sending includes a retry strategy, the retry strategy comprising: only once sent; sending the signals for N times at the same time interval; transmitting N times between the minimum interval and the maximum interval, each time the transmission interval is increased by the same value
Further, in step S5, the service B receives the message through the consumer registered in the RabbitMQ; after service B obtains the message, it will cache the unique message ID into Redis
Further, in step 7, if the service logic B is successfully executed, the update message status is complete, and the whole distributed transaction is Completed; if the service B service logic fails to execute, the message state is updated to Failed; if the execution fails, the manual bottom-packing step 10 is performed
Further, in step S8, the message confirmation task a in the message service needs to set the timeout time and the number of queries in a customized manner; if the message is not answered after a number of queries, the message is set to SendFailed and eventually manual bottoming is performed in step 10
Further, in step S9, the message confirmation task B in the message service needs to set the timeout time and the number of queries in a customized manner; if the message is not answered after a number of queries, the message is set to AckFailed and eventually manual bottom stitching is performed in step 10
Further, in step S10, the message failure notification service sets the timing task time and the priority of sending the administrator mail or short message and the message by user, and the message failure notification service may set different feedback levels and the timing task time according to the priority
Compared with the prior art, the distributed transaction final consistency method has the following advantages:
(1) the final consistency method of the distributed transaction provides independent message service and corresponding message SDK, and the scheme with relatively strong consistency is simple to realize, and the system concurrency is improved; compared with a TCC scheme, the method has the advantages of small invasiveness, simple realization and low development and maintenance cost; the method can finish the final distributed transaction, and solves the problem that the existing final consistency scheme can not completely ensure consistency.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, serve to explain the invention and not to limit the invention. In the drawings:
FIG. 1 is a block diagram of a background art according to an embodiment of the present invention;
fig. 2 is a block diagram of a distributed transaction final consistency method according to an embodiment of the present invention.
Detailed Description
It should be noted that the embodiments and features of the embodiments may be combined with each other without conflict.
In the description of the present invention, it is to be understood that the terms "center", "longitudinal", "lateral", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", and the like, indicate orientations or positional relationships based on those shown in the drawings, and are used only for convenience in describing the present invention and for simplicity in description, and do not indicate or imply that the referenced devices or elements must have a particular orientation, be constructed and operated in a particular orientation, and thus, are not to be construed as limiting the present invention. Furthermore, the terms "first", "second", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first," "second," etc. may explicitly or implicitly include one or more of that feature. In the description of the present invention, "a plurality" means two or more unless otherwise specified.
In the description of the present invention, it should be noted that, unless otherwise explicitly specified or limited, the terms "mounted," "connected," and "connected" are to be construed broadly, e.g., as meaning either a fixed connection, a removable connection, or an integral connection; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meaning of the above terms in the present invention can be understood by those of ordinary skill in the art through specific situations.
The present invention will be described in detail below with reference to the embodiments with reference to the attached drawings.
The noun explains:
service A and service B are both microservices, for example, service A is that user service B is an order service, and the user needs to deduct money from the user service after purchasing goods, deduct money from the order service, deduct money from the user service, deduct money from the order service, and deduct money from the order service, wherein if the user services succeed at the same time, the user services fail at the same time.
ANSI is a character code that typically uses 1 byte in the range 0x00-0x7f to represent 1 english character in order for a computer to support more languages.
An API (Application Programming Interface) is a predefined function or convention for interfacing different components of a software system to provide a set of routines that an Application and developer can access based on certain software or hardware without accessing source code or understanding details of internal workings.
The RabbitMQ is open source message agent software (also called message-oriented middleware) which realizes an Advanced Message Queuing Protocol (AMQP), the RabbitMQ server is written in Erlang language, the cluster and the failover are constructed on an open telecommunication platform framework, and all main programming languages have client libraries which communicate with agent interfaces.
The SDK (Software Development Kit) can simply provide some files of the API for a certain programming language, and can be embedded in a certain code engineering to conveniently provide API for the program to realize a certain function.
The XA protocol was first proposed by Tuxedo and handed to the X/Open organization as an interface standard for the resource manager (database) and the transaction manager.
The X/Open organization consolidates various UNIX standards together, including the recently developed general Open System Environment (daoCOSE), a series of specifications published by X/Open, collectively referred to as X/Open connectivity, with the MOTIF user interface being one of the widely used standards.
Unix is an operating system that appeared in the early 70 s of the 20 th century and can be used as a stand-alone operating system in addition to a network operating system.
Redis (remote Dictionary Server), a remote Dictionary service, is an open source log-type and Key-Value database written in ANSI C language, supporting network, based on memory and persistent, and provides API of multiple languages.
And (4) Created: the message is created and may not be sent.
Can Send: the message may be sent.
Sendfailed: the message transmission failed.
And (3) sending: the message has been sent.
Complete: the message is complete.
Failed: the message execution fails.
AckFailed: the message feedback fails.
TCC: the advantage of the TCC over the direct mode is that under some scenes, the TCC makes your distributed transaction more consistent with the business experience.
try, confirm, cancel: TCC requires the server to provide more specific interfaces, including Try interface, Confirm interface and Cancel interface.
Idempotent: used in the programming arts, means that for the same system, using the same conditions, one request and multiple requests repeated will have a consistent effect on system resources.
As shown in fig. 2, a distributed transaction final consistency method includes the following steps:
s1, pre-sending of the message: before executing local service logic, the service A firstly calls a message service interface through a message SDK and stores the message in a consumption service corresponding database;
s2, executing business logic: the service A executes business logic needing to guarantee transactions;
s3, service a updates the message status: the service A calls the message service to update the message state to CanSend through the SDK;
s4, message sent: a message sending task in the message service periodically acquires a message which can be sent but is not sent from a database of the message service and sends the message to a RabbitMQ;
s5, message consumption: the message consumer-service B registers the consumer to the RabbitMQ through the SDK, and receives and consumes the message when the message exists in the RabbitMQ;
s6, executing business logic: service B executes business logic within the transaction;
s7, service B updates message status: the service B calls the message service through the SDK according to the result of executing the service logic, and updates the message state to be complete or Failed;
s8, message confirmation service a: a message confirmation task A in the message service regularly acquires a message which is in a Created state and is not sent after time-out, and confirms whether the message can be sent to a message source end (namely, the service A);
s9, message confirmation service B: a message confirmation task B in the message service regularly acquires a message which is in a sent state and does not receive feedback after time out, and confirms whether the message is executed to a message target end (namely, the service B);
s10, exception handling: the method comprises the steps that a message failure notification service in the message service sends messages with states of SendFailed, AckFailed and Failed to an administrator at regular time, the administrator handles the exception manually finally, and provides an independent message service and a corresponding message SDK, so that a relatively strong consistency scheme is simple to realize, and the system concurrency is improved; compared with a TCC scheme, the method has the advantages of small invasiveness, simple realization and low development and maintenance cost; the final completion of distributed transactions can be realized, and the problem that the consistency cannot be completely ensured by the conventional final consistency scheme is solved;
said step S1, when the state of the message is Created; the service A is called synchronously through the SDK, and the synchronous calling promotes the consistency of subsequent message distribution; if the message service fails to store the message, the message service is directly abnormal, and the service A does not execute logic downwards any more, so that final consistency is promoted; if successful, executing step 2 to promote final consistency;
in the step S3, when the message status is cantend, the service a is called synchronously by the SDK, so as to ensure that the update status is successful, and if the update status fails, the message status is verified at step 8, and the message processing efficiency can be further ensured by the step 8;
in the step S4, the message sending task is a timing task, and the timing time needs to be configured by itself; when the state of the acquired message is CanSended; the message sending includes a retry strategy, the retry strategy comprising: only once sent; sending the signals for N times at the same time interval; sending N times between the minimum interval time and the maximum interval time, gradually increasing the same value at each sending interval, ensuring that the message is sent for a certain time at step S4, but possibly sending the same message for multiple times, so that the step S5 is required to ensure idempotency, ensuring the reliability of message sending and receiving completely by the characteristics of a RabbitMQ, and not being described again;
said step S5, the service B receives the message through the consumer registered in the RabbitMQ; after the service B acquires the message, the unique message ID is cached in Redis, if the unique message ID exists, the message is not processed, and the idempotency is ensured;
in step 7, if the service B service logic is successfully executed, the update message status is complete, and the whole distributed transaction is Completed; if the service B service logic fails to execute, the message state is updated to Failed; if the execution fails, the step 10 of manual bottom-packing improves the reliability of message processing;
in step S8, the message confirmation task a in the message service needs to set timeout time and query times by user-defined; if the message is not answered after being inquired for many times, the message is set to be SendFailed, and finally the manual bottom-digging is carried out in the step 10, the degree of freedom of users is improved by setting the overtime and the inquiry times in a self-defined mode, and the reliability of message processing is improved by the manual bottom-digging in the step 10;
in step S9, the message confirmation task B in the message service needs to set the timeout time and the number of queries by user-defined rules; if the message is not answered after being inquired for many times, the message is set to be AckFailed, and finally the step 10 is carried out by manual bottom-stitching, and the step 10 improves the reliability of message processing;
in step S10, the message failure notification service sets the timing task time, the priority of sending administrator mails or short messages, and messages by user, and sends information through multiple media, so as to improve the success rate of message transmission.
The invention is general and is only exemplified here by orders.
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 that fall within the spirit and principle of the present invention are intended to be included therein.
Claims (9)
1. A distributed transaction end-to-end consistency method, characterized by: comprises the following steps
S1, pre-sending of the message: before executing local service logic, the service A firstly calls a message service interface through a message SDK and stores the message in a consumption service corresponding database;
s2, executing business logic: the service A executes business logic needing to guarantee transactions;
s3, service a updates the message status: the service A calls the message service to update the message state to CanSend through the SDK;
s4, message sent: a message sending task in the message service periodically acquires a message which can be sent but is not sent from a database of the message service and sends the message to a RabbitMQ;
s5, message consumption: the message consumer-service B registers the consumer to the RabbitMQ through the SDK, and receives and consumes the message when the message exists in the RabbitMQ;
s6, executing business logic: service B executes business logic within the transaction;
s7, service B updates message status: the service B calls the message service through the SDK according to the result of executing the service logic, and updates the message state to be complete or Failed;
s8, message confirmation service a: a message confirmation task A in the message service regularly acquires a message which is in a Created state and is not sent after time-out, and confirms whether the message can be sent to a message source end (namely, the service A);
s9, message confirmation service B: a message confirmation task B in the message service regularly acquires a message which is in a sent state and does not receive feedback after time out, and confirms whether the message is executed to a message target end (namely, the service B);
s10, exception handling: and the message failure notification service in the message service periodically sends the messages with the states of SendFailed, AckFailed and Failed to an administrator, and finally the administrator manually processes the exception.
2. A distributed transaction end coherence method according to claim 1, wherein: said step S1, when the state of the message is Created; the service A is synchronously called through the SDK, the message service stores the message in a local library and then returns the success or failure of storing the local library; if the message service fails to store the message, the message service is directly abnormal, and the service A does not execute logic downwards; if successful, step 2 is performed.
3. A distributed transaction end coherence method according to claim 1, wherein: in step S3, when the message status is cantend, the service a is called synchronously through the SDK, so as to ensure that the update status is successful, and if the update status fails, step 8 verifies the message status.
4. A distributed transaction end coherence method according to claim 1, wherein: in the step S4, the message sending task is a timing task, and the timing time needs to be configured by itself; when the state of the acquired message is CanSended; the message sending includes a retry strategy, the retry strategy comprising: only once sent; sending the signals for N times at the same time interval; the transmission is performed N times between the minimum interval time and the maximum interval time, and the transmission interval is increased by the same value step by step.
5. A distributed transaction end coherence method according to claim 1, wherein: said step S5, the service B receives the message through the consumer registered in the RabbitMQ; after service B obtains the message, it will cache the unique message ID into Redis.
6. A distributed transaction end coherence method according to claim 1, wherein: in step 7, if the service B service logic is successfully executed, the update message status is complete, and the whole distributed transaction is Completed; if the service B service logic fails to execute, the message state is updated to Failed; manual bottoming is performed in step 10 if execution fails.
7. A distributed transaction end coherence method according to claim 1, wherein: in step S8, the message confirmation task a in the message service needs to set timeout time and query times by user-defined; if the message is not answered over multiple queries, the message is set to SendFailed and eventually manually bottomed by step 10.
8. A distributed transaction end coherence method according to claim 1, wherein: in step S9, the message confirmation task B in the message service needs to set the timeout time and the number of queries by user-defined rules; if the message is not answered over multiple queries, the message is set to AckFailed and eventually manually bottomed by step 10.
9. A distributed transaction end coherence method according to claim 1, wherein: in step S10, the message failure notification service sets the timing task time and the priority of sending the administrator mail or short message and the message by user, and the message failure notification service may set different feedback levels and timing task time according to the priority.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011342691.5A CN112671827B (en) | 2020-11-25 | 2020-11-25 | Distributed transaction final consistency method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011342691.5A CN112671827B (en) | 2020-11-25 | 2020-11-25 | Distributed transaction final consistency method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112671827A true CN112671827A (en) | 2021-04-16 |
| CN112671827B CN112671827B (en) | 2023-03-07 |
Family
ID=75403612
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011342691.5A Active CN112671827B (en) | 2020-11-25 | 2020-11-25 | Distributed transaction final consistency method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112671827B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112991022A (en) * | 2021-04-21 | 2021-06-18 | 福建天晴在线互动科技有限公司 | Method and system for realizing final consistency of distributed order system data by using MQ |
| CN113452602A (en) * | 2021-06-21 | 2021-09-28 | 网易（杭州）网络有限公司 | Message transmission method and device, electronic equipment and storage medium |
| CN113742043A (en) * | 2021-08-31 | 2021-12-03 | 中企云链（北京）金融信息服务有限公司 | Asynchronous splitting method for server backend task |
| CN113867897A (en) * | 2021-09-30 | 2021-12-31 | 紫光云技术有限公司 | Method for realizing distributed transaction based on Rabbitmq |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6425017B1 (en) * | 1998-08-17 | 2002-07-23 | Microsoft Corporation | Queued method invocations on distributed component applications |
| CN107861823A (en) * | 2017-11-23 | 2018-03-30 | 国云科技股份有限公司 | A kind of method of the system security data final consistency based on micro services framework |
| CN109471704A (en) * | 2018-11-02 | 2019-03-15 | 上海艾融软件股份有限公司 | A kind of flexible transaction methods based on message-oriented middleware |
| CN109542639A (en) * | 2018-11-06 | 2019-03-29 | 用友网络科技股份有限公司 | A kind of processing method, processing unit for ensureing micro services and calling data consistency |
| CN110049135A (en) * | 2019-04-23 | 2019-07-23 | 深圳市泰蔟科技有限公司 | A kind of cloud storage extended method and memory expansion unit |
| CN110968438A (en) * | 2019-11-29 | 2020-04-07 | 江苏满运软件科技有限公司 | Asynchronous notification method and device of event message, electronic equipment and storage medium |
| CN111198751A (en) * | 2018-11-20 | 2020-05-26 | 北京京东尚科信息技术有限公司 | Service processing method and device |
| CN111209092A (en) * | 2020-01-09 | 2020-05-29 | 江苏艾佳家居用品有限公司 | Distributed transaction processing method based on Saga mode |
| CN111367628A (en) * | 2020-03-05 | 2020-07-03 | 中国银行股份有限公司 | Distributed transaction processing method and device, message producer and consumer system |
-
2020
- 2020-11-25 CN CN202011342691.5A patent/CN112671827B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6425017B1 (en) * | 1998-08-17 | 2002-07-23 | Microsoft Corporation | Queued method invocations on distributed component applications |
| CN107861823A (en) * | 2017-11-23 | 2018-03-30 | 国云科技股份有限公司 | A kind of method of the system security data final consistency based on micro services framework |
| CN109471704A (en) * | 2018-11-02 | 2019-03-15 | 上海艾融软件股份有限公司 | A kind of flexible transaction methods based on message-oriented middleware |
| CN109542639A (en) * | 2018-11-06 | 2019-03-29 | 用友网络科技股份有限公司 | A kind of processing method, processing unit for ensureing micro services and calling data consistency |
| CN111198751A (en) * | 2018-11-20 | 2020-05-26 | 北京京东尚科信息技术有限公司 | Service processing method and device |
| CN110049135A (en) * | 2019-04-23 | 2019-07-23 | 深圳市泰蔟科技有限公司 | A kind of cloud storage extended method and memory expansion unit |
| CN110968438A (en) * | 2019-11-29 | 2020-04-07 | 江苏满运软件科技有限公司 | Asynchronous notification method and device of event message, electronic equipment and storage medium |
| CN111209092A (en) * | 2020-01-09 | 2020-05-29 | 江苏艾佳家居用品有限公司 | Distributed transaction processing method based on Saga mode |
| CN111367628A (en) * | 2020-03-05 | 2020-07-03 | 中国银行股份有限公司 | Distributed transaction processing method and device, message producer and consumer system |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112991022A (en) * | 2021-04-21 | 2021-06-18 | 福建天晴在线互动科技有限公司 | Method and system for realizing final consistency of distributed order system data by using MQ |
| CN113452602A (en) * | 2021-06-21 | 2021-09-28 | 网易（杭州）网络有限公司 | Message transmission method and device, electronic equipment and storage medium |
| CN113742043A (en) * | 2021-08-31 | 2021-12-03 | 中企云链（北京）金融信息服务有限公司 | Asynchronous splitting method for server backend task |
| CN113742043B (en) * | 2021-08-31 | 2024-04-26 | 中企云链股份有限公司 | Asynchronous splitting method for server back-end tasks |
| CN113867897A (en) * | 2021-09-30 | 2021-12-31 | 紫光云技术有限公司 | Method for realizing distributed transaction based on Rabbitmq |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112671827B (en) | 2023-03-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112671827B (en) | Distributed transaction final consistency method | |
| CN109542639B (en) | Processing method and processing device for guaranteeing consistency of microservice calling data | |
| CN107787490B (en) | Direct connect functionality in a distributed database grid | |
| US5802062A (en) | Preventing conflicts in distributed systems | |
| US9417977B2 (en) | Distributed transactional recovery system and method | |
| JP5841177B2 (en) | Method and system for synchronization mechanism in multi-server reservation system | |
| US8364634B2 (en) | System and method for processing fault tolerant transaction | |
| US9336291B2 (en) | Message based synchronization for mobile business objects | |
| US20040158549A1 (en) | Method and apparatus for online transaction processing | |
| US6381617B1 (en) | Multiple database client transparency system and method therefor | |
| US6389431B1 (en) | Message-efficient client transparency system and method therefor | |
| CN109241186A (en) | Management method, system, computer equipment and the storage medium of distributed transaction | |
| CN111198751A (en) | Service processing method and device | |
| US10540344B2 (en) | Utilizing nonce table to resolve concurrent blockchain transaction failure | |
| US7636873B2 (en) | Enhancement of assured event delivery mechanism to eliminate external XA store requirement | |
| US10318520B2 (en) | System and method for reducing communications overhead in a distributed transactions environment by modifying implementation of the transaction end function | |
| CN111061801A (en) | Transaction type database read-write separation implementation method | |
| US7165061B2 (en) | Transaction optimization of read-only data sources | |
| US20040153349A1 (en) | Delayed creation of global transactions | |
| CN112559496A (en) | Distributed database transaction atomicity realization method and device | |
| WO2023134614A1 (en) | Processing of transaction | |
| US7171410B1 (en) | Fault tolerant network element | |
| JPH11161530A (en) | Transaction processing system | |
| US9984096B2 (en) | System and method for reducing communications overhead in a distributed transactions environment by modifying implementation of the transaction start function | |
| CN112965837A (en) | Configuration and service hot overload updating method, device, computer equipment and storage medium |
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 |