Elastic-Job分布式任务调度：分片机制与高可用实战-育师

1. 先搞清楚：分布式任务调度到底解决什么问题

1.1 单机定时任务三个让人头疼的坑

我在写业务代码的时候，最早用定时任务就是JDK自带的Timer加一个ScheduledExecutorService，后来换成Quartz。说实话，单机场景下Quartz已经够用，但一旦系统拆成多节点部署，麻烦就一件接一件地冒出来。

先说说最典型的三个坑。

第一个坑：重复执行。同一个定时任务部署在三台机器上，到了执行时间三台机器同时跑，数据库里就多出三份脏数据。有人会说那我把任务只部署在一台机器上行不行？可以，但如果这台机器重启、宕机、发布的时候任务就空窗了，没有其他节点顶上。于是你需要在代码层面自己写分布式锁，用数据库行锁或者Redis锁，但锁的续期、超时、异常释放这些细节，做起来一点都不轻松。

第二个坑：分片需求几乎无法优雅实现。业务上经常有这样的需求，比如定时扫描用户表，按userId把数据分成四份，每台机器各处理一份。这种逻辑用Quartz写，你得在代码里自己算余数、自己判断当前机器处理哪几份数据。最尴尬的是节点变更的时候，你没法平滑地把数据重新分配。这不是能不能做的问题，而是做了之后维护成本很高，改一次节点就要改一次配置，还要人为保证数据不重不漏。

第三个坑：运维观测基本靠猜。任务到底跑没跑、上一次执行成没成功、当前在哪台机器上执行、执行耗时多久，这些信息单机Quartz都不给你。出了问题只能翻日志，日志多的时候找得头大。

我选Elastic-Job，恰好就是因为它把这几个坑都填上了。

1.2 Elastic-Job用了什么思路来解决

Elastic-Job是面向分布式场景的轻量级任务调度方案，核心思路可以总结成一句话：让任务像数据库分表一样，按分片规则把数据拆开，交给不同节点执行，同时由注册中心统一协调状态。

它的几个关键设计，我认为是真正打动人的地方。

任务分片：把一次任务的数据量拆成多个分片，每个分片绑定一个执行节点。比如配置10个分片，集群里有3台机器，系统会自动分配成4、3、3这样的比例（实际上要根据一致性哈希等策略），每台机器只执行自己那份。
高可用：节点宕机后，它负责的分片会自动转移到剩余节点，不需要人工干预。
弹性扩容：新增一台机器，分片会重新分配，任务自动均衡到新节点上。
运维控制台：可以看到所有任务的执行状态、历史记录、分片分配情况，甚至可以手动触发一次任务。

这套思路本质上就是把“定时触发”和“分布式协调”两件事解耦。触发机制由Elastic-Job的调度器完成，协调机制由ZooKeeper完成。你在业务代码里只需要关心自己的数据逻辑，不需要关心任务跑在哪台机器、那几个分片归我处理。

1.3 和常规方案的对比，我为什么选它

我再换一个角度说说为什么选Elastic-Job，而不是其他方案。

拿Quartz做对比。Quartz可以做集群，但用的是数据库锁的方式，当任务量不大时勉强能用，可一旦调度频率高、任务节点多，数据库的锁竞争就会变成瓶颈。Elastic-Job把调度状态放到ZooKeeper上，协调开销小得多，而且天然支持分片。两者不在一个层次。

有一些轻量级的分布式任务方案，比如基于Redis延迟队列自己写一套，也可以用。但这类方案的灵活性往往不够：没有控制台、没有分片、没有事件追踪，后续扩展、排查问题都要自己动手。

还有一个很现实的点：Elastic-Job本身就脱胎于生产环境，很多大厂都在用，踩坑案例网上多，社区资料足够丰富。对于我们做后端的人来说，一套方案稳定、资料多、能快速落地，比看起来花哨更重要。

当然，它也有自己的缺点。例如依赖ZooKeeper，意味着多了一个中间件要维护；控制台也稍显陈旧。但瑕不掩瑜，在用过的任务调度框架里，Elastic-Job算是省心且取舍合理的一个。

2. 核心概念拆解：作业、分片、注册中心

2.1 三种作业类型该怎么选

