How to Build a Delayed Queue with Java and Redis for High‑Concurrency Scenarios

Idea 1: Sorted Queue (DelayQueue‑style)

Principle: Keep a time‑ordered queue. Each put inserts an element in sorted order by its expiration timestamp. When take is called, the head element’s timestamp is examined; if it has expired, the element is returned, otherwise the calling thread blocks for the remaining time. This follows the behavior of JDK DelayQueue. The author consulted the JDK source for implementation details but did not provide full code.

Idea 2: Redis + Scheduler

Principle: Use a Redis sorted set (ZSET) where the score is the expiration time rounded to seconds (milliseconds removed). A Spring @Scheduled task runs every second, queries Redis with ZRANGEBYSCORE using the current time as the upper bound, and processes all due items. This leverages Redis’s distributed nature and fine‑grained timing.

Business scenario: Simulate a peak load of 5 million orders per day over an 8‑hour window (≈173 orders per second). The author used this rate to test the designs.

Redis implementation details:

Producer: a Spring @Scheduled method generates ~170 orders each second. Each order is added to a Redis ZSET with a score of currentTime + 60 seconds. The helper method removeMillis() strips milliseconds from the timestamp before calling ZADD.

Consumer: another Spring @Scheduled method runs every second, uses the current timestamp as the upper bound, and retrieves due orders via ZRANGEBYSCORE.

Testing showed no lost orders, but the author notes many optimization opportunities and potential real‑world issues (e.g., handling bursts, network latency). They argue that JDK DelayQueue is less suitable for distributed scenarios because it processes one element at a time and is single‑node, whereas Redis can handle higher concurrency. Future exploration may include Kafka or RabbitMQ delayed queues.