What are the application scenarios of java message queue?

1. What is a Queue

Queue is a common data structure. Its biggest feature is First In First Out. As the most basic data structure, queue application Very broad. For example, waiting in line at the train station to buy tickets, etc. The following figure can be used to represent the queue:

where a1, a2, and an represent the data in the queue. Data is put into the queue from the end of the queue, and then dequeued from the head of the queue.

2. What is a message queue?

Message Queue (Message Queue) is a method that uses a queue (Queue) as the underlying storage data structure and can be used to solve communication between different processes and applications. The distributed message container can also be called message middleware.

Currently commonly used message queues include ActiveMQ, RabbitMQ, Kafka, RocketMQ, Redis, etc.

What is the difference between message queue and queue?

The only difference is that when entering the queue, it is called a producer, and when it is dequeued, it is called a consumer.

3. Message queue application scenarios

Message queue application scenarios are very extensive. Below we list some of the more common scenarios

1. Distributed scenarios

1.1. Asynchronous processing

Generally, the programs we write are executed in sequence (that is, synchronously). For example, in the example of an order in an e-commerce system, the execution sequence is as follows:

The user submits the order. Points will be added after the order is completed. SMS notification of points changes.

can be represented by the following flow chart:

#If executed in the above order, if each service takes one second, then the client It takes 3 seconds. For users, 3 seconds is obviously intolerable, so how should we solve it? We can use an asynchronous method to solve this problem. See the flow chart below:

In this way, the points service and SMS service operate asynchronously using threads. , then the client only needs 1 second to complete. However, this asynchronous approach will bring another problem: reduced concurrency. Because both the points service and the SMS service need to open threads in the order service, opening more threads will cause the client to access the order service concurrently, which may cause the actual time for the client to submit an order to exceed 1 second. So how to solve the problems caused by asynchronous? That is to use the message queue, look at the flow chart below:

#In the above process, we have added the role of a message queue. First, the client submits the order, and then Write the order to the message queue, and the points service and SMS service consume the messages in the message queue at the same time. This method does not require the order service to open an additional asynchronous thread, and the client can achieve a real time consumption of 1 second.

1.2. Application decoupling

Let’s take the e-commerce system as an example to explain. First, look at the flow chart below:

Business logic in the picture above: The client initiates a request to create an order. When creating an order, we must first obtain the inventory and then deduct the inventory. This forms a very close dependence between the order system and the inventory system. If the inventory system goes down at this time, because the order system depends on the inventory system, the order system will not be available at this time. So how to solve it?

Look at the flow chart of using the message queue below:

In the above process, we added the message queue. First, the client initiates a request to create an order, and the order message is written into the message queue. Then the inventory system subscribes to the message in the message queue, and finally updates the inventory system asynchronously. If the inventory system goes down, since the order system does not directly depend on the inventory system, the order system can respond to client requests normally. This achieves application decoupling.

1.3. Traffic Peak Shaving

For high-concurrency systems, during peak access times, sudden traffic flows like a flood to the application system, especially some high-concurrency write operations. , which will cause the database server to be paralyzed at any time and unable to continue to provide services.

The introduction of message queues can reduce the impact of burst traffic on application systems. The consumption queue is like a "reservoir" that intercepts floods in the upstream and reduces the peak flow into the downstream river, thereby achieving the purpose of reducing flood disasters.

The most common example in this regard is the flash sale system. Generally, the instantaneous traffic of flash sale activities is very high. If all the traffic flows to the flash sale system, it will overwhelm the flash sale system. By introducing message queues, burst traffic can be effectively buffered to achieve " Peak clipping" effect.

We use the flash sale scenario to describe traffic peak cutting. Let’s first look at the following flow chart:

In the above process, we use the flash sale service It is called upstream service, and order service, inventory service and balance service are collectively called downstream service. The client initiates a flash sale request. After receiving the request from the client, the flash sale service creates an order, modifies the inventory, and deducts the balance. This is the basic business scenario of the flash sale.

Suppose the downstream service can only handle 1,000 concurrent requests at the same time, the upstream service can handle 10,000 concurrent requests, and the client initiates 10,000 requests, which exceeds the amount of concurrency that the downstream service can handle, so it will cause the downstream The service is down. At this time, you can join the message queue to solve the downtime problem. Look at the flow chart of joining the message queue below:

We have added the message queue to the above flow chart to describe how the service will process the 10,000 requests sent by the client after it receives them. All requests are written to the message queue, and then the downstream service subscribes to the flash sale request in the message queue, and then performs its own business logic operations.

Let's take a simple example. The upstream service can still handle 10,000 concurrent requests, and the downstream service can still only handle 1,000 concurrent requests. At this time, we will allow 1,000 concurrent requests to be stored in the message queue. The upstream flash sale service received 10,000 concurrent requests, but the message queue can only store 1,000 requests. The excess requests will not be stored in the message queue, and will be directly returned to the client with the prompt "The system is busy, please wait!" . This is the so-called traffic peak clipping scenario. This is determined by the amount of concurrency that the downstream service can handle. Since the downstream service can only handle 1,000 concurrent requests, only 1,000 flash sales can be stored in the message queue, and all excess flash sales requests will be returned to the client prompt. This ensures the normal response of downstream services, does not cause downtime of downstream services, and improves system availability.

2. Log scenario

Optimize log transmission

In order to make the program robust, we generally add various logging functions to the program, such as error logs, operations Logs, etc., look at the flow chart below:

The above flow chart is the process of synchronously recording logs. Using the process of synchronous logging will increase the time spent on the entire process, and will also easily cause business system downtime (if the database is damaged, the operation of recording logs to the database will cause an error). We can use message queues to optimize log transmission. Look at the flow chart below:

After joining the message queue, the time spent on the system can be shortened, and the function of application system decoupling can also be achieved.

3. Instant communication scenario

Chat room

The main function of the message queue is to send and receive messages. It has an efficient communication mechanism inside, so it is very suitable for message communication.

We can develop a point-to-point chat system based on message queues, or we can develop a broadcast system to broadcast messages to a large number of recipients.

The above is the detailed content of What are the application scenarios of java message queue?. For more information, please follow other related articles on the PHP Chinese website!