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

This article introduces the knowledge of "how RabbitMQ determines whether messages are delivered to the queue". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Preface

When using RabbitMQ message middleware, because messages are delivered asynchronously, RabbitMQ deletes messages that cannot be routed by default. In order to find out whether the message has been successfully delivered to the queue, we need a corresponding processing mechanism. Today, let's verify the relevant verification mechanism.

two。 Message delivery failed

So what are the circumstances in which the message will fail? the RabbitMQ message will first arrive at the specified switch and then be routed by the switch to the corresponding queue. So the following situations can cause message delivery to fail.

The delivered switch is not available.

The delivered switch is available, but does not match the queue.

3. The handling mechanism of delivery failure

In response to the above two cases, RabbitMQ provides corresponding solutions.

ConfirmCallback

RabbitMQ provides the ConfirmCallback interface for acknowledgement callback after the message is sent to the RabbitMQ switch.

In Spring Boot, you need to enable:

Spring: rabbitmq: # usually choose correlated publisher-confirm-type:

There are usually three options:

NONE, which disables the release confirmation mode, is the default.

CORRELATED, the message will be published with a CorrelationData. When it is ack/nack, the CorrelationData will be returned for comparison processing. CorrelationData can contain rich meta-information for callback logic processing.

SIMPLE will wait for all messages to be released after being ack/nack. If it times out, it will trigger an exception or even close the connection channel.

Here I use the CORRELATED mode, declare a ConfirmCallback and set it to RabbitTemplate

RabbitTemplate.setConfirmCallback ((correlationData, ack, cause)-> {/ / correlationData may be empty if (ack) {log.debug ("message sent to exchange succeeded, id: {}", correlationData.getId ());} else {log.debug ("message to exchange failed, reason: {}", cause);}})

Logs are output when a message is delivered to a non-existent switch Exchange and ack=false:

-Publishing message [(Body:' "hello" 'MessageProperties [headers= {spring_listener_return_correlation=a088eb3f-a234-4e15-bb7a-3aa9a6f043e6, spring_returned_message_correlation=29975bc1-f363-4e3a-85ca-010d13888720, _ _ TypeId__=java.lang.String}, contentType=application/json, contentEncoding=UTF-8, contentLength=7, deliveryMode=PERSISTENT, priority=0, deliveryTag=0])] on exchange [DIRECT_EXCHANGE1], routingKey = [DIRECT_ROUTING_KEY2]-message to exchange failed, reason: channel error Protocol method: # method (reply-code=404, reply-text=NOT_FOUND-no exchange 'DIRECT_EXCHANGE1' in vhost' my_vhost', class-id=60, method-id=40)

The implementation here is relatively simple, you can add some messages to the switch after the failure of the operation processing logic.

ReturnCallback

The ReturnCallback interface is used to implement the callback when the message has been successfully sent to the RabbitMQ switch but does not match to the queue.

You need to enable it at the same time in Spring Boot:

Spring: rabbitmq: publisher-returns: true template: mandatory: true

The mandatory setting value in RabbitTemplate takes precedence.

We declare a ReturnCallback and set it to RabbitTemplate

RabbitTemplate.setMandatory (true); rabbitTemplate.setReturnCallback ((message, replyCode, replyText, exchange, routingKey)-> {String correlationId = message.getMessageProperties () .getHeader (PublisherCallbackChannel.RETURNED_MESSAGE_CORRELATION_KEY); log.debug ("message: {} failed to send, answer code: {} reason: {} switch: {} routing key: {}", correlationId, replyCode, replyText, exchange, routingKey);})

When the message is successfully delivered to the switch but cannot be matched to the queue:

-Publishing message [(Body:' "hello" 'MessageProperties [headers= {spring_listener_return_correlation=155648bd-fc3e-4c8b-a650-7b1ce720c7a6, spring_returned_message_correlation=7029ee49-357a-42fc-8532-dc41b4bb8e87, _ _ TypeId__=java.lang.String}, contentType=application/json, contentEncoding=UTF-8, contentLength=7, deliveryMode=PERSISTENT, priority=0, deliveryTag=0])] on exchange [DIRECT_EXCHANGE], routingKey = [DIRECT_ROUTING_KEY2]-message: 7029ee49-357a-42fc-8532-dc41b4bb8e87 sent failed Reason: NO_ROUTE switch: DIRECT_EXCHANGE routing key: DIRECT_ROUTING_KEY2-message sent to exchange successfully, id: 7029ee49-357a-42fc-8532-dc41b4bb8e87

We can also see from the above that ReturnCallback only handles failed delivery to the queue, unlike ConfirmCallback, which can handle both failed and successful cases.

That's all for "how RabbitMQ determines whether a message is delivered to the queue". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.