1. Distributed Transaction analytical principle

1.1. TCC Distributed Transaction

Find out about TCC distributed transaction knows it has three stages: try, confirm, cancel, but many articles is only schematic, and interpretation of schematics, read through also leaving no impression, here for example the actual scene, TCC explain the principle of the distributed transaction

try stage: Suppose we order system, it needs to invoke the inventory and scoring system, try our stage is preprocessing , such as a single commodity, try the operation, we set up a frozen field in the inventory table shows freeze 1 a commodity, the stock of goods to not be deducted, and integrating the same table to add pre-increase integration fields, such as adding a pre-integration 10
confirm stage: Why do we try to go through stages? In order to ensure that all systems are working properly as possible, databases, services do not hang up, there is no lack of resources, you can ensure to the maximum extent confirm stage can be executed correctly, confirm stage is a formal inventory and increase the points deduction
cancel stage: if try to perform phase error , it will try to perform cancel operation on the stage has already been performed by the system, which is the reverse SQL rollback, frozen goods -1 -10 pre-integration. There is no doubt here? My first thought was if confirm or cancel the operation fails again how to do ? Here it must ensure that the TCC distributed transaction framework, and it will record the transaction activity log , and then confirm or cancel continue after a failed attempt to invoke logic confirm and cancel, so here need to develop themselves to ensure that your SQL is correct

TCC distributed framework recommended: ByteTCC, tcc-transaction, himly

1.2. The final consistency Distributed Transaction

1.2.1. Principle

The final consistency schemes were done with a message broker, core processes as shown above

Suppose service A upstream service, reliable messaging service for the service B, service C downstream services, the preferred B A sends a request to the message I will be represented, you prepare for the next, and B data is recorded to be confirmed;
A local database has completed a formal service logic, confirmation messages sent B, you say I run over, you can confirm, then B is updated status message has been sent, and sends a message to the MQ
C subscribed to the service at this time MQ, receives a message sent from B by MQ, the local database and perform operations manual ack confirm completion in consumption after the implementation, which completed the entire process

1.2.2. Issues

Let's consider this there are any problems, why this will ensure eventual consistency of distributed transactions?

The first is the process of service A calls B B if unsuccessful or if the service did not save the message to be confirmed, it is returned directly to the failure, no operation of the database, so there is no impact
A database operation and sends a confirmation message, we need to put the same local affairs, at the same time to ensure the success or failure of such a success, of course, no problem, fail? B service because the database already exists pending confirmation message, can be timed to be judged B service open threads confirmation message , if found to be a confirmation message has not been confirmed, initiate a request to the A, to determine whether the operation was successful? The success of the change status is confirmed, proceed, it fails to delete the record
MQ-B to process, if it fails, MQ hung like, we can service B from the background thread, determines the timing of the acknowledged message, after a certain time is sent into, no longer sends transmission
So after leaving the service to the C MQ, MQ has a retry mechanism, so as long as the business logic is no problem, we can ensure that the final consistency (this process needs to ensure MQ C service interface methods need idempotency)
The above-mentioned process requires a special attention MQ point is, we need to ensure that MQ high availability, or if all MQ is down, dependent on MQ distributed transaction can not be completed

1.2.3. MQ hang of how to do

The larger the company, the more consideration, any component may hang, MQ if it is a cluster, the cluster must consider this excessive pressure to explode how to do? Funded concurrent pressure companies can directly engage and then engage in a spare set, when the MQ request fails, automatically and immediately switch to the backup MQ cluster, of course, this will certainly be a waste of resources, after all, again do not run up a set of MQ put there, then here we are given a set of reference program (if you have redis clusters of words)

redis kind of data structure queue, which can be used to temporarily act as message queues, so here to discuss is, if redis as an alternative to consider what is the problem?
Notification mechanism : when MQ hung up, we all need to use MQ transactional systems are switched to the standby redis program, so we have a notification mechanism , it would have been similar to this notice MQ broadcast mode should be done, but did not MQ, we have other programs, such as zookeeper's watch mechanism, zk there listening mechanism can inform the listener that node system, the switch to open the downgrade, to the effect notify other systems
Message reads hot issues : redis we put the message queue will have a corresponding key, we can not put all messages in the value of a key, so this value will result in excessive data; so here Alternatives: divided hundreds queues, hash of the message into the queue, the message such as a key into different
Recovery failure : When we recover MQ, we have to notify the system, which switches back, this how to do it? You can open a thread, from time to time to try to deliver a message to see if MQ recovery, if restored, you can downgrade to turn off the switch by zookeeper again

Reference:
Please, please do not ask the interview I realized the principle of TCC distributed transactions!
How to guarantee consistency distributed transaction ultimately the actual production of 99.99% availability?