Elastic-Job源码分析-作业节点

最近事有点多，源码分析进度远低于预期，先来个简短的赶下进度，希望每篇的时间间隔不要太长。

上篇文章详细分析了调度的整个启动过程，今晚抽空对elastic-job在ZK创建的节点数据做个简要分析。

elastic-job主要是用ZK来实现分布式数据管理和调度的，他在ZK上建立很多节点，今天我们来简单分析下具体建立了哪些节点，都起什么作用。

作业节点树

首先我来看下elastic-job在ZK上创建的整个节点树：

jobNode.png

• 根节点elastic-job-example

  是elastic-job在ZK上的一个命名空间，节点类型为永久节点。

• 作业节点myElasticJob

  以某个具体的作业名称命名，代表某个具体作业的节点，节点类型为永久节点。

• instances节点

  保存该调度所有作业分片的进程实例的唯一标识，唯一标示的命名规则为IP@-@PID，节点类型为临时节点。

• leader节点

  leader节点主要作用是选举主节点及分片，他两个子节点election和sharding

  • election

    election节点下有个instance子节点，存储着选举出来的主作业进程唯一标识，为临时节点；

    election下还有个latch节点，是ZK实现的分布式锁的锁节点，为永久节点。

  • sharding

    sharding为分片状态节点，有3种子节点，为临时节点，分别代表3种状态：

    • 待分片：sharding节点下存在名为necessary的子节点;
    • 正在分片：sharding节点下存在名为processing的子节点;
    • 分片完成：sharding节点下无子节点, 表示分片完成。

• servers节点

  servers节点下的每个子节点代表一个启动过调度服务的机器，以机器IP命名，为永久节点。

• sharding节点

  sharding节点下会存在一个或多个子节点，以分片号命名，上图以分片0为例，子节点0下还会有个以instance命名的子节点，

  instance节点值为作业进程唯一标示；

  此外，节点0下还存在3种表示调度作业运行状态的子节点，分别是：

  • running：作业分片在运行中，临时节点.
  • misfire：该作业分片被错过执行了，永久节点.
  • disabled：作业被禁用，永久节点.

其实除了上图中展示的节点以外，在作业节点下还存在一个以guarantee命名的子节点，他用来记录和判断分布式下的所有任务分片都全部开始和结束。

• guarantee节点

  guarantee节点下会有2个子节点，分别是

  started和completed，分别记录开始的作业分片号和完成的作业分片号。

小结

整个elastic-job在ZK上创建的节点主要为上面这些，每个节点的创建时间及节点之间的关系，将会在接下来的文章中结合功能点及源码穿插着分析，同时对于这些建立在ZK上的不同节点的理解也是后续源码分析的基础。