一、概述

按目前的设计，每个集群（cluster）为一个业务部门服务，完全属于这个业务部门。

同时可以存在多个集群，提供统一的控制台集中管理这些集群。

集群不可以跨IDC，但可以在同城IDC、甚至异地IDC设置影子集群，调度系统自动同步配置。

当前IDC调度集群整体故障时，可以手动或自动拉起同城影子集群，实现跨IDC高可用。

二、数据结构

采用树形存储。

1. namespace

根目录下，为namespace，同一业务部门下可能分业务组，不同业务组使用不同的namespace，形如：com.nucc.clearing。

/ {namespace}
/config
/runtime

namespace下，分两个子节点：config和runtime。

config下存放配置信息，静态的，可以通过控制台界面或调用api修改。

runtime下存放运行时信息，包括：当前存活节点信息、正在执行中的Job状态等。

2. config

/{namespace}/config
/job
/{jobName} |data: jobConfig,json格式,形如{jobCron:xx,overload:x,state:暂停,preferNodes:xx}
/node
/{nodeName}|data: nodeInfo,json格式，形如{ip:xx, port:xx,state:正常}

config下，分两个子节点：job和node。

job下保存多个job的配置信息，以jobName为key，节点上保存数据，json格式，保存job详细配置信息。

node下保存多个节点信息，这里保存的配置的节点信息，以界面配置或配置文件为准，和节点是否在线无关，其中state也是配置的状态，不是实时状态。

3. runtime

/{namespace}/runtime
/job
/{jobName}
/node
/{nodeName}

同config类似。

4. job runtime

/{namespace}/runtime/job/{jobName}
/availableNodes
/{nodeName1}
/{nodeName2}
/instance
/{jobInstanceId} |data: {startAt:xx, node:xx, state:x, childrenCount:x,retryCount:x}
/children
/{childInstanceId1} |data: {state:running, startAt:xx, node:xx}
/{childInstanceId2} |data: {state:running, startAt:xx, node:xx}

5. node runtime

/{namespace}/runtime/node/{nodeName}
/job
/{jobName1}
/{jobName2}
/jobInstane
/{jobInstaceId}
/{childJobInstaceId}

三、生命周期

1. job

(1)starting

(2)updating

(3)stopping

以上事件都会触发任务分配：根据任务preferNodes配置和overload，生成job和node映射关系。

完成后更新config、runtime中相关节点。

主节点执行，选主期间不能操作。

2. job instance

（1）starting

如果是普通任务，创建instance节点。

如果是dynamic类型的子任务，在children下创建节点。

如果是sharding类型的子任务，在children下创建节点。

（2）running

状态改为running，提交到raft存储。

（3）finishing

子任务正常完成，提交状态更新，触发父任务finishing操作，检查是否整体完成（时间相近的检查合并执行）。

子任务抛异常，提交更新状态，触发父任务finnishing操作。需通过界面或调用api手动重新执行。

子任务执行超时，触发故障转移，更新重试次数。

如普通任务整体完成，则删除{instanceName}节点。

3. node config / runtime

(1)joining

(2)leaving