1 配置属性
1.1 执行器
任务的绑定的执行器：
- 任务触发调度时，将自动发现注册成功的执行器，实现任务自动发现
- 也方便进行任务分组
每个任务须绑定一个执行器, 可在 "执行器管理" 设置。
1.2 任务描述
便于任务管理
1.3 路由策略
当执行器集群部署时，提供的路由策略
- FIRST（第一个）：固定选择第一个机器
- LAST（最后一个）：固定选择最后一个机器
- ROUND（轮询）：
- RANDOM（随机）：随机选择在线的机器；
- CONSISTENT_HASH（一致性HASH）：每个任务按照Hash算法固定选择某一台机器，且所有任务均匀散列在不同机器上。
- LEAST_FREQUENTLY_USED（最不经常使用）：使用频率最低的机器优先被选举
- LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的机器优先被选举
- FAILOVER（故障转移）：按照顺序依次进行心跳检测，第一个心跳检测成功的机器选定为目标执行器并发起调度
- BUSYOVER（忙碌转移）：按照顺序依次进行空闲检测，第一个空闲检测成功的机器选定为目标执行器并发起调度
- SHARDING_BROADCAST(分片广播)：广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；
1.4 Cron
触发任务执行的Cron表达式。
2 运行模式
2.1 BEAN模式
任务以JobHandler方式维护在执行器端；需要结合 "JobHandler" 属性匹配执行器中任务；
2.2 GLUE模式(Java)
任务以源码方式维护在调度中心；该模式的任务实际上是一段继承自IJobHandler的Java类代码并 "groovy" 源码方式维护，它在执行器项目中运行，可使用@Resource/@Autowire注入执行器里中的其他服务；
2.3 JobHandler
运行模式为 "BEAN模式" 时生效，对应执行器中新开发的JobHandler类“@JobHandler”注解自定义的value值；
3 阻塞处理策略
调度过于密集执行器来不及处理时的处理策略； 单机串行（默认）：调度请求进入单机执行器后，调度请求进入FIFO队列并以串行方式运行； 丢弃后续调度：调度请求进入单机执行器后，发现执行器存在运行的调度任务，本次请求将会被丢弃并标记为失败； 覆盖之前调度：调度请求进入单机执行器后，发现执行器存在运行的调度任务，将会终止运行中的调度任务并清空队列，然后运行本地调度任务；
- 子任务：每个任务都拥有一个唯一的任务ID(任务ID可以从任务列表获取)，当本任务执行结束并且执行成功时，将会触发子任务ID所对应的任务的一次主动调度。
- 任务超时时间：支持自定义任务超时时间，任务运行超时将会主动中断任务；
- 失败重试次数；支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；
- 报警邮件：任务调度失败时邮件通知的邮箱地址，支持配置多邮箱地址，配置多个邮箱地址时用逗号分隔；
- 负责人：任务的负责人；
- 执行参数：任务执行所需的参数；
4 架构设计
4.1 设计思想
- 调度行为抽象形成“调度中心”公共平台，平台自身并不承担业务逻辑，“调度中心”只负责发起调度请求
- 任务抽象成分散的JobHandler，交由“执行器”统一管理，“执行器”负责接收调度请求，并执行对应JobHandler的业务逻辑
因此，“调度”、“任务”两部分可解耦，提高系统整体稳定性和扩展性。
4.2 系统组成
调度模块（调度中心）
管理调度信息，按调度配置发出调度请求，不承担业务代码。调度系统与任务解耦，提高系统可用性和稳定性，同时调度系统性能不受限于任务模块：
- 可视化、简单且动态的管理调度信息，包括任务新建，更新，删除，GLUE开发和任务报警等，所有上述操作都会实时生效
- 监控调度结果及执行日志
- 支持执行器Failover
执行模块（执行器）
接收调度请求并执行任务逻辑：
- 任务模块专注任务执行，开发维护更简单高效
- 接收“调度中心”的执行请求、终止请求和日志请求