Elastic-Job把任务分成三种类型，开始用之前需要先理解它们各自的定位，不然容易选错。

Simple类型：最常用，也是最基础的。你只需要实现一个execute方法，方法里写任务逻辑。它适合那些不需要“拉取数据再处理”这种流式步骤的任务。举个例子，每天凌晨清理过期日志，调用execute直接执行即可。

Dataflow类型：适合“先抓数据，再处理数据”的两段式任务。它定义了两个方法：fetchData抓取要处理的数据，processData处理这些数据。框架会循环调用这两个方法，直到fetchData返回空。如果你的任务是“从消息表里抓一批待发送的消息，然后调接口发出去”，选Dataflow比较合适。

Script类型：适合执行脚本或命令行任务。它不要求你写Java逻辑，而是配置一个脚本路径，框架定时去执行这个脚本。比如你要跑一个Python数据分析脚本，或者一个Shell备份命令，用Script作业最省事。

我自己的经验是：不要一上来就追求Dataflow，很多场景Simple就够。Dataflow那套“持续拉取直到拉完”的循环机制，如果数据量比较大又没控制好，很容易一次任务跑太久，反而把资源耗尽。

作业类型	适合场景	核心方法	注意事项
Simple	定时执行一段逻辑	execute	最简单，90%场景用它
Dataflow	抓取数据、处理数据的流式场景	fetchData / processData	注意控制拉取频率和数据量
Script	Shell、Python等外部脚本	无，配置脚本路径	注意脚本执行权限与超时

2.2 分片机制：核心中的核心

如果把Elastic-Job里的概念按重要性排序，分片绝对是第一。不理解分片，后面很多问题都很难定位。

所谓分片，就是任务数据被拆成N份（N是你在配置里设置的shardingTotalCount）。这个N不是节点数，而是你想拆几份。比如你想让3台机器处理100万条数据，可以设置10个分片。框架会把10个分片按规则分给3台机器，每台机器拿到的分片数大致是4、3、3。

具体哪个分片归哪台机器，通过ZooKeeper的临时节点和选举机制决定。节点上线时注册临时节点，下线时临时节点消失，框架感知后重新分配未完成的分片。

在业务代码里，你需要根据当前分片去过滤数据。Elastic-Job会把分片上下文ShardingContext传给你，里面包含shardingItem（当前分片编号）和shardingParameter（对应分片的自定义参数）。

最常用的策略是用分片项做取模。假设我们要扫描用户表，配置10个分片，那么在execute方法里可以这样写：查询用户时加上where user_id % 10 = ${shardingItem}。这样每个分片只处理自己对应余数的那些用户。数据就天然被拆开了，互不冲突。

还有一个重要的点：分片参数。shardingItemParameters这个配置允许你给每个分片绑定不同的业务参数。比如0=A,1=B,2=C，那么分片0执行时shardingParameter就是A，你可以用它来做更多条件控制。这在某些需要差异化处理的场景下非常有用，比如某些分片处理国内数据，某些分片处理海外数据。

2.3 注册中心：为什么非要ZooKeeper

很多第一次接触Elastic-Job的人会问：为什么中间非要加一个ZooKeeper？不用行不行？

这个问题的答案，要从分布式协调的本质说起。一个任务由谁触发、哪个节点执行哪些分片、节点列表发生了变化、任务执行状态如何同步，这些信息需要在多个节点之间共享。Elastic-Job需要一个可靠的、支持临时节点和数据变更通知的组件，ZooKeeper正好满足这些需求。

更重要的是，ZooKeeper的临时节点机制非常适合做故障检测。节点与ZooKeeper之间维持心跳，如果节点挂了，心跳断开，临时节点被自动删除，其他节点能立刻收到通知并进行分片重新分配。如果换成普通数据库，你只能靠轮询和超时判断节点是否存活，时效性和可靠性都差不少。

当然，如果你的集群只有一两台机器，任务也不复杂，也许不需要这么重的方案。但既然选了Elastic-Job，就接受ZooKeeper这个依赖吧。生产环境ZooKeeper集群一般是3个或5个节点，保证高可用即可。

