一、概述
按目前的设计,每个集群(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
以上事件都会触发任务分配:根据任务preferNodes配置和overload,生成job和node映射关系。
完成后更新config、runtime中相关节点。
主节点执行,选主期间不能操作。
leaving会触发故障转移。
/{namespace}/runtime/node/{nodeName}/jobInstance下的任务实例都会触发retry操作。
网友评论