How to use the message retry mechanism to ensure the final delivery of printing instructions

question:

   The imprint cloud printing device terminal is relatively dependent on the network. As long as there is an abnormality, the pushed message cannot reach the device terminal in real time, resulting in the terminal not being able to receive the message in time, the service function not being completed, and the user experience will be degraded.

solution:

  Before explaining the solution, you need to understand several concepts of RabbitMQ.

  The TTL of the message and the dead letter exchange, through the combination of the two to achieve the retry requirement.

  TTL (Time To Live) of the message

  The TTL of a message is the time-to-live of the message. RabbitMQ can set TTL separately for queues and messages. The setting for the queue is the retention time of the queue without the connection of consumers, and it can also be set separately for each individual message. After this time, we consider the message dead, and call it a dead letter. If the queue is set and the message is set, it will be smaller. So if a message is routed to different queues, the time of death of the message may be different (different queue settings). Here we only talk about the TTL of a single message, because it is the key to realizing the delay task.

  The time can be set by setting the expiration field of the message or the x-message-ttl property, both of which have the same effect. It's just that the expiration field is a string parameter, so write a string of type int:

byte[] messageBodyBytes = "Hello, world!".getBytes();

AMQP.BasicProperties properties = new AMQP.BasicProperties();

properties.setExpiration("60000");

channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);

  When the above message is thrown into the queue, after 60 seconds, if it is not consumed, it dies. will not be consumed by consumers. After this message, there is no "dead" message pair that comes up and is consumed by consumers. The dead letter will not be deleted and released in the queue, it will be counted into the number of messages in the queue. Dead Letter alone can not achieve delay tasks, but also Dead Letter Exchange.

Dead Letter Exchanges

The concept of Exchage will not be repeated here, and can be understood from here. A message will enter the dead letter route if it meets the following conditions. Remember that this is a route, not a queue. A route can correspond to many queues.

1. A message was rejected by the Consumer, and the requeue parameter of the reject method is false. That is to say, it will not be placed in the queue again and used by other consumers.

2. The TTL of the above message has arrived, and the message has expired.

3. The length limit of the queue is full. Messages in the front of the queue are discarded or thrown on the dead letter route.

Dead Letter Exchange is actually an ordinary exchange, no different from creating other exchanges. It's just that a message expires in a queue where Dead Letter Exchange is set, it will automatically trigger the forwarding of the message and send it to Dead Letter Exchange.

The imprint cloud printing is to ensure the final arrival of the message through such ideas.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326351182&siteId=291194637