Why Choose Spring Boot + DelayQueue for a Custom Distributed Delayed-Task Queue?

1. Background and Requirement Analysis

In modern distributed systems, delayed‑task processing is a frequent and critical requirement. Typical use cases include order auto‑cancellation, automatic receipt confirmation, and delayed message push. Some scenarios, such as scheduled blog publishing, tolerate a few minutes of delay, but from an operational perspective timely execution may be essential for user experience.

2. Comparison of Common Implementation Schemes

2.1 Scan‑Based Approach Using Redis ZSet

Tasks are stored in a Redis ZSet with the execution timestamp as the score, and a scheduled job periodically scans the set.

Core implementation logic:

// Scan delayed tasks every minute
@Scheduled(cron = "0 * * * * *")
public void scheduleScan() {
    // Read expired tasks
    Set<String> taskIds = stringRedisTemplate.opsForZSet()
        .rangeByScore("task-key", 0, System.currentTimeMillis());
    if (CollUtil.isEmpty(taskIds)) {
        return;
    }
    taskIds.forEach(taskId -> {
        // Process delayed task
        ...
    });
    // Delete processed tasks
    ...
}

Advantages: Simple implementation, low technical threshold.

Disadvantages:

Timeliness cannot be guaranteed; delay depends on scan frequency.

Single‑node execution cannot fully utilize a distributed cluster.

Performance degrades when tasks accumulate.

2.2 Delay Feature of Message Queues

Major MQs such as RocketMQ and RabbitMQ provide built‑in delay queues. For Kafka, which lacks native delay support, a common workaround is to create multiple topics representing different delay intervals (e.g., topic_10s, topic_1m, topic_30m).

Implementation principle:

Producer sends messages to the topic matching the required delay.

Consumer polls messages, compares the message timestamp with the current time.

If the elapsed time reaches the configured delay, the task is processed; otherwise the consumer sleeps until the remaining time expires.

Core code examples:

@Configuration
public class KafkaDelayConfig {
    public static final long DELAY_30M = 30 * 60 * 1000L;

    @Bean
    public ConsumerFactory<String, String> consumerFactory() {
        Map<String, Object> props = new HashMap<>();
        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
        props.put(ConsumerConfig.GROUP_ID_CONFIG, "delay-30m-group");
        // Important: manual offset commit, do not commit before execution time
        props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);
        props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
        return new DefaultKafkaConsumerFactory<>(props);
    }
}

@Service
@Slf4j
public class Delay30mConsumer {
    @KafkaListener(topics = "topic_30m")
    public void consume30mDelay(ConsumerRecord<String, String> record, Acknowledgment ack) {
        try {
            String messageValue = record.value();
            DelayMessage message = parseMessage(messageValue);
            if (message == null) {
                ack.acknowledge();
                return;
            }
            long currentTime = System.currentTimeMillis();
            long elapsedTime = currentTime - message.getSendTime();
            if (elapsedTime >= KafkaDelayConfig.DELAY_30M) {
                // Execute task
                processExpiredMessage(message);
                ack.acknowledge();
                log.info("30‑minute delayed message processed: {}", message.getId());
            } else {
                // Not yet due, pause consumption
                TimeUnit.MICROSECONDS.sleep(KafkaDelayConfig.DELAY_30M - elapsedTime);
            }
        } catch (Exception e) {
            log.error("Exception while processing 30‑minute delayed message", e);
        }
    }
}

Suitable for fixed‑delay scenarios (e.g., order timeout handling) and ordered execution where earlier submissions expire first.

Limitations: cannot handle dynamically changing delays; the number of topics grows with delay granularity, increasing management complexity.

2.3 Redis Key‑Expiration Listener

Redis key expiration can trigger delayed tasks by setting the task ID as a key with an expiration time and listening to expiration events.

Implementation principle:

@Component
public class MyRedisKeyExpiredEventListener implements ApplicationListener<RedisKeyExpiredEvent> {
    @Override
    public void onApplicationEvent(RedisKeyExpiredEvent event) {
        byte[] body = event.getSource();
        System.out.println("Received delayed message: " + new String(body));
        // Execute delayed‑task logic here
    }
}

Timeliness cannot be guaranteed: Redis uses lazy + periodic deletion, so expiration may be delayed.

Cluster coordination issues: Expiration events are broadcast; multiple instances must deduplicate tasks.

Reliability risk: Pub/sub mode lacks persistence, leading to possible message loss.

3. Design of a Self‑Developed Distributed Delayed‑Task Component

Analysis of the above schemes reveals shortcomings in timeliness, distributed coordination, and dynamic‑delay support. To address these, we design a component based on Spring Boot + DelayQueue.

3.1 Core Design Goals

Distributed Coordination: Automatic node registration, heartbeat, health monitoring, and cluster node management.

Timely Trigger: Ensure tasks execute at the intended moment.

Dynamic Delay: Support mixed tasks with varying delay intervals.

Task Persistence: Prevent loss of tasks on restart or failure.

High Availability: No single point of failure, automatic failover.

3.2 Architecture Design

The component consists of the following core modules:

Coordinator Service: Node auto‑registration and discovery, heartbeat, health checks, cluster management.

TaskStorage: Persistent storage of delayed‑task data, status management, execution record tracking.

DelayTaskExecutor: Business‑logic callback interface, execution state management, exception handling, retry mechanism.

DistributedDelayQueue: Exposes a unified API, contains the scheduling core logic, and controls distributed coordination.

3.3 Technology Selection

Native Support: JDK DelayQueue is a priority queue based on a binary heap with O(log n) operations.

Timeliness Guarantee: Uses Condition wait/notify to precisely control execution time.

Flexibility: Supports mixed dynamic delays.

Challenges to solve:

Single‑Node Limitation: Overcome by the distributed coordinator for multi‑node collaboration.

Persistence Requirement: Combine external storage (e.g., database) to persist task data.

4. Summary and Outlook

This article systematically examined several distributed delayed‑task solutions, identified their strengths, weaknesses, and applicable scenarios, and presented a Spring Boot + DelayQueue based component that addresses timeliness, coordination, and dynamic‑delay shortcomings. The next part will dive into concrete implementation details such as the distributed coordination algorithm, task sharding strategy, and fault‑recovery mechanisms.