Distributed things

One .2PC-XA agreement

Two .3PC

3、 ... and . Local message table

Four . Reliable message final consistency scheme

5、 ... and . Best effort notification scheme

---

One .2PC-XA agreement

XA A transaction consists of one or more resource managers (Resource Managers)、 A transaction manager (Transaction Manager) And an app (Application Program) form

Explorer (RM)： participants . Provides access to transaction resources . Usually a database is a resource manager

Transaction manager (TM)： The coordinator . Assign identifier , Monitor the progress of the transaction , And responsible for transaction completion and fault recovery .

Applications (AP)： The initiator . Define the boundaries of the transaction , Set up operations in global transactions .

The whole process is divided into 2 Stages ： Get ready (prepare) And submit (commit),prepare You need to execute the corresponding DML operation .

But there are still some problems ：

1）commit The loss of / Timeout results in inconsistent data .A commit success ,B commit Network timeout caused the database not to receive commit request .

2） Low performance . All transaction participants are in synchronous blocking state while waiting for other participants to respond .

3） The active and standby data are inconsistent .

4） Coordinator single point of failure , Failure of the coordinator at any stage will result in the failure of distributed transactions .

Two .3PC

3PC By adding a timeout mechanism to the participants 2PC The single point of coordinator in brings the problem that the transaction cannot be carried out , But performance and consistency remain unresolved .

TCC The whole process is ：Try、Confirm、Cancel.

This actually uses the concept of compensation , There are three stages ：

1）Try Stage ： This stage is about testing the resources of each service and locking or reserving the resources

2）Confirm Stage ： This phase is about performing actual operations in various services

3）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

Let me give you an example , For example, when transferring money between banks , It's about distributed transactions involving two banks , If you use TCC Plan to achieve , This is the idea ：

1）Try Stage ： First, freeze the funds in the two bank accounts for it and then stop the operation

2）Confirm Stage ： Perform the actual transfer operation ,A Capital deduction from bank account ,B The increase of funds in the bank account

3）Cancel Stage ： If the operation of any bank fails , Then you need to roll back to compensate , For example A If the bank account has been deducted , however B The increase in bank account funds failed , Then we have to put A Add back the bank account funds

Through the retrial mechanism to protect Confirm and Cancel It will succeed .TCC Solved the performance problem , But the business system wants to realize the invasion of business code , You can learn from Ali GTS how .

3、 ... and . Local message table

foreign ebay It's a set of ideas

This probably means this

1）A The system operates in its own local transaction at the same time , Insert a piece of data into the message table

2） next A The system sends this message to MQ In the middle

3）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 , At this time, the transaction will roll back , This ensures that messages are not processed repeatedly

4）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

5） 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 a message that hasn't been processed , It will be sent again to MQ In the middle , Give Way B Deal with... Again

6） 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

To be honest, the biggest problem with this scheme is that it relies heavily on the message table of the database to manage transactions ？？？ This will lead to what if it is a high concurrency scenario ？ How to expand ？ So it is rarely used

 

Four . Reliable message final consistency scheme

This means , Just don't use the local message table , Based on the direct MQ To implement the transaction . Like Ali's RocketMQ Just support message transactions .

The general meaning is ：

1）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

2） 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

3） If a confirmation message is sent , So at this time B The system will receive a confirmation message , Then execute the local transaction

4）mq Will automatically poll all prepared Message callback your interface , Ask you , Is this message a local transaction failure , All didn't send a confirmation message ？ Do you want to try again or roll back ？ Generally speaking, you can check the database to see if the local transaction is executed before , If it rolls back , So roll back here . This is to avoid the possibility that local transaction execution succeeds , Don't confirm that the message failed to be sent .

5） In this plan , If the system B What should I do if my business fails ？ Try again , Automatically retrying until successful , If it doesn't work , Or roll back important fund businesses , 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 is more suitable , At present, most domestic Internet companies are playing like this , Or you can use RocketMQ Supported by , Or you'll base yourself on something similar ActiveMQ？RabbitMQ？ Encapsulate a set of similar logic , In a word, this is the way of thinking

 

5、 ... and . Best effort notification scheme

The general meaning of this plan is ：

1） System A After the local transaction is completed , Send a message to MQ

2） There will be a special consumption here MQ Best effort notification service , This service will consume MQ Then write it down in the database , Or put it in a memory queue , Then call the system B The interface of

3） 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