Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to use RabbitMQ. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Asynchronous processing

Scenario: send mobile verification code, email

The traditional and ancient processing methods are as follows

This process, all completed in the main thread, registration-"storage -" send e-mail-"send text messages, because they are all in the main thread, so you have to wait for each step to complete before continuing to execute. Because the operation time and response time of each step is not fixed, the request time of the main thread may be very long. If there are too many requests, it will lead to IIS site slowness, queuing requests, or even downtime, seriously affecting the user experience.

Now most of the processing methods are as follows

The process is that the main thread still handles the low-time incoming operations, and then writes the messages that need to be processed into the message queue, which is negligible and very fast, and then, an independent e-mail subsystem, and an independent SMS subsystem, at the same time subscribe to the message queue for separate processing. After it is processed, an ACK confirmation is sent to the queue, and the entire data of the message queue is deleted. This process is also the way that all major companies are using, using SOA to service each system, giving time-consuming operations to independent business systems separately, and using message queues as middleware to achieve the purpose of application decoupling, and the consumption of resources is very low, a single server can withstand greater concurrent requests.

Application decoupling

Taking the order placed by e-commerce as an example, assume that the intermediate process is to place an order = "reduce inventory =" delivery.

The first way, through continuous operation table, in a single system, through the main thread, continuous operation. Ha, this practice, I believe that many people have just started, or even a few years of experience, because the project is small, but also continue to use it. If the number of users is small, or they are all used by insiders, there will be no problem, because they will not care about the problems. in this way, as long as there is a problem in one link, the request will report an error directly, resulting in the confusion of the user. assuming that an error is reported in the inventory reduction operation, and if the whole process is not rolled back with transactions, it will also cause data inconsistency.

In the second way, the three services are divided into three independent systems, and the requests are called each other through JSON. This practice, in fact, is already very good, at least independent, do their own things, to a certain extent, reduce the coupling of the whole system. But the problem is, even if the request is in the form of API, the system that sends the request will usually wait for the requested party to respond. If the response is wrong, the whole program will still be terminated. If the previous business system has already done the storage operation, it must be mixed up. It's troublesome. If we do not wait for the requested party to respond, if there is an error, and if we want to ensure data consistency, we need to do more to complete the data, for example, successful order placement, inventory reduction failure, and successful delivery, so that when the inventory reduction system is repaired, it is necessary to supplement the corresponding data of the inventory table through the order data. It is difficult to deal with the trouble first.

The third way

Using the message queue as the middleware, when the order system places the order, the data message is written into the message queue, and the inventory system and the shipping system subscribe to the message queue at the same time, which is similar to the pure API system call. However, the powerful function of the message queue RabbitMq itself will help us to do a lot of error remediation, or, assuming that the order is placed successfully, the inventory fails, and the shipment is successful, when we repair the inventory. There is no need to manage any data inconsistencies, because messages that are not processed in the inventory queue are sent directly to the inventory system, which will be processed by the inventory system. The large decoupling of the application is realized.

Flow peaking

This is mainly used in group buying, flash sale activity.

The main principle is to control the queue length, when the request comes, writes to the queue, exceeds the length of the queue, returns a failure, reports a lovely error page to the user, and so on.

Log processing

This scenario should be very familiar, a system has a large number of business needs a variety of logs to ensure the follow-up analysis work, and the real-time requirements are not high, it is better to use queue processing.

Message communication

Among the major social communication projects launched now, message queues are not actually used for instant messaging, but it can be used to do it, so those who are interested might as well give it a try.

This is peer-to-peer communication. Consumers An and B can realize peer-to-peer communication by subscribing to message queues and being manufacturers at the same time.

In the practice of group chat, all clients subscribe to the queue at the same time, and are also sent and made at the same time.

Difference

The above five approximate RabbitMq application scenarios, let's introduce the differences of several message queues

ActiveMq: this is widely used in JAVA middleware.

ZeroMq: this is the queue with the most efficient distribution, more than ten times that of other queues. The disadvantage is that the data cannot be persisted.

Kafka: this is a high-throughput publish / subscribe messaging system. You can use this when you reach the distribution requirement of 10W + per second, which is what Sina Weibo uses for distribution.

Is there a limit on the number of message stored in a queue on RabbitMQ?

It can be considered unlimited because the limit depends on the memory of the machine, but too many messages can lead to a decline in processing efficiency.

Are channel, exchange, and queue in RabbitMQ concepts logical concepts, or do they correspond to process entities? What are the functions of these things?

Queue has its own erlang process; exchange is implemented internally as a lookup table that holds binding relationships; and channel is the entity that actually carries out routing work, that is, it is responsible for delivering message to queue according to routing_key. According to the description of the AMQP protocol, channel is a virtual connection over a real TCP connection, all AMQP commands are sent through channel, and each channel has a unique ID. A channel can only be used by a single operating system thread, so the message delivered to a particular channel is sequential. However, multiple channel are allowed on one operating system thread. The channel with channel number 0 is used to process all frames that are globally valid for the current connection, while channel numbers 1-65535 are used to process frames associated with a particular channel. The channel reuse model given by AMQP protocol is as follows

Each of these channel runs on a separate thread, and multiple threads share the same socket.

This is the end of the article on "how to use RabbitMQ". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.