Distributed Transaction understand it? If you solve the problem of distributed transactions?
Interviewer mind:
As long as you do talk to distributed systems, distributed transaction must be asked, at least have to know which programs generally how to do, what the advantages and disadvantages of each option yes.
Why have distributed transactions?
Distributed transaction implementation of several options:
1. The two-phase commit scheme / XA program
This distributed transaction program, more suitable for application in a single block. Distributed transactions across multiple repositories , since as heavily dependent on the database level to get complex transactions, inefficient, definitely not suitable for highly concurrent scenarios.
If you want to play, then based on Spring + JTA can handle that.
The program, rarely used, in general, an internal system if such an operation across multiple library goes, is non-compliance.
If you want to operate the library service of others, you must be implemented by calling another service interface, and definitely not someone else's cross to access the database.
2. TCC(Try, Confirm, Cancel)方案
A compensation mechanism. In three stages:
- Try Stage: This stage talking to each service's resources to do testing and resource locking or reserved.
- Confirm Phase: This phase is to say actual operation is performed in each service.
- Cancel stages: if a business method any service execution error, this needs to be compensated, that has been executed successfully execute business logic rollback. (Those successful implementation of the rollback)
Cons: tight coupling with the business, transaction rollback rely heavily on their own to write code to rollback and compensation.
Applicable scene: scene dealing with money, payment, transaction . Need TCC, ensure strict distributed transaction either all succeed or all automatic rollback, and strictly ensure the correctness of the funds.
3. Local news list
Probably process:
1. A system while inserting a data processing local transaction table to the consumer.
2. A system then sends this message to the MQ.
3. B system after receiving the message, in a transaction, the message to its local table to insert a record, and perform service processing;
If this message has been processed, the message insert failed, the transaction is rolled back, guaranteed not to repeat the process the message.
4. If the processing system B is successful, to update their local status and consumption table A table system consumption state.
5. If the B-block processing fails, the message does not update the status table, A system periodically scans its own message table, if there is an unprocessed message, will be sent again to the MQ, so that the B system is performed again.
6. This scheme ensures that the final consistency, even if the transaction fails B system, but will continue to resend the message A, B until it succeeds.
Disadvantages: heavy reliance on a message table in the database to manage transactions. How to do high concurrency scenarios, access to the message table bottlenecks, are not easily expandable.
4. Reliable sources eventual consistency scheme ( domestic Internet pop )
Without local consumption table to implement the transaction directly on MQ. For example, Ali RocketMQ to support message transactions.
Probably process:
1. A system to send a message prepared MQ, if the message is directly cancel the operation fails.
2. If this prepared message is sent successfully, perform local transactions, if the transaction is executed successfully sends a message to confirm MQ, MQ rollback if it fails to tell the news.
3. If you send confirm message, then let B MQ system consumption this confirm message, and then performs local affairs.
4. MQ periodically poll all the prepared message, then A callback system interface, the message is rolled back view or a confirm message to be retransmitted.
A general system to see if the local transaction is successful, if rolled back, the message also rolled back. Avoid local transaction is executed successfully, and confirm the message failed to send.
5. If the B system transaction fails, keep retrying until it succeeds. If it is not, then find a way to roll back system A notification or warning sent by hand to manually roll back or compensation.
How your company distributed transactions?
If money is tight scene, with the TCC program;
If it is inserted after the order to invoke the service inventory update inventory, you can use eventually consistent and reliable messaging program.
Normally you should not use distributed transactions, code complexity, poor performance. A common call B, C, D, do not have to do a distributed transaction.
Generally is to monitor (e-mail, text messaging alarm), log (once the error, the complete log), and afterwards quickly locate, troubleshoot and solutions, temporary repair data.
Distributed transaction costs than doing much lower.
References:
"The Internet Advanced Java interview training camp," notes - China huperzine