Shulou(Shulou.com)06/03 Report--

This article introduces you from the double 11 business to see distributed transactions to meet Saga and asynchronous scenario example analysis, the content is very detailed, interested partners can refer to, I hope to help you.

At the time of Double 11, many e-commerce companies were promoting, including Jingdong.

We take Da Wei's book as an example. For example, when buying a book on Double 11, there is a red envelope in addition to a discount. In this way, when buying a book, there is a double discount, as shown in the following figure:

Then, in the double 11 scenario, a request to buy a book includes synchronous and asynchronous scenarios, as shown in the following figure.

The synchronous scenario adopts Saga, and the asynchronous scenario adopts transaction messages (Sagas+ local transaction message table). In other words, distributed transactions should be designed to meet both synchronous and asynchronous scenarios:

So, let's look at a successful double eleven shopping request.

Steps 1, 2, 3 and 4 in the following figure are respectively calling application modules A, B, C and D in the above figure.

In the figure above, we originate a request from the App and the request is assigned to any gateway layer and then to any amateur logical layer.

1. The business logic layer will first invoke the commodity data source access layer to reduce inventory (access DB).

2. After step 1 succeeds, the business logic layer accesses the order data access layer to create the order local transaction (access

DB), at the same time as placing the order, the business logic layer sends a delayed order payment message, i.e., a transaction message, to MQ.

3. After step 2 is successfully executed, the service logic layer invokes the red envelope data access layer to perform red envelope reduction operation.

(Visit DB). After success, the red packet data access will return success information to the transaction logic layer, the transaction logic layer will return success information to the network gateway layer, and the gateway layer will return information to the App.

4. The App page automatically jumps to the payment page, that is, the business logic layer calls the payment data access layer to make foreground payment.

Then the whole operation is complete.

What about the order payment message in MQ? When the delay payment message expires (24 hours for JD.com), the MQ order delay payment message will be sent to the business logic layer (because the business logic layer subscribes to MQ Topic), and then the business logic layer judges whether the order has been paid according to the transaction group table. If it has been paid, the delay message will be deleted directly. If the order is not paid, change the state in the transaction group table from 1 to 3 (failure):

Then TM triggers transaction compensation according to transaction call table: add red envelope back, order +1, delete order.

Finally, Proxy changes the state in the transaction group table from 1 to 4 (compensation successful).

So, if we look at the architecture above, where are the possible bottlenecks when hyper-requests arrive?

From the technical architecture point of view, gateway, transaction business logic layer, data access layer are stateless, can be horizontally expanded, there is no bottleneck. For DB, data can be divided into tables. For MQ, fragmentation is possible. There also appears to be no performance bottleneck.

So, why do shopping failures occur in Jingdong shopping on Double 11?

The reason is that there is hot data, that is, particularly hot goods, such as:

If we want to solve the hot spot data problem, we need to do hot spot data prediction. To do hot spot data prediction, you have to do asynchronous first. That is to say, purchase requests for hot and tight commodities are sent directly to MQ. Then, in turn, execute the business logic.

At this point, the hot spot will be pressed against MQ. At this point, we need to fragment MQ, but for a record of a commodity, how do we fragment it? You can add a column of Type to change one row of data into multiple rows:

Then we can eliminate hot spots by storing each row in an MQ Topic.

Since technically hot data can be eliminated, why double 11 Jingdong shopping still fails? Because purchasing servers costs money, double 11 e-commerce will guarantee the success rate of the transaction, but this success rate will not be 100%, which is a problem to consider from the perspective of ROI.

Summary: When designing a business architecture, we need to focus on the following three aspects of the architecture in view of the high concurrent traffic requests:

About from the double 11 business to see distributed transactions to meet Saga and asynchronous scenario example analysis shared here, I hope the above content can be of some help to everyone, you can learn more knowledge. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.