Implementation scheme of distributed transaction

CAP Theorem

To see distributed transactions, you must first understand CAP Theorem
CAP Theorem in distributed system is ： Uniformity , Usability , Zone tolerance

• Uniformity ： Whether the data of multiple nodes in a distributed environment is strongly consistent
• Usability ： Distributed services can consistently ensure availability , When the user makes a request , The service can return results in a limited time
• Zone tolerance ： Especially the tolerance of network partition

For shared data systems , At most, you can only have CAP Two of them , There's no way to balance the three

• Any combination of the two has its applicable scenarios
• The real system should be ACID and BASE Get the mixture
• Different types of businesses can and should be treated differently
  among ！ Partition tolerance is indispensable ！！！
  

BASE theory

The core idea

• Basic available （BasicallyAvailable）
  When a distributed system fails , Allow the availability of the lost part to ensure the core availability
• Soft state （SoftState）
  Allow distributed systems to have intermediate states , This intermediate state will not affect the overall availability of the system
• Final consistency （EventualConsistency）
  After a certain period of time, all the replica data of the distributed system , In the end, we can reach a consistent state

The consistency pattern of consistency model data can be divided into the following 3 class ：

• Weak consistency
  After the data is updated successfully , Data in all replicas is consistent at any time , It is generally realized in synchronous mode
• Final consistency
  A form of weak consistency , After the data is updated successfully , The system does not promise to return the latest written value immediately , But it is guaranteed that the value of the last update operation will be returned finally

Strong consistency of distributed system data , Weak and final consistency can be achieved by Quorum NRW Algorithm analysis

Distributed implementation scheme

There are mainly the following five schemes ：
XA programme ,TCC programme , Local message table , Reliable message final consistency scheme , Best effort notification scheme

XA programme （ Two stage proposal ）

So-called XA The proposal is also called two-phase submission , There is a concept of transaction manager , Responsible for coordinating multiple databases （ Explorer ） The business of , The transaction manager first asks whether each database is ready , If every database replies OK, Then formally submit the transaction , Perform operations on various databases , If there is any one of the data, answer no OK, Then roll back the transaction

This distributed transaction scheme , It is more suitable for single block applications , Distributed transactions across multiple libraries , And because it relies heavily on the database level to handle complex transactions , Efficiency is very low , Absolutely not suitable for high concurrency scenarios , If you want to play , Then based on Sprign+JTA You can do it

TCC programme

TCC The full name is ：Try ,Confirm,Cancel

• try Stage ： This stage is about checking the resources of various services and locking or reserving resources
• Confirm Stage ： This stage is to perform actual operations in various services
• Cancel Stage ： If the business method execution of any service is wrong , Then compensation is needed here , It is to perform the rollback operation of the successful business logic （ Roll back those successful execution ）

This scheme is rarely used at present , But there are also scenarios for use , For example, it is generally related to money , Payment when dealing with money , Trading related scenarios , Will use TCC, Strictly guarantee the success of distributed transactions , Or roll back all automatically , Strictly guarantee the correctness of funds , Make sure there are no problems with the money .

Local message table

See below for the general meaning ：

• A While the system operates in its own local transaction , Insert a piece of data into the message table
• next A The system sends this message to MQ In the middle
• B After the system receives the message , In a business , Insert a piece of data into your local message table , Perform other business operations at the same time , If the message has been processed , Then this transaction is rolled back , This ensures that messages are not processed repeatedly
• B After the successful execution of the system , It will update the status of its local message table and A Status of the system message table
• If B System processing failed , Then the message table status will not be updated , So at this time A The system will scan its message table regularly , If there is an unprocessed message , It will be sent again to MQ In the middle , Give Way B Deal with... Again
• This scheme guarantees final consistency , Even if the B The transaction failed , however A I'll keep sending messages back , until B Until we succeed there

The biggest problem with this scheme is that the Champions League relies heavily on the message table of the database to manage transactions , What if it is a high merger scene ？ Difficult to expand , Therefore, it is generally less used

Reliable message final consistency scheme

This scheme is to use no message table , Based on the direct MQ To implement the transaction , Like Ali's RocketMQ Just support message transactions
The meaning is as follows ：

• A The system sends a prepared The message to MQ, If this prepared If the message fails to be sent, cancel the operation directly and don't execute
• If this message has been sent successfully , Then we will execute the local transaction , Tell... If you succeed mq Send a confirmation message , If you fail, tell mq Rollback message
• If a confirmation message is sent , Then the system B You will receive a confirmation message , Then execute the local transaction
• mq Will automatically poll all prepared Message callback your interface , Ask you , Is this message a local transaction failure , So no confirmation message was sent , Continue to retry or rollback ？ Generally speaking, you can check the database to see if the local transaction is executed before , If it rolls back , Then roll back here , This is to avoid the possibility that local transaction execution succeeds , And the confirmation message failed to be sent
• In this plan , If the system B The transaction failed ？ Retry lo , Automatically retrying until successful , If it doesn't work , Or roll back the important capital business , such as B After the system locally rolls back , Find a way to inform the system A Also roll back , Or send alarm manually to rollback and compensate
• This plan is quite suitable , Or use it directly RocketMq Supported by , Or based on ActiveMQ perhaps RabbitMQ Encapsulate a set of such logic by yourself
  

Best effort notification scheme

The general meaning of this plan is as follows

• System A After the local transaction is completed , Send a message to MQ
• There will be a special consumption here MQ Try your best to inform the service , This service will consume MQ Then write it down in the database , Or put it into a memory queue , Then call the system B Have to interface
• If the system B If the implementation is successful OK 了 , If the system B Execution failed , Then the best effort notification service will periodically try to call the system again B, Over and over again N Time , In the end, if you can't, just give up