我有个习惯：单独给Elastic-Job划分一个ZooKeeper命名空间（namespace），不要和业务的其他ZooKeeper使用混在一起。这样职责清晰，清理的时候也方便，避免误删别人的节点。

3. 从零搭建：一个可运行的Elastic-Job示例

3.1 依赖引入与基础配置

纸上谈兵说完，现在进入实际操作。我先给出一套最简洁的集成方式，基于Spring Boot项目，假设你已经有一个可运行的工程。

第一步，引入Maven依赖。以ElasticJob-Lite 2.x版本为例，核心依赖如下：

<dependency> <groupId>com.dangdang</groupId> <artifactId>elastic-job-lite-core</artifactId> <version>2.1.5</version> </dependency> <dependency> <groupId>com.dangdang</groupId> <artifactId>elastic-job-lite-spring</artifactId> <version>2.1.5</version> </dependency>

如果是Spring Boot工程，推荐直接使用elastic-job-lite-spring-boot-starter，可以少写不少配置类。

第二步，配置ZooKeeper连接信息和任务默认配置。我一般放在application.yml里：

elasticjob: regCenter: serverLists: 127.0.0.1:2181 namespace: elasticjob-example jobs: mySimpleJob: elasticJobClass: com.example.demo.job.MySimpleJob cron: 0 0 1 * * ? shardingTotalCount: 4 shardingItemParameters: 0=first,1=second,2=third,3=fourth

这里说明一下关键参数的含义：

serverLists：ZooKeeper地址，多个节点用逗号分隔。
namespace：ZooKeeper里的命名空间，隔离不同项目的任务数据。
cron：任务触发表达式。
shardingTotalCount：分片总数。
shardingItemParameters：分片项与参数映射关系，可选。

3.2 实现第一个Simple作业

配置写好之后，定义一个任务类，实现SimpleJob接口。这个接口只有一个方法execute，方法入参是ShardingContext。

