Detailed explanation of SpringBoot's monolithic and distributed task architecture

In the Spring Boot ecosystem, the selection of a timed task framework needs to be traded down based on the architecture type (monopoly or distributed) and functional requirements. The following is a detailed review of the mainstream timing task framework and its classification from the perspectives of framework characteristics, applicable scenarios and Spring Boot integration methods:

1. The timing task framework under a single structure

Core Requirements: Lightweight, high ease of use, no complex coordination mechanism required
Applicable scenarios: Stand-alone deployment, simple task logic, no need for high availability or sharding processing.

1. Spring Task（@Scheduled）

characteristic：

• Spring's own lightweight timing task framework, through@EnableSchedulingand@ScheduledAnnotation Quick configuration tasks.
• Supports Cron expressions and fixed frequency (fixedRate), fixed delay (fixedDelay) and other scheduling methods.
• Single threaded execution: Default serial execution tasks, need to be combined@AsyncOr custom thread pool to implement concurrency.

advantage：

• Zero extra dependencies, seamless integration with Spring Boot.
• Simple configuration, suitable for rapid development.

shortcoming：

• Dynamic modification of task parameters is not supported (restart the application).
• No distributed coordination capabilities, tasks are repeatedly executed when deploying multiple nodes.

Spring Boot Integration Example：

@SpringBootApplication
@EnableScheduling
public class App { ... }
@Component
public class MyTask {
    @Scheduled(cron = "0 */5 * * * ?")
    public void execute() { ... }
}

2. ScheduledExecutorService

characteristic：

• JDK built-in thread pool scheduling tool, throughScheduledThreadPoolExecutorImplement multi-threaded concurrent execution.
• Support delayed tasks (schedule) and periodic tasks (scheduleAtFixedRate）。

advantage：

• Lightweight, no Spring dependencies required.
• Avoid single-threaded blocking problems and is suitable for CPU-intensive tasks.

shortcoming：

• Cron expressions are not supported, and complex scheduling logic needs to be implemented by yourself.
• No task persistence capability, task is lost after application restart.

Example：

ScheduledExecutorService executor = (2);
(() -> { ... }, 0, 1, );

3. Timer features:

• The timer class provided by JDK in the early days (),passTimerTaskDefine task logic.

advantage：

• Simple and easy to use, suitable for minimalist scenarios.

shortcoming：

• Single-threaded serial execution, task blocking leads to inaccurate scheduling. The exception handling mechanism is incomplete and the task is terminated as a whole after the crash.
• status quo: Has beenScheduledExecutorServiceReplace, new projects are not recommended.

2. Timed task framework under distributed architecture

Core Requirements: High availability, task sharding, failover, load balancing
Applicable scenarios: Multi-node cluster deployment, tasks need to be expanded and scaled elastically to avoid repeated execution.

1. Quartz

characteristic：

• Powerful: Supports Cron expressions, calendar scheduling, and task persistence (JDBCJobStore).
• Cluster mode: Through the database lock (e.g.LOCKSTable) Implement node coordination to avoid repeated tasks execution.
• Task sharding: You need to implement sharding logic by yourself, without native support.

advantage：

• Mature and stable, with extensive community support. Spring Boot 2.0+ is built-in integration for simplified configuration.

shortcoming：

• Strongly invasive: Need to be definedJobInterface implementation class, coupled with business code.
• Performance bottleneck: Database lock competition may become a bottleneck under high concurrency.

Spring Boot Integration：

# 
spring:
  quartz:
    job-store-type: jdbc
    properties:
      : MyScheduler
      : 
      : myDS

@Bean
public JobDetail sampleJobDetail() {
    return ().storeDurably().build();
}

2. Elastic-Job

characteristic：

• Elastic scheduling: Based on ZooKeeper, it realizes distributed coordination, supports sharding, failover, and elastic expansion and scaling.
• Task sharding: Split the task into multiple shard items and processed in parallel by different nodes.
• Lightweight: Uncentralized design, integrated through jar package.

advantage：

• High availability, automatic reassignment after a task fails. Supports dynamic expansion and has high resource utilization.

shortcoming：

• Rely on ZooKeeper to increase operation and maintenance complexity. Community activity is lower than XXL-JOB.

Spring Boot Integration：

<dependency>
    <groupId></groupId>
    <artifactId>elasticjob-lite-spring-boot-starter</artifactId>
</dependency>

@ElasticJobScheduler(
    jobName = "myJob",
    cron = "0/5 * * * * ?",
    shardingTotalCount = 3
)
public class MyJob implements SimpleJob {
    @Override
    public void execute(ShardingContext context) { ... }
}

3. XXL-JOB

characteristic：

• Centralized scheduling: The dispatch center (Admin) is separated from the executor and communicates through RPC.
• Visual interface: Provides operation and maintenance functions such as task management, log tracking, alarm notification, etc.
• Sharded broadcast: Support dynamic sharding, and task parameters are passed through HTTP API.

advantage：

• Out of the box, low learning cost.
• Supports GLUE scripts and dynamically modify task logic.

shortcoming：

• The dispatch center needs to be deployed independently to increase the complexity of the architecture.
• The community version has limited functions and the enterprise version requires a fee.

Spring Boot Integration：

# 
xxl:
  job:
    admin:
      addresses: http://xxl-job-admin:8080/xxl-job-admin
    executor:
      appname: xxl-job-executor
      port: 9999

@XxlJob("demoJobHandler")
public void execute() { ... }

3. Frame comparison and selection suggestions

Selection strategy：

• Single-body application: Priority is given to Spring Task, and complex scenarios are combined with thread pool optimization.
• Distributed lightweight requirements: When choosing Quartz, you need to tolerate database dependence and lock competition.
• High availability and sharding: Elastic-Job or XXL-JOB, the latter is suitable for scenarios where the operation and maintenance interface is required.

4. Summary

In Spring Boot, the selection of a timed task framework requires weighing architectural requirements and functional complexity:

• Monopoly architecture: Spring Task and ScheduledExecutorService provide rapid development capabilities.
• Distributed architecture: Quartz is suitable for basic needs, while Elastic-Job and XXL-JOB cover high availability, sharding and operation and maintenance management.

Developers should choose the most suitable framework based on the task scale, team technology stack and operation and maintenance capabilities.

This is the end of this article about SpringBoot's monolithic and distributed task architecture. For more content related to SpringBoot's distributed task architecture, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!