background
Since I want to tell you what is seata, I have to talk about the positioning of this thing first. This thing is a component in the popular Spring Cloud Alibaba, which is designed to help us solve distributed transaction problems. That is to say, seata is a distributed transaction framework.
What is a distributed transaction
That may be confusing to many small partners. What is a distributed transaction? Well, in order to ensure that everyone can continue to read, let's first talk about what is a distributed transaction.
To give the simplest example, suppose you are in charge of an order system, an inventory system, and a marketing system. Then, when your order system receives a request from a user to create an order, you have to do three things at this time. matter.
First, call the interface of the inventory system to lock the inventory. Second, call the interface of the marketing system to lock the coupons. Third, your order system has to insert a series of order data into MySQL.
For example, as shown in Figure 1 below:
So now the question is, your order system has its own order database, you can insert order data, so should the inventory system also have its own inventory database to lock the inventory data?
Should the marketing system have its own marketing database to lock coupons? Of course it is! Everyone has their own database, and this one is indispensable.
As shown in Figure 2 below:
Now the problem comes again. Since a request to create an order involves the three systems of order, inventory, and marketing, and operates their own three databases respectively, this request can be completed.
Is it possible that there will be such a situation, first of all, you call the inventory system first, and the inventory is locked, O.
Then, you called the marketing system again, locked the coupon, and it was O. Finally, when your order system is about to insert data into your order database, the network is convulsed, causing you to fail to insert order data this time, and the exception is abnormal directly, and you are confused.
As shown in Figure 3 below:
At this time, what kind of problems do you think may arise? It is actually very simple. At this time, the inventory of the goods you want to buy for this order has been locked, and the coupon you used to place this order has also been locked.
As a result, the data of your order itself did not enter the database, and then returned an exception message to the user saying that the order failed this time.
But if you say that the order fails, it will fail. As a result, the operation may be confused when looking at the inventory data. Why are some commodity inventories locked, but there is no corresponding order, and no one has paid for the purchase? Woolen cloth? ?
Then the user is also a little confused, because after checking his own coupons, he finally saved a few coupons to buy things, but now the order has not been placed, and the status of the coupons has been used, and he still cannot use these discounts. coupons.
As shown in Figure 4 below:
In fact, this is a very classic distributed transaction problem. Your request to create an order spans the three systems of order, inventory, and marketing, and involves three databases respectively.
It is very likely that you will find that your inventory and marketing data operations are successful, and the local transactions in the inventory and marketing databases are submitted. As a result, the order insertion database fails, and the local transactions in the order database are rolled back, but the inventory and the local transactions in the marketing database have been committed, they will not be rolled back.
As shown in Figure 5 below:
What is Reverse Compensation
Now that the problem has been found, what effect should we hope for?
The effect we actually hope is that if the order fails to be inserted into the database and the local transaction of the order database is rolled back, we should find a way to notify the inventory system and marketing system to modify the data that has been submitted in the inventory database and marketing database before. Make a reverse compensation and restore.
What is reverse compensation? That is to say, if the previous inventory system executed insert in the database, then delete should be executed at this time to delete the previously inserted data.
If the delete was executed before, the insert should be executed now to reinsert the deleted data. If the udpate statement was executed before, an update statement should be executed again now to restore the data to the state before the update.
As shown in Figure 6 below:
The Internet's most popular distributed transaction component seata
Since we want to achieve this effect, the problem arises at this time. We cannot solve this problem by relying on ourselves alone. At this time, we must introduce the big component in Spring Cloud Alibaba, seata.
Seata is designed to help us solve this problem. If we introduce the seata framework into the system, seata will actually be embedded in every system, and we also need to deploy a seata server.
As shown in Figure 7 below:
At this time, the operating principle of our system will become like this: seata in the order system will send a request to the seata server to start a global transaction, and then the inventory system will run first. When it is performing database crud, these operations will be executed by the seata framework to intercept.
Then the seata framework will insert your sql statement and reverse compensation log into your inventory database in a local transaction. There must be an undo_log table in the inventory database to store seata's reverse compensation log.
So what is this reverse compensation log? Simple, if your sql is insert, the reverse compensation log can help you build a delete statement to delete later, if your sql is update, then the reverse compensation log can record the old data before you update, it can help you follow up with the data update to the state of the old version.
As shown in Figure 8 below:
The sql statements of your inventory system and their compensation logs are submitted together in a local transaction, and they succeed or fail together, so whenever your inventory system is updated successfully, there must be corresponding compensation logs in the inventory In the database, in case of emergency, the marketing system actually works on the same principle.
Then suppose that the inventory system and the marketing system have been implemented according to this idea, and when it comes to the order system, he ends up with a pick, and the insertion into the order database fails.
Of course, when inserting, there will actually be a corresponding compensation log that will be submitted together, but because of network problems at this time, the insertion order and the insertion compensation log will fail together.
So at this time, the seata of the order system will report to the seata server and say, brother, I'm done here, why don't you notify the inventory and marketing brothers, and make reverse compensation.
As shown in Figure 9 below:
Then the seata server found out that this distributed transaction has failed, so hurry up, he will notify the seata frame brother in the inventory system and marketing system and say, brothers, hurry up, insert the previous undo_log table in your database Take out the compensation log and build a reverse compensation sql.
If it was insert before, you should make a delete for me, if it was delete before, you should make an insert for me, if it was an update before, you should still make an update, reverse compensation sql quickly run, restore the data to me, change the front team to the back team, Run forward, hurry up.
As shown in Figure 10 below:
Summarize
Great, so far, we have discovered the role of the boss of seata. Your order, inventory, and marketing systems run casually. If anyone fails, the seata server will notify other systems after receiving your failure notification. Use the undo log log to build compensation sql, and roll back all the data, perfect.