08_1_ElasticJob_基本使用

分布式调度 Elastic Job 详解

一、环境配置与基本使用

1. 环境准备
   依赖引入：

org.apache.shardingsphere.elasticjob elasticjob-lite-core 3.0.1 org.apache.curator curator-recipes 5.2.0

Zookeeper 配置：
启动 Zookeeper 服务（默认端口 2181），Elastic Job 使用 ZK 作为注册中心协调分布式节点。
2. 编写作业
简单作业类型（实现 SimpleJob 接口）：
public class MySimpleJob implements SimpleJob {
@Override
public void execute(ShardingContext context) {
int shardId = context.getShardingItem();
System.out.println("分片ID: " + shardId);
}
}

数据流作业类型（实现 DataflowJob 接口）：处理数据流的分片任务。
3. 配置与启动
// 配置注册中心
CoordinatorRegistryCenter regCenter = new ZookeeperRegistryCenter(
new ZookeeperConfiguration(“localhost:2181”, “elastic-job-demo”));
regCenter.init();
// 配置作业
JobConfiguration jobConfig = JobConfiguration.newBuilder(“myJob”, 3) // 3个分片
.cron(“0/5 * * * * ?”) // 每5秒执行一次
.shardingItemParameters(“0=Beijing,1=Shanghai,2=Guangzhou”) // 分片参数
.build();
// 创建作业实例
LiteJobConfiguration liteJobConfig = LiteJobConfiguration.newBuilder(jobConfig).build();
new ScheduleJobBootstrap(regCenter, new MySimpleJob(), liteJobConfig).schedule();

4. 运行与验证
   启动多个进程实例，观察分片任务在不同节点上的分配与执行。

---

二、高级功能使用

1. 分片策略
   默认分片策略：平均分配分片到各节点。
   自定义分片策略：实现
   JobShardingStrategy 接口，例如按业务参数分片。

2. 故障转移与失效转移
   故障转移：节点宕机时，其他节点接管其分片。
   失效转移：作业执行失败后，重新调度到其他节点。

3. 作业监听器
   public class MyJobListener implements ElasticJobListener {
   @Override
   public void beforeJobExecuted(ShardingContext context) {
   System.out.println("任务开始: " + context.getJobName());
   }
   @Override
   public void afterJobExecuted(ShardingContext context) {
   System.out.println("任务结束: " + context.getJobName());
   }
   }
   // 在 JobConfiguration 中添加监听器
   jobConfig.getJobListenerTypes().add(“myListener”);

4. 数据流处理
   配置 streamingProcess: true 开启持续数据抓取，直到数据为空。

5. 动态扩缩容
   通过修改分片数 shardingTotalCount 动态调整任务分布。

6. 静态分片
   使用 shardingItemParameters 固定分片与业务参数的映射。

---

三、底层调度原理分析

1. 调度中心
   Zookeeper 协调：通过 ZK 的临时节点（/instances）监控节点存活，利用持久化节点存储作业配置。
   分片分配：基于 Leader Election 选举主节点，主节点计算分片分配策略（如平均分配）。
   事件触发：监听 ZK 节点变化（如节点上下线），触发重新分片。
2. 作业执行
   分片执行逻辑：每个节点根据分片参数执行任务，通过 ShardingContext 获取当前分片信息。
   失效重试：若任务执行失败，记录错误次数，超过阈值后标记为失效分片。
3. 高可用机制
   主节点选举：通过 ZK 的 Leader Latch 实现，主节点负责分片计算。
   幂等性保证：通过数据库唯一键或分布式锁避免重复执行。

---

四、底层架构设计分析

1. 模块分层
   作业注册层：管理节点注册与心跳检测。
   配置管理层：持久化作业配置（如分片数、Cron 表达式）。
   调度核心层：分片策略、故障转移、事件监听。
   执行器层：实际执行作业逻辑，支持多种作业类型（Simple/Dataflow/Script）。
2. 分布式协调
   Zookeeper 作用：
   存储作业配置（持久化节点）。
   记录节点存活状态（临时节点）。
   事件通知（Watcher 机制）。
3. 调度流程
   触发调度：Cron 表达式触发或手动调用。
   分片计算：主节点计算分片分配策略。
   任务分发：各节点拉取分配给自己的分片。
   执行与反馈：节点执行任务并上报状态。
4. 高可用设计
   主节点容灾：主节点宕机后重新选举。
   分片抢占式执行：节点通过 ZK 临时节点抢占分片锁。
5. 弹性扩缩容
   动态分片：修改分片数后，重新计算分配策略。
   资源隔离：分片参数与业务绑定，避免资源争抢。
6. 扩展性
   SPI 机制：支持自定义分片策略、事件监听器等。
   Spring 集成：通过命名空间简化配置。

---

五、总结
适用场景：定时任务、大数据分片处理、分布式批处理。
优势：弹性扩缩容、故障自动转移、分布式协调。
对比：相比 Quartz（单点调度）、XXL-JOB（中心化调度），Elastic Job 更适合大规模分布式场景。