ElasticJob relies on ZooKeeper clusters for job coordination, which means you must provision, monitor, and scale ZooKeeper nodes yourself. As your job count grows, you need additional clusters, which increases infrastructure cost and operational overhead. SchedulerX 2.0 is fully compatible with ElasticJob interface classes and provides a managed scheduling platform that eliminates ZooKeeper dependencies. Migrate your existing ElasticJob jobs by changing only Maven dependencies and configuration -- no business code changes required.
ElasticJob is a lightweight and decentralized distributed job scheduling framework developed based on Quartz. It is available as an open-source service integrated into Apache. ElasticJob uses ZooKeeper as a registry center, which requires a cluster of at least three nodes. If a node fails, you must reconfigure the ZooKeeper server and client, and you may need to restart all applications. A single ZooKeeper cluster cannot handle a large number of jobs due to feature limits and cannot be scaled out for more TPS, so you may need to maintain multiple clusters. If you host ElasticJob jobs on SchedulerX 2.0, you no longer need to maintain ZooKeeper clusters.
This guide walks through the migration process using a Spring Boot application with ElasticJob 3.0.2.
Before you begin
Make sure you have:
An Alibaba Cloud account with SchedulerX 2.0 activated
A Spring Boot application that uses ElasticJob 3.0.2
A SchedulerX namespace. For instructions, see Create a namespace
A SchedulerX application registered in that namespace. For instructions, see Create an application
After creating the namespace and application, note down the namespace ID, groupId, and appKey from the console. You need these values in the configuration step.
For a complete working example, see the schedulerx-example-elasticjob demo project.
Step 1: Add the SchedulerX plugin dependency
Add the schedulerx2-plugin-elasticjob dependency before the ElasticJob dependency in your pom.xml file.
<dependency>
<groupId>com.aliyun.schedulerx</groupId>
<artifactId>schedulerx2-plugin-elasticjob</artifactId>
<version>3.0.2.2</version>
</dependency>
<dependency>
<groupId>org.apache.shardingsphere.elasticjob</groupId>
<artifactId>elasticjob-lite-spring-boot-starter</artifactId>
<version>3.0.2</version>
</dependency>The schedulerx2-plugin-elasticjob dependency must appear before elasticjob-lite-spring-boot-starter in your POM file.
Step 2: Configure SchedulerX as the scheduler
In your application.yml file, set elasticjob.scheduler to schedulerx and add the SchedulerX connection properties under spring.schedulerx2.
elasticjob:
regCenter:
serverLists: 127.0.0.1:2181
namespace: elasticjob-test
scheduler: schedulerx # Route scheduling to SchedulerX 2.0 instead of ZooKeeper
jobs:
simpleJob:
elasticJobClass: com.alibaba.elasticjob.test.processor.SpringBootSimpleJob
cron: 0/10 * * * * ?
shardingTotalCount: 1
overwrite: true
shardingJob:
elasticJobClass: com.alibaba.elasticjob.test.processor.SpringBootShardingJob
cron: 0 * * * * ?
shardingTotalCount: 3
shardingItemParameters: 0=Beijing,1=Shanghai,2=Guangzhou
overwrite: true
# SchedulerX 2.0 connection settings
spring:
schedulerx2:
endpoint: acm.aliyun.com
namespace: <your-namespace-id> # Example: 433d8b23-xxxx-xxxx-xxxx-90d4d1b9a4af
groupId: <your-group-id> # Example: xueren_primary
appKey: <your-app-key>
regionId: public
aliyunAccessKey: <your-access-key>
aliyunSecretKey: <your-secret-key>Replace the following placeholders with your actual values:
| Placeholder | Description | Where to find it |
|---|---|---|
<your-namespace-id> | SchedulerX namespace ID | SchedulerX console > Namespace Management |
<your-group-id> | Application group ID | SchedulerX console > Application Management |
<your-app-key> | Application key | SchedulerX console > Application Management |
<your-access-key> | Alibaba Cloud AccessKey ID | AccessKey Management |
<your-secret-key> | Alibaba Cloud AccessKey Secret | AccessKey Management |
For a full reference of SchedulerX connection parameters, see Connect a Spring Boot application to SchedulerX.
Step 3: Add component scanning for the SchedulerX plugin
Add com.alibaba.schedulerx.plugin.* to your application's @ComponentScan so that Spring Boot loads the plugin classes at startup.
@SpringBootApplication
@ComponentScan(basePackages = {"com.alibaba.schedulerx.plugin.*", "your.application.package"})
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}Replace your.application.package with your actual application base package.
Step 4 (optional): Set up log collection
SchedulerX 2.0 can collect job execution logs from your application. The following example configures log collection with log4j2.
Create or update your log4j2.xml configuration file:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="off">
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout
pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %m%n" />
</Console>
<SchedulerxLog4j2Appender name="schedulerxLog"
timeFormat="yyyy-MM-dd'T'HH:mmZ"
timeZone="UTC"
ignoreExceptions="true">
<PatternLayout pattern="%d %-5level [%thread] %logger{0}: %msg"/>
</SchedulerxLog4j2Appender>
</Appenders>
<Loggers>
<Root level="info">
<AppenderRef ref="Console" />
</Root>
<Logger name="schedulerx" level="info" additivity="false">
<AppenderRef ref="schedulerxLog" />
</Logger>
</Loggers>
</Configuration>To write logs to the SchedulerX logging service from your job code, get the logger named schedulerx:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyJob implements SimpleJob {
private static final Logger schedulerxLogger = LoggerFactory.getLogger("schedulerx");
@Override
public void execute(ShardingContext shardingContext) {
schedulerxLogger.info("Processing shard: {}", shardingContext.getShardingItem());
// Your job logic here
}
}For other logging frameworks, see Logging services supported by SchedulerX.
Step 5: Verify the migration
Start your application. SchedulerX 2.0 automatically syncs your ElasticJob definitions to the console. During sync, SchedulerX applies the following rules:
Second-level cron expressions are converted to the
second_delaytrigger type.Jobs with
shardingTotalCountgreater than 1 run in sharding mode. All other jobs run in standalone mode.
Open the SchedulerX console and confirm that your jobs appear under the correct namespace and application. Check the execution logs to verify that jobs run as expected.
Roll back to ElasticJob
If you need to switch back to the ElasticJob scheduler, pass the following JVM parameters when starting your application:
-Dspring.schedulerx2.enabled=false -Delasticjob.scheduler=elasticjobThis disables the SchedulerX plugin and restores ElasticJob's native ZooKeeper-based scheduling. No code changes are required.
Migration benefits
After migration, SchedulerX 2.0 provides the following capabilities that are not available in open-source ElasticJob:
| Capability | Open-source ElasticJob | ElasticJob on SchedulerX 2.0 |
|---|---|---|
| Simple jobs | Supported | Supported |
| Script jobs | Supported | Supported |
| Dataflow jobs | Supported | Supported |
| Standalone execution | Supported | Supported |
| Sharding broadcast | Supported | Supported |
| Time-based scheduling | cron | cron, fixed_rate, fixed_delay, one_time |
| Workflows (job dependencies) | Not supported | Supported (DAG-based orchestration) |
| Visualization | Not available | Execution history, logging service, running stacks, operation records, user dashboards |
| Monitoring and alerting | Email only | Email, DingTalk groups, text messages, phone calls |
| Operations | Not available | Rerun failed jobs, run one-time jobs, update job outputs, mark as completed, view stacks, terminate jobs, specify machines |
SchedulerX 2.0 advantages:
No ZooKeeper maintenance. SchedulerX 2.0 is a fully managed service. You do not need to provision, scale, or troubleshoot registry infrastructure.
Built-in high availability. SchedulerX 2.0 creates multiple replicas for each job and continues scheduling even if two cluster nodes fail or a data center loses power. This architecture is battle-tested in Alibaba Group production scenarios such as Double 11 events.
Visual operations and monitoring. Access dashboards, execution history, running stacks, and operation logs directly in the SchedulerX console.
Flexible alerting. Receive notifications for job failures, timeouts, and no available machines through email, DingTalk groups, text messages, or phone calls.
DAG-based job orchestration. Define job dependencies using Directed Acyclic Graphs (DAGs) through a drag-and-drop interface in the console.
Concurrency throttling with priority queues. Control the maximum number of concurrent jobs per application. Jobs that exceed the threshold wait in a queue, and higher-priority jobs can preempt lower-priority ones.
Resource isolation. Isolate resources by namespace or application, with built-in multi-tenant permission management.
What's next
Connect a Spring Boot application to SchedulerX -- Full reference for SchedulerX connection parameters
Create a namespace -- Set up resource isolation boundaries
Create an application -- Register your application in SchedulerX