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

Background confirmCallback confirmation mode returnCallback not delivered to queue return mode shovel-plugin reliable delivery background across computer rooms

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.

ConfirmCallback confirmation mode

Set the PublisherConfirms (true) option when creating the connectionFactory and turn on confirmcallback.

CachingConnectionFactory factory = new CachingConnectionFactory (); factory.setPublisherConfirms (true); / / enable confirm mode RabbitTemplate rabbitTemplate = new RabbitTemplate (factory); rabbitTemplate.setConfirmCallback ((data, ack, cause)-> {if (! ack) {log.error ("message failed!" + cause + data.toString ());} else {log.info ("message sent successfully, message ID:" + (data! = null? Data.getId (): null);}})

Let's take a look at the ConfirmCallback interface.

Public interface ConfirmCallback {/ * * Confirmation callback. * @ param correlationData correlation data for the callback. * @ param ack true for ack, false for nack * @ param cause An optional cause, for nack, when available, otherwise null. * / void confirm (CorrelationData correlationData, boolean ack, String cause);}

The point is the CorrelationData object, each message sent needs to be equipped with a CorrelationData-related data object, and there is only one id property inside the CorrelationData object to indicate the uniqueness of the current message.

Create a CorrelationData object when it is sent.

User user = new User (); user.setID (1010101L); user.setUserName ("plen"); rabbitTemplate.convertAndSend (exchange, routing, user, message-> {message.getMessageProperties (). SetDeliveryMode (MessageDeliveryMode.NON_PERSISTENT); return message;}, new CorrelationData (user.getID (). ToString ()

Here user ID is set to the current message CorrelationData id. Of course, this is a pure demo. In the real scenario, you need to generate a business-independent message ID and record this id for error correction and reconciliation.

ConfirmCallback will be executed as soon as the message is received by rabbitmq broker, and if it is in cluster mode, confirmCallback will not be called until all broker receives it.

Being received by broker can only indicate that the message has arrived at the server, and there is no guarantee that the message will be delivered to the target queue. So you need to use the next returnCallback.

ReturnCallback not delivered to queue return mode

The confrim mode can only guarantee that the message reaches the broker, not that the message is accurately delivered to the target queue. In some business scenarios, we need to ensure that the message must be delivered to the target queue, and we need to use the return return mode.

Similarly, when you create a ConnectionFactory, you need to set the PublisherReturns (true) option.

CachingConnectionFactory factory = new CachingConnectionFactory (); factory.setPublisherReturns (true); / / enable return mode rabbitTemplate.setMandatory (true); / / enable mandatory delegation mode rabbitTemplate.setReturnCallback ((message, replyCode, replyText, exchange, routingKey)-> log.info (MessageFormat.format ("messaging ReturnCallback: {0}, {1}, {2}, {3}, {4}, {5}", message, replyCode, replyText, exchange, routingKey)

In this way, if it is not delivered to the target queue, returnCallback will be called, and detailed data can be recorded to the delivery data, which are needed for regular inspection or automatic error correction.

Reliable delivery of shovel-plugin across computer rooms

RabbitMQ provides a good plug-in shovel in cross-room integration. It is very convenient to use the shovel-plugin plug-in. Shovel can accept unstable factors such as network disconnection between computer rooms, machine offline and so on.

Here are two broker:

10.211.55.3 rabbit_node1

10.211.55.4 rabbit_node2

We want to transfer the message sent to rabbit_node1 plen.queue to rabbit_node2 plen.queue. Let's first turn on the shovel-plugin__ of _ _ rabbit_node1.

First check whether shovel-plugin is installed in the current version of RabbitMQ, and if so, open it directly.

Rabbitmq-plugins listrabbitmq-plugins enable rabbitmq_shovelrabbitmq-plugins enable rabbitmq_shovel_management

Then you can see this setting option in the Admin panel, but how to set it will not be discussed here. The main thing is to configure amqp protocol address, amqp://user:password@server-name/my-vhost.

If there is no problem with the configuration, it should be a state that indicates that you have successfully connected to _ _ rabbit_node2 broker__.

Let's take a look at the Connections panel of rabbit_node1 and rabbit_node2.

_ _ rabbit_node1 (10.211.55.3): _ _

_ _ rabbit_node2 (10.211.55.4): _ _

The RabbitMQ shovel-plugin plug-in creates two tcp connections in rabbit_node1 broker, port 39544 connections are used to consume messages in plen.queue, and port 55706 connections are used to push messages to rabbit_node2.

Let's take a look at the _ _ rabbit_node1 tcp__ connection status:

Tcp6 0 0 10.211.55.3:5672 10.211.55.3:39544 ESTABLISHEDtcp 0 0 10.211.55.3:55706 10.211.55.4:5672 ESTABLISHED

_ _ rabbit_node2 tcp__ connection status:

Tcp6 0 0 10.211.55.4:5672 10.211.55.3:55706 ESTABLISHED

In order to verify the stability of shovel-plugin, we take _ _ rabbit_node2__ offline.

Then send the message and find that the message will stay in the rabbit_node1 plen.queue now. Once the shovel-plugin connection is restored, the rabbit_node1 plen.queue message will be consumed and delivered to _ _ rabbit_node2 plen.queue__.

Author: Wang Qingpei (Senior JAVA architect, Hujiang Group)

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.