Must I use message queue? Let’s talk about why we should use it

This article brings you relevant knowledge about message queues. It mainly introduces the reasons why we use message queues and why we should use message queues. For those who are interested, let’s take a look. I hope everyone has to help.

Why use message queue, six words summary: decoupling, asynchronous, peak elimination

1)Decoupling

System in traditional mode The coupling between them is too strong. How to put it, for example: System A sends data to three systems B, C, and D through interface calls. If system E is connected in the future or system B does not need to be connected, system A will still need to modify the code, which is very troublesome. .

If system A generates a relatively critical piece of data, then it must always consider if the four systems B, C, D, and E are down. What to do? Have they all received this data? Clearly, System A is heavily coupled with other systems.

And if we write data (message) into the message queue, the system that needs the message directly consumes it from the message queue itself. In this way, System A does not need to consider who to send data to, nor does it need to maintain this code, nor does it need to consider whether other systems are successfully called, failure timeout, etc. Anyway, I am only responsible for production, and I don't care about anything else.

2) Asynchronous

Let’s first look at the traditional synchronization situation. For example: System A receives a user The request requires a library writing operation, and the same library writing operation needs to be performed in the three systems B, C, and D. If A writes the library locally, it only takes 1ms, while the three systems B, C, and D take 100ms, 200ms, and 300ms respectively. The final total request delay is 1 100 200 300 = 601ms, which greatly reduces the user experience.

If you use the message queue, then system A only needs to send 3 messages to the message queue. If it takes 5ms, system A will receive one from The total time from request to return response to the user is 1 5 = 6ms. For the user, the experience satisfaction is directly maximized.

#3) Peak elimination

If no cache or message queue is used, then the system is directly based on the database MySQL , if there is such a peak period and a large number of requests flood into MySQL, there is no doubt that the system will crash directly.

If we use the message queue, assume that MySQL can process up to 1k pieces of data per second, and 5k pieces of data flood in during the peak period. However, these 5k pieces of data flow into the message queue. In this way, our system can slowly pull requests from the message queue according to the capabilities of the database, and do not exceed the maximum number of requests it can handle per second.

That is to say, 5k requests come in and 1k requests go out of the message queue every second. Assuming the peak period is 1 hour, then there may be hundreds of thousands or even millions of requests backlogged in the message queue during this period. in queue. However, this short peak backlog is completely acceptable, because after the peak period, there will not be so many requests entering the message queue per second, but the database will still process it at a rate of 1k requests per second. Therefore, as soon as the peak period is over, the system will quickly process the backlog of messages.

Recommended study: "Redis Video Tutorial"

The above is the detailed content of Must I use message queue? Let’s talk about why we should use it. For more information, please follow other related articles on the PHP Chinese website!