How to implement delayed tasks in RabbitMQ message queuing

This article mainly introduces the relevant knowledge of "how to achieve deferred tasks in RabbitMQ message queues". The editor shows you the operation process through an actual case. The operation method is simple, fast and practical. I hope this article "how to achieve deferred tasks in RabbitMQ message queues" can help you solve the problem.

I. Preface

Deferred tasks are widely used. Typical application scenarios for deferred tasks include automatic cancellation of order timeout and payment callback retry. Among them, the order timeout cancellation is idempotent, and there is no need to consider the problem of repeated consumption; the problem of repeated consumption needs to be considered in the retry of payment callback.

Deferred tasks have the following characteristics: they are executed at some point in the future; they are usually executed only once.

1. Realization principle

The producer sends the message with delay information to the RabbitMQ switch, waiting for the end of the delay time to forward the message to the bound queue, and the consumer consumes the message through the monitoring queue. The key to the delayed task is that the message stays in the switch.

Obviously, the implementation of deferred tasks based on RabbitMQ requires extremely high reliability of the server. There is no persistence mechanism for messages within the switch, such as the restart of stand-alone mode services, and all unstarted delayed tasks are lost.

2. Component selection

II. Scheme Design (1) Server

The RabbitMQ service requires the x-delayed-message plug-in to be installed to handle delayed messages.

(2) producers

The implementation of the deferred task requires the producer to deliver the message reliably to the switch, so the confirm confirmation mechanism can be used.

After the order is generated, it is first stored in the warehouse, and then the order details are stored in Redis (persistence) with the order ID as key, and an asynchronous confirm determination request is sent to RabbitMQ. If you receive a normal delivery return, delete the data in Redis where the order ID is key, and reclaim the memory. Otherwise, take the order ID as key, query the order data from Redis and resend it.

(3) consumers

The realization of the delayed task requires consumers to consume messages in a way that does not lose information, which is embodied in: manually confirming the consumption of messages to prevent message loss; consumers' continuous stability to prevent message accumulation; and message consumption failure has a retry mechanism.

Considering that the order delay cancellation is an idempotent operation, there is no need to consider the repeated consumption of messages.

Third, SpringBoot implementation

Only part of the core source code is posted in the implementation part. For the complete project, please visit GitHub.

(1) producers

Considering that placing an order is an extremely important operation, first put the order in stock, save it, and then do the follow-up operation.

For (long I = 1; I