Shulou(Shulou.com)06/02 Report--

This article mainly explains "how to understand distributed transactions in web development". The content in this article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to understand distributed transactions in web development".

Cap

C: consistency is called an atomic object, and any read or write should appear to be "atomic" or serial. The read after writing must be able to read what was written before, and all read and write requests seem to be sorted globally.

A: any non-failed node should give a response to the request within a limited time.

P: allow any number of messages to be lost between nodes. When a network partition occurs, messages between nodes may be completely lost.

Personal understanding:

For C, it is to ensure that the state of each node is consistent at a point of time, while An is from the user's point of view that each node is normal, and P is that all nodes are connected normally.

But in the distributed environment, multi-instance deployment is the basic condition, because of the unreliability of the network, P becomes a hard condition, so the distributed system is basically cp and ap.

Base

Basic available (Basically Available)

Soft state (Soft State)

Final consistency (Eventually Consistent)

Personal understanding:

Base theory is basically an ap system, distributed transactions and business have a strong coupling relationship, because basically the business level to maintain an intermediate state so that transactions can have room for rollback without destroying data.

Secondly, because there is an intermediate state, it is basically consistent in the process of the transaction.

Xa

As shown in the figure, there are basically three roles

AP application

RM Explorer

TM transaction Manager

Personal understanding:

Basic resource managers need to implement their own resource management interfaces.

The application application requests the resource from the resource manager, and then the modification of the resource is not notified to the resource manager directly, but is prepared in advance, and then modified by the three transaction managers.

The systems that use this protocol are basically cp systems.

2pc/3pc

2pc:

Personal understanding:

After the transaction is executed in the prepare phase, the transaction is committed, and the transaction rollback is triggered as soon as there is a problem with the execution.

There may be inconsistencies due to network problems during the submission phase

Transactions depend on each other for success, and resources are locked for too long (blocking time is too long)

There is a timeout re-election for the transaction coordinator, but there is no timeout mechanism for each service

3pc:

Personal understanding:

A layer has been added on top of 2pc. I understand that this layer is to assist the timeout phase, because in the preCommit phase, all other services are confirmed to be successful. Finally, each service will start a timeout plan, which will directly commit instead of waiting for the coordinator to docommit, and docommit is a commit command, but each service may have a timeout mechanism because the network cannot receive it. This is to make up for the excessive blocking in 2pc and the lack of timeout mechanism on the server side.

Tcc

Personal understanding:

The essence of tcc is that the business in base provides an intermediate state to complete the overall transaction by preparing commit and rollback.

As a whole, the transaction manager is added to automate the process of managing transactions, for example, after downtime, the transaction manager will regularly execute the process of transactions in logging to ensure final consistency.

General distributed transactions pass global transaction id to identify transactions and solve idempotency.

Sega

Personally, I understand that sega is very much like 2pc, but sega's transactions are submitted by themselves. For centralized problems, the main business rolls back or retries, and for distributed but recursive forms, rollback.

The above questions

On the whole, I understand that sega is ultimately consistent, but there will be no intermediate state of base, so there will be isolation problems, such as phantom read repetition, read changes and other problems. For the solution, the framework corresponding to sega generally provides global read-write locks to provide isolation.

For the sagas framework, he implements a transaction coordinator to simplify the rollback and retry of transactions, and implements a mechanism to generate rollback sql by himself.

There are still many designs for sagas. At present, I do not have time to study the problem of rewriting the relevant sagas. (for the history of sagas, it seems that at first it was the Ali charging project gks. At that time, the disassembly code said that the implementation might be a tcc that automatically generated the rollback code, but now it seems to be the mode of saga plus a global lock.)

Sega2 rollback scheme

Backward recovery, restore backward, compensate for all completed transactions if any of the sub-transactions fail. That is, the second execution order mentioned above, where j is the sub-transaction where the error occurred, which has the effect of undoing all previous successful sub-transation, causing the execution result of the entire Saga to be undone.

Forward recovery, resume forward, retry the failed transaction, assuming that each subtransaction will eventually succeed. For scenarios that must be successful, the order of execution is similar to this: T1, T2,..., Tj (failed), Tj (retry),..., Tn, where j is the sub-transaction where the error occurred.

Centralized type

Distributed system

Thank you for reading, the above is the content of "how to understand distributed transactions in web development". After the study of this article, I believe you have a deeper understanding of how to understand distributed transactions in web development. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.