package com.example.demo.job; import org.apache.shardingsphere.elasticjob.api.ShardingContext; import org.apache.shardingsphere.elasticjob.api.simple.SimpleJob; import org.springframework.stereotype.Component; @Component public class MySimpleJob implements SimpleJob { @Override public void execute(ShardingContext shardingContext) { int shardingItem = shardingContext.getShardingItem(); String shardingParameter = shardingContext.getShardingParameter(); System.out.println("分片项：" + shardingItem + "，分片参数：" + shardingParameter); // 模拟处理自己的数据 // 比如处理 userId % shardingTotalCount == shardingItem 的那些用户 processByShardingItem(shardingItem); } private void processByShardingItem(int shardingItem) { // 业务逻辑，略 } }

这里补充一个重点：每个分片都会触发一次execute方法。也就是说，如果配置了4个分片，你的execute方法会被执行4次（分别在对应的节点上），每次拿到的shardingItem不同。实际操作中不要在这方法里写全局性的逻辑，比如清空一张表，否则每个分片都会清一次，彻底乱套。

3.3 分片参数与运维控制台

任务跑起来之后，怎么观察效果？Elastic-Job自带的运维控制台elastic-job-console可以帮上大忙。

控制台是一个独立的Web应用，部署好之后填入ZooKeeper地址和命名空间，就能看到任务列表。它提供几个很实用的能力：

任务状态：查看每个任务当前是启用还是禁用。
分片分配：查看每个分片当前落在哪台机器上。
运行轨迹：查看最近一次执行的开始时间、结束时间、耗时，甚至每个分片的执行结果。
手动触发：不用等cron表达式，直接在控制台点一下就能触发任务立即执行。

这个控制台在排查问题时特别好用。比如怀疑某台机器没跑任务，打开分片分配页面就知道分片是不是都挂在别的节点上。

另外，如果一个任务想临时停一下，不删除配置，可以在控制台上直接禁用。这个操作会通过ZooKeeper下发，所有节点都会感知到，比去代码里注释配置再发布一遍效率高太多。

有一点需要提醒：控制台只是运维工具，它本身不参与任务调度。就算控制台宕机了，任务调度也不会受影响——这一点设计得很干净。

4. 实操中常见的问题与排查技巧

4.1 分片分配不均匀

分片不均匀是我见过最频繁的“伪故障”。明明是3台机器10个分片，结果一台机器扛了6个分片，另外两台各扛2个。机械地看数字，会以为分配算法有问题。

但其实，Elastic-Job默认的分片策略是平均分配，只是节点上线时间不同会产生差异。比如说，第一台机器注册的时候只有它自己在线，10个分片全部分给它。之后第二台、第三台机器上线，分片不一定立刻重新分配。如果任务配置没有开启failover，并且没有触发重新分片的机制，就会出现“新节点不接活”的情况。

遇到这种情况，我的排查路径是这样的：

在控制台查看分片分配，确认是否真的不均。
确认是否有failover配置，该配置决定分片转移和重新分配的行为。
手动在控制台触发一次任务，观察分片是否重新分配。
如果还是不均衡，检查ZooKeeper上该任务的节点数据，看看是不是存在失效的临时节点占着位置。

其实，有时候不均匀并不是严重问题。只要每个分片的处理量都差不多，总体执行效率还是能接受的。真正要避免的是某些分片永远落在同一台机器上，其他机器空转。

4.2 任务重复执行与幂等性

Elastic-Job虽然是分布式调度，但它不保证任务一定不会重复执行。这一点我觉得是所有使用者都要尽早认清的现实。

为什么会有重复？两个原因最常见：

任务执行超时，cron下一次触发时间到了，上一次还没跑完。
failover机制下，分片重新分配之后，新节点会重新执行这个分片的任务。

面对重复执行，最有效的方案是让任务本身具备幂等性。我在业务代码里通常会在数据库层面加唯一索引或者任务流水表。任务开始时插入一条任务流水记录，如果插入成功说明之前没跑过，继续执行；插入失败则说明已经执行过或正在执行，直接跳过。

可以用类似这样的逻辑：

-- 任务流水表 CREATE TABLE task_watermark ( id BIGINT PRIMARY KEY AUTO_INCREMENT, job_name VARCHAR(64) NOT NULL, sharding_item INT NOT NULL, execute_time DATETIME NOT NULL, UNIQUE KEY uk_job_sharding (job_name, sharding_item, execute_time) );

任务里执行前先插入一条，插入成功才继续业务逻辑。这样就算分片被多个节点交替执行，也不会数据重复。

4.3 事件追踪不生效

有时候你想在控制台看每个分片的执行轨迹，结果发现轨迹是空的。这通常是因为没有配置事件追踪功能。

Elastic-Job的事件追踪默认不开启，需要额外配置存储事件数据的表或者数据库。常见做法是在ZooKeeper配置之外再指定一个数据源，框架会把任务执行事件写到这个库里。控制台从库里读取这些事件并展示。

如果你用的是Spring Boot starter，配置里没有明确加数据源，事件追踪很可能就是静默失效的。排查步骤就两步：确认配置中有没有指定事件追踪数据存储；确认事件表是否创建成功。一般把这两点搞定，轨迹数据就出来了。

4.4 实际踩坑清单

我再整理几条实操中容易踩的坑，每条都是真实遇到过的。

第一条：ZooKeeper地址配置错误导致任务无法注册。这种情况日志里会反复报连接异常，但应用本身不报错，容易忽略。我习惯先把连接信息单独抽出来，用自测工具测一遍连通性，再让任务启动。

第二条：分片总数和数据库表数量对不上。如果分片总数设计为10，但业务数据只有几千条，取模之后很多分片数据量为0，这没问题。但反过来，如果分片总数设得太大，集群节点又少，每个节点要处理的分片数量就会很多，任务的总耗时可能不降反升。分片总数建议和节点数的整数倍挂钩，比如节点数的1到3倍，不要拍脑袋设一个超大的数。

第三条：多个任务共用一个作业类。在配置里为同一个elasticJobClass配置多个任务时，要特别注意任务名称不能混淆。Elastic-Job是以任务名称作为ZooKeeper节点的区分依据，如果任务类相同但任务名不同，分片上下文和事件都会按任务名隔离，配置错位会导致任务执行逻辑被串掉。

第四条：服务器时间不一致。虽然听起来基础，但多台服务器时间偏差大的话，cron触发会有明显的时间差。有些节点会提前触发，有些会延后。最好在运维层面统一用NTP同步服务器时间。