1.1 LTS技术架构
LTS 着力于解决分布式任务调度问题,将任务的提交者和执行者解耦,解决任务执行的单点故障,支持动态扩容,出错重试等机制。代码程序设计上,参考了优秀开源项目Dubbo,Hadoop的部分思想。
LTS目前支持四种任务:
- 实时任务:提交了之后立即就要执行的任务。
- 定时任务:在指定时间点执行的任务,譬如 今天3点执行(单次)。
- Cron任务:CronExpression,和quartz类似(但是不是使用quartz实现的)譬如 0 0/1 * ?
- Repeat任务:譬如每隔5分钟执行一次,重复50次就停止。
架构设计上,LTS框架中包含以下五种类型的节点:
JobClient
:主要负责提交任务, 并接收任务执行反馈结果。JobTracker
:负责任务调度,接收并分配任务。TaskTracker
:负责执行任务,执行完反馈给JobTracker。LTS-Monitor
:主要负责收集各个节点的监控信息,包括任务监控信息,节点JVM监控信息LTS-Admin
:管理后台)主要负责节点管理,任务队列管理,监控管理等。
LTS的这五种节点都是无状态的,都可以部署多个,动态扩容,来实现负载均衡,实现更大的负载量, 并且框架采用FailStore策略使LTS具有很好的容错能力。
架构图
Registry: 注册中心,LTS提供多种实现,目前支持
zookeeper
(推荐)和redis
, 主要用于LTS的节点信息暴露和master节点选举。FailStore:失败存储,主要用于在部分场景远程RPC调用失败的情况,采取现存储本地KV文件系统,待远程通信恢复的时候再进行数据补偿。目前FailStore场景,主要有
RetryJobClient
提交**任务失败的时候,存储FailStore;TaskTracker
返回任务执行结果给JobTracker
的失败 时候,FailStore;TaskTracker
提交BizLogger
的失败的时候,存储FailStore. 目前FailStore有四种实现:leveldb,rocksdb,berkeleydb,mapdb(当然用户也可以实现扩展接口实现自己的FailStore)QueueManager:任务队列,目前提供mysql(推荐)和mongodb两种实现(同样的用户可以自己扩容展示其他的,譬如oracle等),主要存储任务数据和任务执行日志等。
RPC:远程RPC通信框架,目前也支持多种实现,LTS自带有netty和mina,用户可以自行选择,或者自己SPI扩展实现其他的。
NodeGroup:节点组,同一个节点组中的任何节点都是对等的,等效的,对外提供相同的服务。譬如
TaskTracker
中有10个nodeGroup都是send_msg
的节点组,专门执行发送短信的任务。每个节点组中都有一个master节点,这个master节点是由LTS动态选出来的,当一个master节点挂掉之后,LTS会立马选出另外一个master节点,框架提供API监听接口给用户。ClusterName:LTS集群,就如上图所示,整个图就是一个集群,包含LTS的五种节点。