To improve system performance, the first thing to consider is the optimization of the database, but due to historical reasons, horizontal expansion of the database is a very complicated project, so we generally try to block all traffic before the database.
Whether it is infinitely scale-out servers or vertically blocking traffic to the database, this is the idea. Blocking the traffic directly to the database, the cache component and the message component are two major killers. Here we will focus on the application scenarios of MQ.
1. Introduction to MQ
MQ: Message queue, message queue, refers to a container for storing messages. The specific definition here is not similar to databases, caches, etc., which are used to store data. Of course, compared with products such as databases and caches, it also has its own characteristics. The specific characteristics will be introduced in detail later.
Now commonly used MQ components include activeMQ, rabbitMQ, rocketMQ, and zeroMQ. Of course, Kafka, which has been popular in recent years, is also MQ in some scenarios. Of course, Kafka has more powerful functions. Although different MQs have their own characteristics and advantages, However, no matter what kind of MQ it is, there are some characteristics of MQ itself. Next, let's talk about the characteristics of MQ first.
2. MQ features
l First in first out
It can't be first in first out, and it can't be said to be a queue. The order of the message queue is basically determined when entering the queue, and generally no manual intervention is required. And, most importantly, the data is only one piece of data in use. This is why MQ is used in many scenarios.
l Publish and subscribe
Publishing and subscribing is a very efficient processing method. If there is no blocking, it can basically be regarded as a synchronous operation. This processing method can effectively improve server utilization, and such application scenarios are very extensive.
l Persistence
Persistence ensures that the use of MQ is not just an auxiliary tool for some scenarios, but allows MQ to store core data like a database.
l Distributed
In today's large traffic and big data usage scenarios, server software that only supports single applications is basically unusable, and only distributed deployment can be widely used. Moreover, the positioning of MQ is a high-performance middleware.
3. Application scenarios
Message queue middleware is an important component in a distributed system. It mainly solves problems such as application decoupling, asynchronous messages, and traffic shaving, and realizes high performance, high availability, scalability, and eventual consistency architecture. The currently used message queues are ActiveMQ, RabbitMQ, ZeroMQ, Kafka, MetaMQ, RocketMQ
3.1. Message middleware monitoring
Activemq monitoring
Rabbitmq monitoring
Kafka monitoring
3.2. Asynchronous processing
Scenario description: After the user registers, he needs to send a registration email and a registration SMS. There are two traditional methods: 1. Serial way; 2. Parallel way
a. Serial mode: After successfully writing the registration information into the database, send the registration email, and then send the registration SMS. After the above three tasks are all completed, return to the client.
b. Parallel mode: After successfully writing the registration information into the database, send the registration SMS at the same time as sending the registration email. After the above three tasks are completed, return to the client. The difference from serial is that the parallel method can improve the processing time
Assuming that each of the three service nodes uses 50 milliseconds, without considering other overheads such as the network, the serial time is 150 milliseconds, and the parallel time may be 100 milliseconds.
Because the number of requests processed by the CPU per unit time is certain, assume that the throughput of the CPU within 1 second is 100 times. Then the CPU can handle 7 requests (1000/150) within 1 second in the serial mode. The amount of requests processed in parallel is 10 times (1000/100)
Summary: As described in the above case, the performance (concurrency, throughput, response time) of the system in the traditional way will have a bottleneck. How to solve this problem?
The introduction of message queues will not require business logic and will be processed asynchronously. The modified structure is as follows:
According to the above agreement, the user's response time is equivalent to the time for the registration information to be written into the database, which is 50 milliseconds. After registering an email, sending a short message and writing it into the message queue, it returns directly, so the speed of writing to the message queue is very fast, which can basically be ignored, so the user's response time may be 50 milliseconds. Therefore, after the architecture change, the throughput of the system is increased to 20 QPS per second. It is 3 times higher than serial and 2 times higher than parallel.
3.3. Application decoupling
Scenario description: After the user places an order, the order system needs to notify the inventory system. Traditionally, the order system calls the interface of the inventory system. As shown below:
Disadvantages of the traditional model: If the inventory system cannot be accessed, the order will fail to reduce the inventory, resulting in order failure, and the order system is coupled with the inventory system
How to solve the above problems? The solution after introducing the application message queue is shown in the following figure:
Order system: After the user places an order, the order system completes the persistence process, writes the message to the message queue, and returns the user's order successfully
Inventory system: Subscribe to the news of the order, and use the pull/push method to obtain the order information, and the inventory system performs inventory operations according to the order information
If: The inventory system is not working properly when placing an order. It does not affect the normal order placement, because after the order is placed, the order system writes to the message queue and no longer cares about other follow-up operations. Realize the application decoupling of order system and inventory system
3.4. Flow clipping
Traffic shaving is also a common scenario in message queues, and it is generally used in seckill or group grabbing activities.
Application scenario: In seckill activities, generally due to excessive traffic, the traffic will increase sharply and the application will hang up. To solve this problem, it is generally necessary to add a message queue at the front end of the application.
a. The number of people who can control the activity
b. It can alleviate the application of high traffic in a short period of time
After the user's request is received by the server, it is first written into the message queue. If the message queue length exceeds the maximum number, the user request will be discarded directly or the error page will be redirected.
The seckill business performs follow-up processing according to the request information in the message queue.
3.5. Message communication
Message communication means that message queues generally have built-in efficient communication mechanisms, so they can also be used in pure message communication. For example, implement point-to-point message queues, or chat rooms, etc.
Point-to-point communication:
Client A and client B use the same queue for message communication.
Chat room communication:
Client A, client B, and client N subscribe to the same topic to publish and receive messages. Achieve a chat room-like effect.