The final consistent MQ implementation of distributed transactions _ distributed transactions

The origin of the problem distributed system characteristics

Readers who have studied distributed systems may have heard "cap law", "base theory" and so on, and it is a coincidence that the acid in the chemical theory is sour and base is exactly the base. Here we do not explain the concepts too much, interested readers can see the relevant reference materials.

Here for consistency we do a simple science:

Distributed transactions have strong consistency, weak consistency, and final consistency of these three kinds:

Strong consistent

When an update operation completes, access to any number of subsequent processes or threads will return the most recent updated value. This is the most user-friendly, that is, what the user wrote last time, the next time to ensure that what can be read. According to CAP theory, this implementation requires sacrificing usability.

Weak consistent

The system does not guarantee that the continuation process or the access of the thread will return the most recent updated value. After the data is written successfully, the system does not promise to read the latest write value immediately, nor how long it will be read after the specific commitment.

Final agreement

A particular form of weak consistency. The system guarantees that the system will eventually return the value of the last update operation without subsequent updates. In the absence of failure, the time of the inconsistent window is mainly affected by the communication delay, the system load and the number of replicas. DNS is a typical final consistency system

In distributed systems, it is almost impossible to satisfy the "cap law" of "consistency", "availability" and "partitioning fault tolerance". Most of the scenes in the Internet field, all need to sacrifice strong consistency in exchange for the high availability of the system, the system often only need to ensure "final consistency", as long as the final time is acceptable to the user can be, when we only need to use the short data inconsistency can achieve the desired effect. Instance Description

For example, there are orders, inventory two data, a single process to simplify to, add an order, minus one inventory. and order and inventory are independent services, that how to ensure data consistency.

At this point we need to think about how to ensure that two remote calls "at the same time", the data is consistent.

Please pay attention to a little bit. Remote invocation The most depressing place is that there are 3 kinds of results, success, failure and timeout. It is possible to fail successfully if you timeout.

General solution, most of the practice is to use MQ to do the final agreement. How to achieve the final consistent case analysis

How do we use MQ to achieve the final consensus? Let's take a detailed analysis together: Order Business Analysis

First, take the order business we mentioned above for example: in the process of adding an order we insert loga at the same time (this process can be done locally) and then we can read the Loga asynchronously, send the MQA B-end to receive MQA, and reduce the inventory, b it needs to be idempotent (to avoid business confusion due to duplicate messages) Complex, mixed asynchronous business calls

Then we may associate this with the above analysis.

The local execution of the transaction, the success of the implementation of a message in the past, the consumer side to get the message to carry out their own affairs
For example, a,b,c a asynchronously calls B,c, if B fails, or b succeeds, or b times out, then how do you use MQ to make them end up consistent? B failed to fail, b after success to send a message to C, B and C for a is asynchronous, and they are all concurrent, and need to a,b,c the same time success, then this situation with MQ how to do

In fact, the practice is also referred to the concept of local affairs. In the first case: Assuming that the a,b,c are properly executed, the whole business ended normally. The second case: assuming b timeout, then need a to send a message to B (remember B service to do power, etc.), if there is a repeat failure, need to see the situation, is Terminal Services, or continue to hair, Even human intervention (all rules are set up according to business rules) The third: Suppose that one of the three a,b,c failed, the failed service uses MQ to send messages to other services, other services receive messages, query local transaction log logs, and if local fails, delete the received message ( Indicates the success of the message consumption, if local success, then need to invoke the compensation interface for compensation (requires each service to provide a business compensation interface). Attention matters

MQ has a pit here, usually only for the first operation to fail the scene, that is, the first successful after the operation must be guaranteed to have no business obstacles, or the back of the failure of the front is not good rollback, only allow system exception failure, not allow business failure, Usually the failure of a business is not likely to succeed at all, if the failure of the network or downtime can be resolved by retrying, if the business is abnormal, it can only send a message to a and C let them make compensation. Typically compensated by a third party, ABC provides a compensating interface, and the design paradigm usually does not allow consumption downstream business to fail

How do we understand the above, for example:

For example, a to B transfer, a first to deduct their own money, and then sent a message, b this side if in this before the sale of households, then try how many times also useless, can only artificially intervene in the distributed transaction in the solution

Ali part of the business is to achieve the final consistency with MQ, also a part of the business used TCC transactions, but TCC transactions with less, because it will infect the business, the development cost is high, if the volume is not small words directly with JTA or MQ support transactions, in fact, in the distributed transaction this piece also has a kind of maximum effort type, There is also a way of not having a brain. Statement

The above views are personal summary, does not represent completely correct.

Author: jsondream
Link: http://www.jianshu.com/p/716d3ec567c0