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