Shulou(Shulou.com)05/31 Report--

Editor to share with you how to standardize the use of RabbitMQ, I hope you will learn something after reading this article, let's discuss it together!

In the use of RabbitMQ, in order to avoid fewer problems in the development, in order to get twice the result with half the effort, it is necessary to standardize some configurations and matters in advance.

1. Set up multiple vhost in a RabbitMQ application to correspond to different development projects

When we use a database, we will set up several different databases in one database application for different projects, instead of installing a database application for each project on a different server.

At RabbitMQ's vhost, it's a similar idea.

Vhost is essentially a mini version of RabbitMQ server with its own queues, bindings, switches, and permission controls. When creating a user in RabbitMQ, the user is usually assigned to at least one vhost and can only access queues, switches and bindings within the assigned vhost. The vhost is absolutely isolated.

Therefore, different vhost correspond to different projects and do not affect each other, and these vhost are actually on one host and one RabbitMQ application.

However, the current situation is that most technical teams that use RabbitMQ tend to use the default vhost: "/", and if there is one more project, create a RabbitMQ process. Doing so is a waste of development resources.

It is recommended that a project corresponds to a vhost.

two。 Do not use RabbitMQ's own client directly

Many companies use RabbitMQ directly using RabbitMQ's own java version of the client, but because of the inherent complexity and diversity of RabbitMQ itself, there are many technical details that need to be dealt with alone.

For example, the handling of network connections, such as exception handling, such as message failure handling and so on. These, if you do not have a mature framework on hand, then it is likely that some details are not handled in place, resulting in a lot of problems, which are unnecessary costs.

Therefore, you can either use an existing RabbitMQ client framework (such as Spring's RabbitMQ framework) or package an underlying RabbitMQ client framework instead of using RabbitMQ clients alone

3. In any case, consumers must give back an ACK response.

The ACK mechanism is that consumers receive a message from RabbitMQ and process it, then feedback it to RabbitMQ, and then RabbitMQ receives the feedback before removing the message from the queue.

Because the ACK mechanism itself must reply to RabbitMQ, the message will discard this feature. As for when to give ACK, when we do development, we must plan and design in advance before the development project.

When we use RabbitMQ, we usually don't want to give it back to ACK as soon as we receive a message, nor do we set up the autoACK mechanism, that is, the consumer receives an automatic ACK response. Generally speaking, we will manually return ACK in different locations depending on the business logic.

At this time, problems may arise: when a message is received, sometimes the processing business logic reports an error, and the ACK is often ignored after processing the business logic, which will cause the message to be stuck in the queue all the time. If the quantity is more and more, the follow-up processing is very troublesome.

4. Consider setting up dead letter exchanges

Why don't so many people set up dead letter exchanges? This is what I am very confused about.

I went out to communicate with all kinds of project teams using RabbitMQ and found that very few people set up dead letter exchanges. There is a problem with this.

We have to know that sometimes message delivery errors, there are not always problems in the application reception, there will be a lot of non-application problems. For example:

There was a problem on the consumer side and the message was rejected. And we also set up requeue=false.

The message may be deleted because the ACK timeout has not been received, or the consumption speed of the consumer side can not keep up with the timeout.

The number of messages exceeds the maximum queue length limit and is discarded.

The total message size exceeds the queue message size limit and is discarded.

Setting dead letter exchanges is a solution to these problems.

Once the message appears in the situation I listed above, it will be sent to the dead letter exchanges we set up. Then we can deal with the messages of these special cases separately, which can make our project more robust and easier to track problems.

5. Use Direct Exchange as much as possible

The Exchange of RabbitMQ is the message switch, which specifies the rules by which messages are routed to which queue.

There are four types of this guy:

Direct: to handle routing keys, you need to bind a queue to the switch and require that the message exactly match a specific routing key. This is a complete match. If a queue is bound to the switch and requires the routing key to be "green", only messages with the routing key "green" will be forwarded, the routing key will not be forwarded with "red", and only the routing key with "green" will be forwarded.

Topic: matches the routing key to a pattern. At this point the queue needs to be bound to a mode. The symbol "#" matches one or more words, and the symbol "*" can match only one word.

Fanout: routing keys are not processed. You just need to simply bind the queue to the switch. A message sent to this type of switch is broadcast to all queues bound to that switch.

Headers: the routing key is not processed, but is matched based on the headers attribute in the content of the message sent. Specify a set of key-value pairs when binding Queue and Exchange; when a message is sent to RabbitMQ, the headers of the message is matched with the key-value pair specified when Exchange is bound; if there is an exact match, the message is routed to the queue, otherwise it will not be routed to the queue.

Of the four types, Exchange delivery messages of Direct type are the fastest. Other Exchange,MQ also takes time to calculate the location of the delivery.

Therefore, it is recommended to use Direct if you can use the Direct type.

After reading this article, I believe you have a certain understanding of "how to standardize the use of RabbitMQ". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading!

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.