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

This article introduces what the message idempotency is in the message middleware MQ, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

Preface

Our buddies should have heard enough about the news middleware MQ, such as RabbitMQ,RocketMQ,Kafka and so on. The benefits of introducing middleware can resist high concurrency, peak shedding and business decoupling.

As shown above:

(1) order service delivers messages to MQ middleware (2) Logistics service listens to MQ middleware messages for consumption

This article discusses how to ensure that the order service successfully delivers messages to MQ middleware, taking RabbitMQ as an example.

Analyze the problem

Friends will have some doubts about this, the order service to launch a message service, the return of success will not be a success? Such as the following pseudo code:

In the above code, it is generally written to send a message. Do you think there is any problem with it?

Here is a scenario, what happens if the MQ server suddenly goes down? Is it true that all the messages sent by our order service are gone? Yes, generally MQ middleware will store messages in memory in order to improve the throughput of the system. If no other processing is done, once the MQ server goes down, all messages will be lost. This is not allowed by the business, resulting in a great impact.

Persistence

Experienced friends will say, I know one way is to persist the message. When sending a message in RabbitMQ, there will be a durable parameter that can be set to true, and it will be persisted.

In this way, even if the MQ server is down, there are messages stored in the disk file after restart, so that it will not be lost. Yes, this ensures that the message will not be lost with a certain probability.

But there will also be a scenario in which the message has just been saved in MQ memory but has not yet been updated to a disk file when it suddenly goes down. (shit, this time is so short, it will also happen, the probability is too low.) this scene will be very common in the process of continuous delivery of a large number of messages.

What can we do? What can we do to ensure that it will be persisted to disk?

Confirm mechanism

The above problem is that no one tells us whether persistence is successful or not. Fortunately, many MQ have the feature of callback notification, so RabbitMQ has a confirm mechanism to tell us whether the persistence is successful.

The principle of the confirm mechanism:

(1) the message producer sends the message to MQ. If it is received successfully, MQ will return an ack message to the producer.

(2) if the message is not received successfully, MQ will return a nack message to the producer

In the pseudocode above, there are two ways to handle messages, namely the ack callback and the nack callback.

Does this guarantee that 100% of the messages will not be lost?

Let's take a look at the mechanism of confirm and imagine that every time our producer sends a message, the MQ is persisted to disk, and then a callback of ack or nack is initiated. In this case, the throughput of our MQ is not very high, because we have to persist messages to disk every time. The action of writing to disk is slow, which is unacceptable in high concurrency scenarios, and the throughput is too low.

So the real implementation of MQ persistence disk is handled by asynchronous calls, and it has a certain mechanism, such as: when there are thousands of messages, it will flush the disk to the disk at once. Instead of swiping the disk every time a message comes.

Therefore, the comfirm mechanism is actually an asynchronous listening mechanism to ensure high throughput of the system, so that messages cannot be 100% guaranteed not to be lost, because even with the confirm mechanism, messages go down before being flushed to disk in MQ memory, and they still cannot be processed.

Having said so much, there is still no guarantee, so what should we do?

Message persistence in advance + scheduled task

In fact, the essential reason is that it is impossible to determine whether it is persistent or not. So can we persist the news ourselves? The answer is yes, and our plan will evolve further.

The process shown above:

(1) before delivering the message, the order service producer persists the message to Redis or DB. Redis is recommended for high performance. The status of the message is in progress.

(2) whether the monitoring message of confirm mechanism is sent successfully? For example, delete the ack success message in Redis.

(3) if the nack is not successful, this can choose whether to resend the message according to its own business. You can also delete this message, as determined by your own business.

(4) A scheduled task has been added here to pull the message after a certain period of time, and the message status is still in the process of being sent. This status indicates that the order service has not received the ack success message.

(5) scheduled tasks will make compensatory delivery messages. At this time, if the MQ callback ack is successfully received, delete the message in the Redis.

Such a mechanism is actually a compensation mechanism. No matter whether the MQ actually receives it or not, as long as the message status in my Redis is also "sending", it means that the message has not been delivered correctly. Then start the scheduled task to monitor and initiate compensation delivery.

Of course, we can also add a compensation number for the scheduled task. If it is more than 3 times and still does not receive the ack message, then directly set the status of the message to "failed", and let the manual check why.

In this way, the solution is more perfect, ensuring that 100% of the messages are not lost (of course, the disk is also broken, so you can make the master-slave scheme).

However, with such a solution, it is possible to send the same message many times. It is very likely that MQ has received the message that a network failure occurred during the callback of the ack message, which did not allow the producer to receive it.

Then it is necessary to require consumers to protect idempotence when spending!

Idempotent meaning

Let's first understand what idempotent is? In distributed applications, idempotency is very important, that is, the operation of a business under the same conditions, no matter how many times, the result is the same.

Why is there such a scene as idempotence?

Why is there such a scene as idempotence? Because in large systems, are distributed deployment, such as: order business and inventory business may be deployed independently, are separate services. When the user places an order, the order service and inventory service are called.

Because of distributed deployment, it is very likely that when invoking the inventory service, the invocation of the order service fails due to network and other reasons, but in fact, the inventory service has already been processed, but an exception occurred when the processing result was returned to the order service. At this time, the general system will make a compensation scheme, that is, the order service will once again put the call to the inventory service, and the inventory will be reduced by 1.

There is a problem, in fact, the last call has been reduced by 1, but the order service did not receive the processing result. Now it is called again, and it has to be reduced by 1, which is not in line with the business and will be deducted too much.

The idempotent concept is that no matter how many times the inventory service is called under the same conditions, the processing result is the same. Only in this way can the feasibility of the compensation scheme be ensured.

Optimistic locking scheme

Learn from the optimistic locking mechanism of the database, such as:

A unique ID is the only primary key of a business table, such as commodity ID

Fingerprint code is to distinguish each normal operation of the code, each operation to generate a fingerprint code; you can use a timestamp + business number.

The above sql statement:

If 0 means no operation has been performed, then you can insert into t_check (unique ID+ fingerprint code) after the business operation.

Returns that if greater than 0 indicates that the operation has been performed, it will be returned directly.

Benefits: easy to implement

Disadvantages: database bottleneck under high concurrency

Solution: algorithmic routing based on ID database and table

Redis atomic operation

Use the atomic operation of redis to mark the completion of the operation. This performance is better. But there will be some problems.

First: do we need to store the business results in the database? if so, the key problem to be solved is how to achieve atomicity in the database and redis operations?

This means that inventory is minus 1, but what if redis fails when it completes the mark? That is to say, we must make sure that the database and redis either succeed or fail together.

Second: if you do not drop the database, then all are stored in the cache, how to set the timing synchronization policy?

This means that inventory minus 1, do not drop the warehouse, directly operate the redis operation to complete the mark, and then store the inventory by another synchronization service, which increases the complexity of the system, and how to set the synchronization policy.

On the message middleware MQ message idempotency is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.