ActiveMQ message middleware application scenarios

0a74a3ed983d41709fa68348056ec5cc.gif1. Introduction to ActiveMQ

 

  ActiveMQ is the most popular and powerful open source message bus produced by Apache. ActiveMQ is a JMS Provider implementation that fully supports JMS1.1 and J2EE1.4 specifications. Although the JMS specification has been published for a long time, JMS still plays a special role in today's J2EE applications.

 

2. ActiveMQ application scenario

  Message queues have in-depth applications on large e-commerce websites, such as Jingdong, Taobao, Qunar and other websites.

 

The main role of the queue: to eliminate high concurrent access peaks and speed up the response speed of the website.

 

In the case of not using the message queue, the user's request data is directly written into the database. In the case of high concurrency, it will put a huge pressure on the database and also increase the delay of the system response;

 

After using the queue early, the user's request is sent to the queue and returned immediately;

 

For example: Of course, it is not possible to directly remind the customer that the order has been submitted successfully. On Taobao, it will prompt: "You have submitted the order, please wait for the system to confirm."

 

Then the consumer process of the message queue obtains the database from the message queue and writes it into the database asynchronously.

 

Since the service processing speed of the message queue is much faster than that of the database, the user's response delay may be effectively improved.

 

Flow diagram, as shown below:

 

 

 

3. Message Queue Description

  The middle of the message queue is an important component in the distributed system, which mainly solves problems such as application coupling, asynchronous messages, and traffic peak shaving;

 

Realize high performance, high availability, scalability and eventual consistency architecture; it is an indispensable middleware for large-scale distributed systems.

 

Currently, many message queues are used in the production environment: ActiveMQ, RabbitMQ, Kafka, ZeroMQ, MetaMQ, RocketMQ, etc.

 

4. Message queue application scenarios

1. Asynchronous processing

Scenario description: After the user registers, he needs to send a registration email and a registration SMS. There are two traditional methods: serial and parallel;

 

(1) Serial mode: After the registration information is successfully written into the database, a registration email and a registration SMS will be generated. After the above three tasks are completed, return to the client.

 

 

 

(2) Parallel mode: After the registration information is successfully written into the database, a registration message will be generated at the same time as the registration email. After the above three tasks are completed, it will be returned to the client. The difference from the serial method is that the parallel method can improve the processing time;

 

 

 

Assuming that each of the three service nodes uses 50ms, regardless of other overheads such as the network, the time-consuming of the serial mode is 150ms; the time-consuming of the parallel mode is 100ms;

 

Because the number of requests processed by the CPU per unit time is certain, assuming that the throughput of the CPU within 1 second is 100; then the number of requests that the CPU can process within 1 second in the serial mode is 7 times (1000/150); the parallel mode can be The amount of processing requests is 10 times (1000/100);

 

To sum up, the performance (concurrency, throughput, and response time) of the system in the traditional way will have bottlenecks. how to solve this problem?

 

The introduction of message queue will not be necessary business logic, asynchronous processing, the modified architecture is as follows:

 

 

 

After installing 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 50ms.

 

After registering emails, sending text messages and writing them into the message queue, they are directly put back, so the speed of writing to the message queue is very fast, which can basically be ignored.

 

After using the message queue, the user's response data may be 50ms. Therefore, based on this architecture, the throughput of the system is increased to 20QPS per second; it is 3 times higher than serial and 2 times higher than parallel.

 

2. Application decoupling

Scenario description: After the user places an order, the order system needs to notify the inventory system. Traditional approach: the order system calls the inventory system interface. As shown below:

 

 

 

Disadvantages of the traditional model:

 

  1>. If the inventory system cannot be accessed, the order will fail to reduce the inventory, resulting in the failure of the order;

 

  2>. 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:

 

 

 

  1>. Order system: After the user places an order, the order system completes the persistence process, writes the message into the message queue, and returns the user's order successfully placed, please wait for the logistics delivery.

 

  2>. Inventory system: Subscribe to the order information, and use the pull/push method to obtain order information, and the inventory system will perform inventory operations based on the order information.

 

  3>. If the inventory system cannot be used normally when the order is placed, it will not affect the normal order. Because after the order is placed, the order system writes to the message queue, which is no longer related to other follow-up operations, realizing the application decoupling of the order system and the inventory system.

 

3. Flow peak elimination

Traffic peak reduction is also a common scenario in message queues, and is generally used in seconds or group grabbing activities.

 

Application Scenario: Seconds activity, generally due to excessive traffic, resulting in a sudden increase in traffic, and the application is easy to hang up. To solve this problem, it is generally necessary to assume a message queue at the front end of the application.

 

(1) The number of people involved can be controlled.

 

(2) It can relieve the application of high traffic in a short period of time;

 

 

 

Introduce message queue:

 

  1>. The user's request, after the server receives it, writes it into the message queue first. If the length of the message queue exceeds the maximum number, the user request will be discarded directly or the error page will be redirected;

 

  2>.Seckill business performs follow-up processing according to the request information of the message queue;

 

4. News communication

 Message communication refers to: 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.

 

(1) Point-to-point communication

 

 

 

Client A and client B use the same queue for message communication.

 

(2) Chat room communication (publish and subscribe)

 

 

 

Client A, client B, and client N subscribe to the same topic, publish and receive messages, and achieve the effect of a chat room.

おすすめ

転載: blog.csdn.net/weixin_57763462/article/details/131628953