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具有很好的容错能力。

架构图

LTS architecture

  • 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的五种节点。

results matching ""

    No results matching ""