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

This article introduces the relevant knowledge of "web distributed transaction example analysis". In the operation process of actual cases, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations! I hope you can read carefully and learn something!

In the distributed era, sub-database sub-table is very common, micro-service system, each system usually uses independent database, so it is difficult to rely on the database itself to ensure that transactions can only rely on business systems to solve.

For example, the balance treasure and flower in Alipay are not clear, but guess it should be 2 services, not the same database. When we spend money, we usually deduct it from the balance treasure. This is distributed transaction. Money is deducted from one system and money is added to one system.

Below we analyze the implementation scheme of final consistency. Final consistency is usually implemented using message middleware. The system structure is as follows:

The user initiates a transfer request to system A. A first deducts money from its own database, and then tells B that it should add money through the message middleware. B adds money to its own database after receiving it.

Here is a key problem, A updates the database and sends messages to the messaging middleware are two operations, how to deal with the following two scenarios:

Update the database first, succeeded, but failed to send the message, retransmission multiple times or failed

The first message succeeded, but the database update failed, and the message could not be withdrawn.

Because these two operations are not atomic, anyone has problems.

Let's see if we can do this by putting updating the database and sending messages to the messaging middleware into a single transaction. Isn't that atomic?

There are problems, such as:

If the message fails to be sent, what is the problem? Did the message middleware not receive the message at all, or did it make an error in responding after receiving the message? If it is not received at all, it is better, if it is received but the response fails, it will be troublesome, causing A database to roll back, no money deducted, but B received the message and added money.

What if network latency is high when sending messages, database transactions are dragged all the time, performance is poor, and risk is high?

Therefore, this method of putting it into a transaction is undesirable.

In order to ensure atomicity, you can add a message table. A does not send messages directly to the messaging middleware, but writes messages to the message table, and then continuously writes messages to the messaging middleware through a background program.

This background program continuously sends messages from the message table to the messaging middleware. If it fails, it will try again. It can ensure that:

Messages are not lost

The order is correct.

However, there will be cases where the message is repeated, because the message sending failure may be a write failure, or it may be a write success but a response failure, so the message may be repeated, and this problem needs to be handled by System B.

System B requires two considerations:

message loss

B gets the message from the message middleware, but it goes down before it is processed. What about this message?

It needs to be processed through ACK mechanism. If the consumption succeeds, ACK will be sent. For messages without ACK, the message middleware will push them again.

message repetition

ACK mechanism also exists message duplication, for example, B has finished processing a message, when sending ACK failed, then this message will be pushed over.

There is also the background program mentioned above may be repeated when sending messages.

For the problem of repeated messages, a weight table can be added to record the successfully processed messages. Each time a message is received, it is judged by the weight table first. If it is repeated, it will not be processed to achieve idempotent.

Thus, the overall structure becomes:

"Web distributed transaction example analysis" content is introduced here, thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

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.