轻量级分布式任务调度框架(一、LTS简介、特点、工作流程)

LTS

轻量级分布式任务调度框架(Light Task Schedule)

LTS简介

LTS(light-task-scheduler)主要用于解决分布式任务调度问题,支持实时任务定时任务Cron任务有较好的伸缩性,扩展性,健壮稳定性而被多家公司使用,同时也希望开源爱好者一起贡献。

LTS框架概况

LTS 四种节点:

  • JobClient:主要负责提交任务, 并接收任务执行反馈结果。

  • JobTracker:负责接收并分配任务,任务调度。

  • TaskTracker:负责执行任务,执行完反馈给JobTracker。

  • LTS-Admin:主要负责节点管理,任务队列管理,监控管理等。
    详解:
    其中JobClient,JobTracker,TaskTracker节点都是无状态的。 可以部署多个动态的进行删减,来实现负载均衡,实现更大的负载量, 并且框架采用FailStore策略使LTS具有很好的容错能力

LTS注册中心提供多种实现(Zookeeper,redis等),注册中心进行节点信息暴露,master选举。(Mongo or Mysql)存储任务队列和任务执行日志, netty or mina做底层通信, 并提供多种序列化方式fastjson, hessian2, java等。

LTS支持任务类型

  • 实时任务:提交了之后立即就要执行的任务。
  • 定时任务:在指定时间点执行的任务,譬如 今天3点执行(单次)。
  • Cron任务:周期性任务,CronExpression,和quartz类似(但是不是使用quartz实现的)譬如 0 0/1 * * * ?

支持动态修改任务参数,任务执行时间等设置,支持后台动态添加任务,支持Cron任务暂停,支持手动停止正在执行的任务(有条件),支持任务的监控统计,支持各个节点的任务执行监控,JVM监控等等.

LTS架构图

轻量级分布式任务调度框架(一、LTS简介、特点、工作流程)
轻量级分布式任务调度框架(一、LTS简介、特点、工作流程)

组件说明:

  1. 节点组

NodeGroup:一个节点组等同于一个小的集群,同一个节点组中的各个节点是对等的,等效的,对外提供相同的服务。

每个节点组中都有一个master节点,这个master节点是由LTS动态选出来的,当一个master节点挂掉之后,LTS会立马选出另外一个master节点,框架提供API监听接口给用户。

  1. FailStore

顾名思义,这个主要是用于失败了存储的,主要用于节点容错,当远程数据交互失败之后,存储在本地,等待远程通信恢复的时候,再将数据提交。

FailStore主要用户JobClient的任务提交,TaskTracker的任务反馈,TaskTracker的业务日志传输的场景下。

FailStore目前提供几种实现:leveldb,rocksdb,berkeleydb,mapdb,ltsdb,用于可以*选择使用哪种,用户也可以采用SPI扩展使用自己的实现。

LTS-Admin新版界面预览

目前后台带有由ztajy提供的一个简易的认证功能. 用户名密码在auth.cfg中,用户自行修改.
轻量级分布式任务调度框架(一、LTS简介、特点、工作流程)

LTS特性


Spring支持

LTS可以完全不用Spring框架,但是考虑到很用用户项目中都是用了Spring框架,所以LTS也提供了对Spring的支持,包括Xml和注解,引入lts-spring.jar即可。


业务日志记录器

在TaskTracker端提供了业务日志记录器,供应用程序使用,通过这个业务日志器,可以将业务日志提交到JobTracker,这些业务日志可以通过任务ID串联起来,可以在LTS-Admin中实时查看任务的执行进度。


SPI扩展支持

SPI扩展可以达到零侵入,只需要实现相应的接口,并实现即可被LTS使用,目前开放出来的扩展接口有对任务队列的扩展,用户可以不选择使用mysql或者mongo作为队列存储,也可以自己实现。对业务日志记录器的扩展,目前主要支持console,mysql,mongo,用户也可以通过扩展选择往其他地方输送日志。


故障转移

当正在执行任务的TaskTracker宕机之后,JobTracker会立马将分配在宕机的TaskTracker的所有任务再分配给其他正常的TaskTracker节点执行。


节点监控

可以对JobTracker,TaskTracker节点进行资源监控,任务监控等,可以实时的在LTS-Admin管理后台查看,进而进行合理的资源调配。


多样化任务执行结果支持

LTS框架提供四种执行结果支持EXECUTE_SUCCESS,EXECUTE_FAILED,EXECUTE_LATER,EXECUTE_EXCEPTION,并对每种结果采取相应的处理机制,譬如重试。

EXECUTE_SUCCESS: 执行成功,这种情况,直接反馈客户端(如果任务被设置了要反馈给客户端)。

EXECUTE_FAILED执行失败,这种情况,直接反馈给客户端,不进行重试。

EXECUTE_LATER稍后执行(需要重试),这种情况,不反馈客户端,重试策略采用1min,2min,3min的策略,默认最大重试次数为10次,用户可以通过参数设置修改这个重试次数。

EXECUTE_EXCEPTION执行异常, 这中情况也会重试(重试策略,同上)


FailStore容错

采用FailStore机制来进行节点容错,Fail And Store,不会因为远程通信的不稳定性而影响当前应用的运行。具体FailStore说明,请参考概念说明中的FailStore说明。


LTS工作流程

下图是一个标准的实时任务执行流程。

轻量级分布式任务调度框架(一、LTS简介、特点、工作流程)

解析:

  1. JobClient 提交一个 任务 给 JobTracker, 这里我提供了两种客户端API, 一种是如果JobTracker 不存在或者提交失败,直接返回提交失败。另一种客户端是重试客户端, 如果提交失败,先存储到本地FailStore(可以使用NFS来达到同个节点组共享leveldb文件的目的,多线程访问,已经做了文件锁处理),返回 给客户端提交成功的信息,待JobTracker可用的时候,再将任务提交。

  2. JobTracker收到JobClient提交来的任务,将任务存入任务队列。JobTracker等待TaskTracker的Pull请求,然后将任务Push给TaskTracker去执行。

  3. TaskTracker收到JobTracker分发来的任务之后,然后从线程池中拿到一个线程去执行。执行完毕之后,再反馈任务执行结果给 JobTracker(成功or 失败[失败有失败错误信息]),如果发现JobTacker不可用,那么存储本地FailStore,等待TaskTracker可用的时候再反馈。反馈 结果的同时,询问JobTacker有没有新的任务要执行。

  4. JobTacker收到TaskTracker节点的任务结果信息。根据任务信息决定要不要反馈给客户端。不需要反馈的直接删除,需要反馈的,直接反馈,反馈失败进入FeedbackQueue, 等待重新反馈。

  5. JobClient收到任务执行结果,进行自己想要的逻辑处理。

上一篇:elasticsearch启动常见错误


下一篇:shell 下执行mysql 命令