RABBITMQ Application One supplement (RABBITMQ application scenario)

Go straight to the chase.

I. Asynchronous processing

Scenario: Send phone verification code, mail

Traditional ancient processing methods such as

This process, all in the main thread to complete, registration-"warehousing-" Send mail-"Send text messages, because all in the main thread, so to wait for each step to complete to continue to execute. Because the operation time response time of each step is not fixed, the request of the main thread can be very long, and if too many requests, it can cause the IIS site to slow down, queue up requests, or even go down, which seriously affects the user experience.

Now most of the processing methods are as follows

This practice is the main thread only take a very short time-consuming warehousing operations, send mail and send text messages, will open 2 asynchronous threads, throw in parallel execution, the main thread regardless, continue to perform subsequent operations, this processing way is far better than the first processing, greatly enhanced the response speed of the request, the user experience is good. The disadvantage is that because the asynchronous line thread operation is a time-consuming operation, a request to open 2 threads, and a standard configuration of the ECS server supporting the number of concurrent threads around 800, assuming that a thread in 10 seconds to complete, the single server can support up to 400 requests for concurrency, followed by queuing. This situation, it is necessary to consider increasing the server load, embarrassing increase in costs.

How Message Queuing RABBITMQ is handled

The process is that the main thread still handles the time-consuming warehousing operations, and then writes the messages that need to be processed into the message queue, which is time-consuming, negligible, very fast, and then, independent of the outgoing mail subsystem, and independent of the texting subsystem, subscribing to the message queue for separate processing. After processing, an ACK acknowledgement is sent to the queue, and the entire data is deleted from the message queue. This process is now used by major companies in a way to service the various systems of SOA, the time-consuming operation, separate to the independent business system, through the message queue as a middleware, to achieve the purpose of application decoupling, and the consumption of low resources, a single server can withstand greater concurrent requests.

Two. Application decoupling

Take the e-commerce order as an example, assuming that the intermediate process is to place orders = "Reduce inventory =" issue

The first way, through the continuous Operation table, in a single system, through the main thread, continuous operation. Hehe, this practice, I believe many people have just started, even years of experience, because the project is small, also continue to use it. Less users, or are internal people use, there is no problem, because will not care about the problem, this practice, as long as a link problems, request direct error, resulting in user Meng, assume that in the implementation to reduce inventory operation error, the entire process is not used transaction rollback, but also result in inconsistent data.

The second way, the three business, split into three separate systems, through the JSON method calls each other request. This practice, in fact, has been very good, at least independent out, each to do their own things, to a certain extent, reduce the coupling of the entire system. However, the problem is, even if the request through the API, the system will normally wait for the requested party response, if the response is wrong, the entire program will be terminated, the front of the business system if you have already done the storage operation, it must be mixed. Very troublesome. If the response is not waiting for the requested party, if the error, if you want to ensure data consistency, it is necessary to do more to complete the data, for example, the success of the order, reduce inventory failure, delivery success, so that when the reduction of inventory system repair, it will be through the order data, to fill the inventory table corresponding data. First, trouble, difficult to deal with.

The Third Way,

The message queue as a middleware, when the order system after the completion of orders, the data messages written to the message queue, inventory system and shipping system simultaneously subscribe to the message queue, thinking and pure API system calls similar, but the message queue RABBITMQ itself powerful function, will help us do a lot of error after processing, or, Assuming that the order succeeds, the inventory fails, the delivery succeeds, and when we repair the inventory, there is no inconsistency of the tube data, because the inventory queue is not processed and the message is sent directly to the inventory system, which is processed by the inventory system. It realizes the large-scale decoupling of the application.

Three. Peak Flow shaving

This is mainly used in the group purchase, the second kill activity

The main principle is to control the queue length, when the request comes, write to the queue, more than the length of the queue, it will return to failure, to the user to report a lovely error page and so on.

Four. Log processing

This scenario should be familiar, a system has a large number of business needs a variety of logs to ensure the subsequent analysis work, and the real-time requirements are not high, with the queue to deal with the better

Five. Message communication

Now in the major social communication projects on-line, actually does not use the message queue to do instant communication, but it can be used to do, interested may wish to try it

This is point-to-point communication, where consumers A and B subscribe to Message Queuing and are also manufacturers to achieve point-to-point communication

The practice of group chat, where all clients subscribe to the queue at the same time, are also sent, the manufacturer.

--------------------------------------------------------------------------------------------------------------- ----------------------------------------------

The above 5 types of RABBITMQ scenarios are described below to describe the differences between several message queues

ACTIVEMQ: This application is more in Java middleware

ZeroMq: This is the most efficient distribution queue, more than 10 times times the other queues, the disadvantage is that data persistence is not possible.

Kafka: This is a high-throughput publish-Subscribe messaging system that can be used to distribute the 10w+ when it meets the distribution requirements for the second time.

First write so much, the general application scenario, welcome to the big God to add, I am also the company needs, learning to sort out, there may be understanding deviation, forgive ha!

RABBITMQ Application One supplement (RABBITMQ application scenario)