Which Delayed Task Strategy Wins? A Deep Dive into DB Polling, DelayQueue, Time Wheel, Redis, and RabbitMQ

Background

In many systems a delayed task is needed, e.g., automatically cancel an unpaid order after 30 minutes or send an SMS 60 seconds after order creation. Unlike a scheduled task, a delayed task has no fixed trigger time, does not repeat, and usually processes a single item.

Solution Overview

1. Database Polling (Quartz)

Idea A single thread periodically scans the order table and updates or deletes rows whose timeout has passed. Suitable for small projects.

Implementation Add Quartz to the Maven project (org.quartz-scheduler:quartz:2.2.2) and create a job that prints "Scanning database…" every 3 seconds.

Pros

Simple to set up.

Supports clustering.

Cons

High memory consumption.

Latency up to the scan interval.

Heavy DB load with millions of rows.

2. JDK DelayQueue

Idea Use java.util.concurrent.DelayQueue, an unbounded blocking queue that releases elements only after their delay expires. Elements must implement java.util.concurrent.Delayed.

Implementation Define an OrderDelay class implementing Delayed (stores orderId and expiration time). A demo adds five orders with a 3‑second delay and consumes them with take(), printing the order ID and elapsed time.

Pros

High efficiency, low trigger latency.

Cons

Data lost on server restart.

Cluster scaling is difficult.

Potential OOM when many pending tasks.

Higher code complexity.

3. Time Wheel (Netty HashedWheelTimer )

Idea Netty provides a timing‑wheel implementation. A wheel rotates at a fixed tick; tasks scheduled for the current slot are executed.

Implementation Add Netty (io.netty:netty-all:4.1.24.Final). Create a MyTimerTask that prints "Deleting order from DB…" and schedule it with timer.newTimeout(task, 5, TimeUnit.SECONDS).

Pros

High efficiency, lower latency than DelayQueue, simpler code.

Cons

Data lost on restart.

Cluster scaling is hard.

OOM risk with many pending tasks.

4. Redis Sorted Set (ZSET)

Idea Store each order ID as a member and its expiration timestamp as the score in a Redis ZSET. Periodically query the smallest score to find expired orders.

Implementation Use Jedis. ZADD key score member adds an order, ZRANGE key 0 0 WITHSCORES fetches the earliest entry, and ZREM key member removes processed orders. The demo creates five orders with a 3‑second delay and consumes them.

Pros

High accuracy.

Easy horizontal scaling.

Persistence guarantees reliability after crashes.

Cons

Requires Redis deployment and maintenance.

Concurrency handling In high‑concurrency scenarios, use the return value of ZREM to ensure only one consumer removes a given order:

Long removed = jedis.zrem("OrderId", orderId);
if (removed != null && removed > 0) {
    // process order
}

5. Message Queue (RabbitMQ)

Idea RabbitMQ supports per‑message TTL ( x-message-ttl) and dead‑letter exchanges. By setting a TTL on a message, it is moved to a dead‑letter queue after the delay, where a consumer can process it.

Pros

Efficient and leverages RabbitMQ’s distributed nature.

Persistent messages increase reliability.

Cons

Operational overhead of running RabbitMQ adds complexity and cost.