Choosing the Right Delayed‑Task Solution: Why Redis Expiration and RabbitMQ Dead‑Letter Queues Are Problematic

Recently I read a post warning against using scheduled tasks to close orders and highlighted several flaws in common implementations.

Typical ways to achieve delayed execution include:

Using the delayed delivery feature of message queues such as rocketmq , rabbitmq , pulsar .

Using Redisson's DelayedQueue .

Some widely spread solutions have fatal drawbacks and should be avoided:

Redis expiration listener.

RabbitMQ dead‑letter queue.

Non‑persistent time wheel.

Redis Expiration Listener

The Redis official manual ( keyspace-notifications → timing-of-expired-events ) states that expired events are generated when the server deletes the key, not when the TTL reaches zero.

Basically expired events are generated when the Redis server deletes the key and not when the time to live theoretically reaches the value of zero

Redis removes expired keys via periodic offline scans and lazy checks on access; it does not guarantee immediate deletion or timely notifications, and notifications can be delayed by minutes. The key‑space notification uses a fire‑and‑forget strategy, so clients may miss events during disconnections. This approach is considered a low‑reliability solution and should not be used.

RabbitMQ Dead Letter

Dead letters ( Dead Letter ) in RabbitMQ occur when a message is negatively acknowledged with channel.basicNack and requeue=false , exceeds its TTL, or the queue length surpasses its maximum. When a dead‑letter exchange is configured, such messages are routed to a dead‑letter queue.

Creating a dead‑letter queue involves:

Creating an exchange to act as the dead‑letter exchange.

Configuring the business queue with x-dead-letter-exchange and x-dead-letter-routing-key pointing to the dead‑letter exchange.

Creating a queue bound to the dead‑letter exchange and listening to it.

RabbitMQ does not guarantee delivery timing for dead letters; the first dead letter may delay subsequent ones. To achieve reliable delayed delivery, RabbitMQ provides the official plugin rabbitmq-delayed-message-exchange , which is recommended.

Time Wheel

A time wheel is an efficient data structure for scheduling tasks, but most implementations are in‑memory only. If the process crashes, all scheduled tasks are lost, making it a risky choice without additional persistence mechanisms.

Redisson DelayQueue

The redisson delayqueue is built on a Redis zset . Each element’s score stores the delivery timestamp. The queue periodically runs zrangebyscore to move due messages to a ready list.

As long as Redis does not crash, the delay queue will not lose messages, making it a viable fallback when professional message queues are unavailable. However, a compensation mechanism should be designed to handle Redis failures, and scanning the database for unfinished orders can be combined to reduce load.

Conclusion

Prefer message queues with built‑in delayed delivery such as rocketmq or pulsar .

If a professional queue is not feasible, consider redisson delayqueue but add protection for Redis crashes.

When neither is suitable, a time wheel can be used, but ensure frequent persistence or database‑scan safeguards.

Never use Redis expiration listeners for delayed tasks.

References:

https://juejin.cn/post/6987233263660040206

https://juejin.cn/post/6844904158227595271