RabbitMQ application scenarios
1.1 Asynchronous processing
Scenario description: After users register, they need to send registration emails and registration text messages. There are two traditional methods: 1. Serial method; 2. Parallel method
(1) Serial method: After writing the registration information into the database, send the registration Email, and then send the registration SMS, the above three tasks are all completed before returning to the client. The problem with this is that email and SMS are not necessary, it is just a notification, and this approach makes the client wait for something that is not necessary to wait
. At the same time, sending a short message, after the above three tasks are completed, return to the client, and the parallel method can improve the processing time. 
Assume that the three business nodes use 50ms respectively, the serial time is 150ms, and the parallel use time is 100ms. Although the processing time has been improved, as mentioned earlier, emails and text messages have no effect on my normal use of the website, and the client does not need to wait for the completion of the sending to display the registration success. Return.
(3) After the message queue is
introduced into the message queue, the business logic of sending emails and short messages is not required to be asynchronously processed 
. It can be seen that after the introduction of the message queue, the user's response time is equal to the time of writing to the database + writing the message Queue time (negligible), after the introduction of message queue post-processing, the response time is 3 times that of serial and 2 times that of parallel.
1.2 Application Decoupling
Scenario: Double 11 is a shopaholic festival. After the user places an order, the order system needs to notify the inventory system. The traditional method is that the order system calls the interface of the inventory system. 
This method has a disadvantage:
- When the inventory system fails, orders fail. (In this way, Jack Ma will earn a lot less money ^ ^)
Order system and inventory system are highly coupled.
Introduce message queueOrder system: After the user places an order, the order system completes the persistent processing, writes the message to the message queue, and returns that the user's order is successful.
- Inventory system: subscribe to the message of placing an order, obtain the message of placing an order, and perform library operations.
Even if the inventory system fails, the message queue can ensure the reliable delivery of messages without causing message loss (Jack Ma is happy now).
Traffic clipping
Traffic peak shaving is generally used in a wide range of
scenarios in seckill activities: In seckill activities, the application is usually hung up due to excessive traffic. To solve this problem, a message queue is generally added to the front end of the application.
Functions:
1. It can control the number of active people, and orders that exceed this certain threshold will be discarded directly (why have I never succeeded in a second kill ^^)
2. It can alleviate the short-term high-traffic overwhelming the application (the application can press its own maximum Processing ability to obtain orders)
1. After the server receives the user's request, it will first write to the message queue, and if the length of the added message queue exceeds the maximum value, the user's request will be discarded directly or the error page will be jumped.
2. The second-kill business will do follow-up processing according to the request information in the message queue.
This article comes from: https://blog.csdn.net/whoamiyang/article/details/54954780