Today, when reading, to see the consistency of distributed transactions, to quickly write it down.
I. Introduction distributed transactions
We usually write the code, we can contain as many SQL calls with a transaction if an exception occurs a database operation, you can manipulate all previous SQL rollback only if it's SQL operations are successful, it carried out submission, which ensures transactional consistency.
Look to pull Photo
However, in a distributed environment, multiple database operations may be split into three separate database access services, in which case the original call to a local SQL evolved into a remote service call, transactional consistency can not be guaranteed, pull the sheets map view
A and B services added service call is successful, the SQL A and B will be submitted, the final implementation service C, its SQL operation failed, then the C roll back, here, has led to inconsistent transaction.
Second, the design of a distributed transaction
Typically, a distributed transaction based on a two-phase implementation that works diagram is as follows:
Phase 1: global transaction manager sends all transaction participants prepare request, transaction participants respond to the global transaction manager if they are ready.
Stage 2: A global transaction manager receives a reply so make a judgment after the transaction participants, if all participants can submit the transaction, then all transactions are sent to the submitter submit an application, or rolled back. Transaction commit or rollback participants according to an instruction of a global transaction manager.
Distributed Transaction rollback is as follows:
Two stage uses a pessimistic locking strategy, because each transaction participants waiting for the response of the slowest players, so the relatively poor performance. And the whole process is the need to lock, and when the coordinator fails, the entire transaction to wait until after the coordinator reply to proceed.
So you can use instead of the traditional eventual consistency and strong consistency, try to avoid the use of distributed transactions.
Third, the Distributed Transaction Optimization
Commonly used in practice, the final solution is to use MQ consistency with the transactional capabilities of the middleman role, works as follows:
Before doing local affairs, Xianxiang MQ preapre send a message, and then perform local transactions, local transaction commit is successful, a message is sent to the MQ commit message, or send a message rollback cancel before. MQ will only receive a commit message delivery confirmation will be out, so this form can be guaranteed under all normal circumstances, local affairs and MQ can achieve consistency.
However, if the transaction is successful implementation of the system, not enough time to send commit to MQ, or network timeouts and other issues led MQ commit not received, then the MQ message delivery is not'll prepare to go out. After MQ will try to ask (callback) messaging system to check whether the message should be delivered out or discard the strategy to obtain confirmation system, MQ will do delivery or discarded, thus fully guaranteed and MQ messaging system consistency, so as to ensure the consistency of the received message system.