1: Distributed things to understand:
Distributed Transaction refers to participants in the transaction, transactional servers, server and transaction manager resource are located on different nodes of different distributed systems. Is a major operation by the composition of different small operation, these small operations distributed across different service nodes, distributed transactions need to ensure that these small operations either all succeed, or all fail; in essence, is to ensure distributed transaction the consistency of data from different databases.
2: Distributed causes of errors:
a) a database sub-library sub-table;
When the data in a database table single year generated more than 1000W, then we must consider sub-library sub-table, simply means that the original database becomes a multiple databases, this time, if an operation both access 01 libraries, and access 02 library, but also to ensure data consistency, it is necessary to use a distributed transaction.
b) Application of the SOA;
It is the business of service. Such as the original stand-alone support the entire electricity supplier site, now the dismantling of the entire site, isolated the Order Center, Customer Center, inventory centers, for Order Center, a dedicated database to store the order information, the user center also has a dedicated database storage user information, inventory center will have a dedicated database for storing inventory information, If you want to order and inventory operations, it will relate to the order database and inventory database, in order to ensure data consistency, you need to use a distributed transaction.
In both cases different appearance, but essentially the same, because the database is to be operated changed much.
3) distributed usage scenarios:
Payments: sum payment, the buyer is a debit account, but add money to the seller accounts, these operations must be executed in a single transaction, either all succeed, or all fail, and the seller's account database corresponding to the seller, the buyer correspondence buyers database, operating on different databases necessitates the introduction of a distributed transaction.
Online orders: orders in electronic business platform, often involves two actions, one buckle inventory, and the second is to update the order status, inventory and order generally belong to a different database, you need to use distributed transactions to ensure data consistency .
4) Common distributed transaction solutions:
a) based on two-phase XA protocol submission,
XA is a distributed transaction agreement, XA are roughly divided into two parts: the local transaction manager and resource manager. Where the local resource managers are often implemented by the database, and transaction manager as a global schedule, responsible for the various local resources commit and rollback.
XA protocol is relatively simple, and once commercial databases to achieve the XA protocol, but also the cost of using distributed transactions, XA also has fatal flaws, that is, the performance is not satisfactory, often high concurrency, XA can not meet the high concurrency scenarios.
b) the consistency of the final message transactions +
The so-called news of the transaction is based on a two-stage submission of messaging middleware is a special use of messaging middleware essence, it is the local transaction message and placed in a distributed transaction, or to ensure the success of the local operation is successful and outgoing messages succeed or both fail, the open source RocketMQ to support this feature.
Specific principles:
Their order of execution:
b.1) A preparation system sends a message to the message broker;
b.2) messaging middleware ready to save the message and return success;
b.3) messaging middleware ready to save the message and return success;
b.4) A message middleware to send a commit message;
For the analysis performed in this order:
A step error, the whole transaction fails, does not perform a local operation of A;
Step two errors, the whole transaction fails, it does not perform a local operation of A;
Step three errors, this time the need to roll back the provisioning message, rollback method,: A system implements a callback interface messaging middleware, messaging middleware will continue to perform the callback interface, check whether A transaction execution is successful, if it fails then back roll provisioning message.
Step four mistakes, this time A local transaction is successful, the rollback A successful local operations, does not require a rollback: A fact can check to perform successfully through the callback interface, messaging middleware, this time actually do not need to send A submit news, messaging middleware can submit their own messages, thus completing the entire message transaction.
c) submit a distributed transaction-based messaging middleware is a two-stage high concurrency scenarios:
For example: a distributed transaction is split into a transaction message (A messaging system local operating +) + B local operating system
B is driven by the operating system messages, as long as the message transaction is successful, then A must operate successfully, the message must be sent, and this time B will receive a message to local operation. If the local B fails, the message will re-enter until the B operation is successful. This disguise a distributed transaction A and B, respectively.
While the above scheme can complete the operation A and B, but A and B are not strictly identical, but eventually consistent, of course, this play is risky, if B has been unsuccessful implementation, the consistency will be destruction, specifically whether or not to play, still have to see how much risk businesses can afford.
d) TCC programming mode,
TCC programming mode, is a variant of the two-phase commit.
TCC provides a programming framework, the entire business logic is divided into three: Try, Confirm Cancel and three operations.
Online orders, for example: Try going to buckle inventory stage, Confirm stage is to update the order status, order if the update fails, then enter Cancel phase, will go to restore inventory, TCC is to achieve a two-phase commit human through code, different business scenario written code are not the same, not the same degree of complexity, and therefore, this model can not be reused very well.
4) Summary:
Distributed transaction, the transaction is essentially a database of more unified control, in accordance with control efforts can be divided into: no control, partial control and total control. It is not without introducing distributed transaction control; the control portion is a variety of variants of two-phase commit, comprising the above-mentioned message transaction + final consistency, the TCC mode; complete control of two-phase commit is fully realized.
Portion control benefits is a good amount of concurrency and performance, data consistency drawback is weakened, complete control is at the expense of performance, guarantee consistency, specific somehow, ultimately depends on the business scene
----- -----------
Disclaimer: this article is the original article CSDN bloggers "wanghang88", and follow CC 4.0 BY-SA copyright agreement, reproduced, please attach the original source link and this statement.
Original link: https: //blog.csdn.net/wanghang88/article/details/79762761