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

How to carry out reliable delivery of RabbitMQ messages, in view of this problem, this article introduces the corresponding analysis and answers in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

Mq provides two ways to confirm the reliable delivery of messages.

ConfirmCallback confirmation mode

ReturnCallback not delivered to queue return mode

When using RabbitMQ, as the message sender, you want to put an end to any message loss or delivery failure scenarios. RabbitMQ provides us with two options to control the reliability mode of message delivery.

The entire message delivery path of rabbitmq is as follows:

Producer- > rabbitmq broker cluster- > exchange- > queue- > consumer

Message returns a confirmCallback from producer to rabbitmq broker cluster.

If message fails to deliver from exchange- > queue, a returnCallback will be returned. We will use these two callback to control the final consistency and partial error correction capabilities of the messages.

For message exceptions, you can use the following methods to resolve

Using the MessageRecoverer of RepublishMessageRecoverer sends a message to the specified queue

Bind a dead-letter queue to the queue because the default RepublishMessageRecoverer sends nack and the requeue is false. In this way, a game is thrown in the same way as the above result is forwarded to another queue. See DeadLetterConsumer for details

Register your own implementation of MessageRecoverer

Set RecoveryCallback for MessageListenerContainer

Manually catch an exception for the method and handle it

The sending process of rabbitTemplate is as follows:

1 send data and return (do not confirm that the rabbitmq server has received it successfully)

2 receive the ack confirmation message returned from rabbitmq asynchronously

3 call the confirmCallback function after receiving the ack

Note: there is no original message in confirmCallback, so you cannot call resend in this function. ConfirmCallback only serves as a notification.

The safest thing to do is to use transactions, but this will be inefficient, with about a few hundred message per second. It is very undesirable for high-performance mq.

Another solution is as follows: on the basis of rabbitTemplate asynchronous confirmation

1 caching sent message locally

2 delete the confirmed message locally through confirmCallback or the confirmed ack

3 scan the local message regularly. If it is not confirmed for a certain period of time, it will be resent.

There are some problems with this solution:

Imagine this scenario where the rabbitmq receives the message and the network goes down when sending the ack confirmation, causing the client not to receive the ack and resend the message. It is much easier to resend messages than to lose messages, and we can be idempotent on the server side.

This is the answer to the question on how to deliver RabbitMQ messages reliably. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

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.