directory

  • background
  • What are distributed transactions
  • What do we mean by reverse compensation
  • Seata, the most popular distributed transaction component on the Internet
  • conclusion

background

Hello, everyone. Today, I’m going to share with you a technology that will almost certainly be asked when going out to interview Java in 2022, and that is SEATA. What?? You read the first sentence and there’s a million question marks in your mind? Because you’ve never heard of seata? That’s okay. Just so you guys don’t get blindfolded when they go out for an interview and get asked about Seata, we’re going to explain it to you today.

Seata is a component in the popular Spring Cloud Alibaba that is designed to help us solve distributed transactions. In other words, SEATA is a distributed transaction framework.

What are distributed transactions?

What is a distributed transaction? Well, just to keep you going, let’s talk about what distributed transactions are.

The simplest example, suppose that now you are responsible for an order system, an inventory system, a marketing system, and then, when your order system receives a request to create order, this time you have to do three things, first, call interface lock stock inventory system, second, call marketing system interface lock coupons, third, Your order system itself has to insert a series of order data into MySQL, as shown in Figure 1 below:

Figure 1

So now the question is, your order system has its own order database, you can insert order data, 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 in coupons? Of course it is! Everyone has their own database, and this one is indispensable, as shown in Figure 2 below:

Figure 2

Now the problem comes again, since a request to create an order, to involve the order, inventory, marketing three systems, respectively operate their own three databases, in order to complete the request.

Student: Is it possible to have a situation where, first of all, you call the inventory system, lock the inventory, O. Then you call the marketing system, lock the coupon, and cancel. Finally, when your order system tried to insert data into its own order database, the network blew up, causing you to fail to insert the order data this time, resulting in a direct exception and confusion, as shown in Figure 3 below:

Figure 3

What did you think that this may lead to what kind of problem, actually very simple, this time the order you want to buy the inventory has been locked, you use coupons to under the order, has also been locked, as a result, your order data and no access to the data of their own, and then returns a said the exception information to the user, the order to fail. But you said the order failed to fail, the result, the operation may look at the inventory data in a confused face, why some goods inventory is locked, the result is no corresponding with the order, and no one has paid to buy it? After checking their coupons, the user managed to save several coupons to buy things. As a result, the order has not been placed and the coupons have been used, so he can’t use these coupons, as shown in Figure 4 below:

Figure 4.

In fact this is a classic problem of a distributed transaction, you create an order request, across three orders, inventory, marketing system, involving three databases respectively, all are likely to find that your inventory and marketing data operation is a success, and inventory and marketing database, local transactions are submitted, the results order insert database failed, The local transactions in the order database are rolled back, but the local transactions in the inventory and marketing database are committed and they are not rolled back, as shown in Figure 5 below:

Figure 5

What do we mean by reverse compensation?

Now that the problem has been identified, what effect should we be hoping for? In fact, we hope that if the order fails to be inserted into the database and the local transaction of the order database is rolled back, we should try to notify the inventory system and marketing system, and modify the submitted data in the inventory database and marketing database to make a reverse compensation and restore.

What do we mean by reverse compensation? If the system had performed an INSERT in the database, it would have performed a delete to delete the data previously inserted. If the system had performed a DELETE, it would have performed an INSERT to insert the data back into the database. If the system had performed a UDPATE statement, it would have performed an INSERT to insert the data back into the database. You should now execute an UPDATE statement again to restore the data to its previous state, as shown in Figure 6 below:

Figure 6.

Seata, the most popular distributed transaction component on the Internet

Since we want to achieve this effect, the problem is that we cannot solve this problem by ourselves. 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 be embedded in every system and we will need to deploy a SeATA Server, as shown in Figure 7 below:

Figure 7.

Seata in the order system will send a request to SeATA Server to open a global transaction. Then the inventory system will run first. When it performs database CRUD, these operations will be intercepted by the SEATA framework. The SeATA framework then inserts your SQL statement and the reverse compensation log into your inventory database in a local transaction. There must be an undo_log table in the inventory database to store the seATA 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 it. If your SQL is UPDATE, the reverse compensation log can record the old data before you update it. It can help you update the data to the old state, as shown in Figure 8:

Figure 8.

Your inventory system of SQL statements and their compensation log, is in a local transaction submitted together, together with success or failure, so whenever your inventory system update is successful, will have corresponding compensation log will be in stock in the database, for a rainy day, the operation of the marketing system is actually the same principle.

So that the inventory system and marketing system, and according to this train of thought are completed, to the ordering system, he almost quit as a result, insert the order database failure, of course, when inserted in fact have log will be submitted together with the corresponding compensation, but because the network problems, lead to insert orders with insert compensation log failed, Therefore, the seATA of the order system will report to the Seata Server and say, “Dear brother, I have finished my calf here. Why don’t you notify the inventory and marketing brothers and reverse compensate, as shown in Figure 9 below?”

Figure 9.

And then Seata Server discovers that all of these distributed transactions have failed, so let’s go ahead and tell the seata framework brothers in the inventory system and in the marketing system, and say, guys, let’s go ahead and get the compensation log from the undo_log table that was inserted into your database and build a reverse compensation SQL, Update SQL, reverse compensation SQL, run quickly, restore the data to me, the first team changed to the second team, run forward, hurry up, as shown in figure 10 below:

Figure 10.

conclusion

Seata server will tell other systems to use undo log to build compensation SQL and roll back all data.

If you want to learn how to design a complex distributed order architecture based on SEATA in a real complex large order project, learn all kinds of difficult scheme design and code implementation, click to see “Large-scale enterprise distributed Order System Project Practice”

END

Scan code for free 600+ pages of Huisei teachers original fine articles summary PDF

Summary of original technical articles