ElasticJob 学习路线

本页只是索引。ElasticJob 的主线是「分片号怎么分、故障后怎么接管」；它不路由数据，也不保存进度。机制细节在正文，本页只给顺序、前置和自检。

适用版本：ElasticJob 3.x（正文以 3.0.5 为例），ZooKeeper 3.5+（练习用 3.9）。3.x 与 2.x 的包名、接口和 Spring Boot 配置键不同，不要混用资料。

前置

• ZooKeeper 的 Session、临时节点、Watch：01-ZK架构与ZAB协议；会话超时和生产边界：04-生产踩坑与运维。
• 分布式调度的基本故障域：重复、漏执行、倾斜、接管、misfire。可以先读 02-调度系统的五个故障域 建立分类，再回到 01 看机制。
• 业务侧要准备：稳定的数据切分键、幂等键、进度表；没有这三样，故障接管和补跑都会制造重复。

阅读顺序

顺序	文章	读完能带走什么
1	01-ElasticJob分片调度	分片项与实例的关系；ZK 中的作业结构；取数为什么用 MOD(id, shardingTotalCount)；故障接管为什么是换宿主而不是续进度。
2	02-调度系统的五个故障域	重复、漏执行、倾斜、接管、misfire 各自的触发条件，以及框架能解决和不能解决的部分；与 XXL-JOB 的调度模型差异。
3	99-生产检查清单	上线前、运行中、故障时的可执行动作，按 ZK 会话、分片、幂等、misfire 分组。

只读一篇时先读 01；要做选型或排故障，再读 02 和 99。

与 XXL-JOB 的衔接

• 中心化调度的对照：03-调度核心机制。
• 心跳和故障剔除的对照：05-心跳与故障剔除。

读后自检

• 能说清实例数变化和 shardingTotalCount 变化分别会改变什么，以及改分片数为什么需要迁移或全量重跑。
• 能画出实例宕机后的接管链路：ZK 会话过期 → 临时节点删除 → Leader 重新分片 → 新宿主从分片起点重跑。
• 能解释为什么用了 DataflowJob 仍然要业务自己存 offset，以及 props.streaming.process=true 改变的是什么。
• 能区分 failover、monitorExecution、misfire 三个开关各自解决什么、不解决什么。
• 能给出「ZK 不可用」的观测和处置顺序，并说明为什么失联实例不能继续跑旧分片。