TB-schedule的使用

使用方法

• 任务名称：对应调度策略中的任务名称
• 任务处理的SpringBean：对应处理机中的Bean名称
• 心跳频率(秒)／假定服务死亡间隔(秒)：保持默认
• 线程数：处理该任务的线程数，在没有划分多任务项的状况下，多线程是没有意义的，且线程数 大于任务项也是没有意义的。若是要开启多机多线程，必须对数据作任务项过滤
• 处理模式:SLEEP（推荐）、NOSLEEP（单个线程处理完分配到的数据后，马上会从新获取数据）
• 每次获取数据量：子计时单元开始，线程会不断的去获取数据（eachFetchDataNum参数），直到获取不到数据子计时单元才结束
• 每次执行数量：执行机实现IScheduleTaskDealMulti接口时使用，handleTask方法参数arg0的数量（taskTypeInfo中executeNumber）
• 没有数据时休眠时长(秒)：
  未设置开始时间：当获取不到数据时，休眠此时间，再执行获取数据操做
  设置开始时间，未设置结束时间：无效（实际上子计时单元即将中止了）
  设置开始时间，设置结束时间：当获取不到数据时，休眠此时间，再执行获取数据操做
• 每次处理完数据后休眠时间(秒)：子计时单元内，两次获取数据操做间隔（对于总会返回数据的任务，使用这个配置来控制间隔）
• 执行开始时间：子计时任务开始时间
• 执行结束时间：子计时任务结束时间
• 单线程组最大任务项：配置单JVM处理的最大任务项数量，多任务项状况下，可按需限制，通常默认，多执行机会均衡分配（TBScheduleManager的任务调度器使用，未研究过。。）

• 策略名称：策略标示，随意填写
• 任务类型：通常保持默认Schedule
• 任务名称：对应任务栏被调度任务名称
• 任务参数：通常不用，保持空
• 单JVM最大线程组数量：单个JVM容许开启的线程数
• 最大线程组数量：多处理机状况下的线程总数限制（总线程数为2，若是配置任务项的线程为4是没有意义的）
• IP地址(逗号分隔)：如图说明，此处注意多处理机若是没有根据任务项划分数据处理，会致使多处理机重复处理数据

TBScheduleProcessorSleep多线程工做原理

启动task配置的threadNum数量的线程去处理任务。由其中一个线程去获取任务并放入taskList队列中，全部的线程从这个队列中获取任务执行。若是是Multi任务，能够一次取多个任务执行。在一个线程获取任务的过程当中，其余线程处于休眠状态，任务获取完毕唤醒其余线程。

• TBScheduleProcessorSleep#loadScheduleData
• IScheduleTaskDeal#selectTasks，由此方法的实现返回获取的任务
• 两次loadScheduleData之间有休眠，即在task上配置的SleepTimeInterval（每次处理完数据后休眠时间）
• 一旦TBScheduleProcessorSleep启动了，会一直循环执行，直到PauseTimer让其中止。但若是没有配置结束时间，则一直运行。（对于运行间隔较短的任务，应经过上述休眠时间来实现控制）

注意事项

• 计划任务开始／恢复的时候Factory会建立TBScheduleProcessorSleep、TBScheduleProcessorNotSleep对象；计划中止的时候，会将已经在执行的任务处理完，可是缓存在队列中带执行的任务将被丢弃
• IScheduleTaskDealSingle和IScheduleTaskDealMulti两个接口，除了execute方法上参数不一样，功能上没有区别
• 处理模式为Sleep下getComparator()没有做用，通常状况下，使用Sleep模式

原理

zk数据的大体结构

factory部分：

/rootPath/factory
/rootPath/factory/facotoryUUID1
/rootPath/strategy
/rootPath/strategy/strategy1
/rootPath/strategy/strategy1/factoryUUID1

• factory（永久节点）存储执行机注册的主机信息，每一个执行机启动后，都会在factory下建立一个临时顺序子节点，该节点名是由TBSchedule源码生成的主机惟一标示。每一个factory对应一个执行机启动的TBScheduleManagerFactory实例，每一个JVM能够有多个factory实例，factory实例也能够存在于不一样的JVM中。（通常一个JVM对应一个factory，即任务执行终端）
• strategy（永久节点）是在调度机配置的任务策略，每一个factory启动时候回去检查本身能处理哪几个strategy，若是能处理则在/rootPath/strategy/strategy1/路径下注册本身，注册的这个信息在tbschedule源码里叫作FactoryRunningInfo。

调度配置为永久节点

[zk: 172.26.50.86:2181(CONNECTED) 56] get /rootPath/strategy/IScheduleTaskDealSingleTest
{"strategyName":"IScheduleTaskDealSingleTest","IPList":["127.0.0.1"],"numOfSingleServer":0,"assignNum":1,"kind":"Schedule","taskName":"IScheduleTaskDealSingleTest","taskParameter":"0","sts":"resume"}

[zk: 172.26.50.86:2181(CONNECTED) 57] get /rootPath/strategy/IScheduleTaskDealSingleTest/127.0.0.1$IAN$7D3122FC0C574603B6CFD0C146641A77$0000000000
{"strategyName":"IScheduleTaskDealSingleTest","uuid":"127.0.0.1$IAN$7D3122FC0C574603B6CFD0C146641A77$0000000000","requestNum":1,"currentNum":0,"message":""}

ScheduleServer部分：

/rootPath/baseTaskType
/rootPath/baseTaskType/task1
/rootPath/baseTaskType/task1/task1
/rootPath/baseTaskType/task1/task1/server
/rootPath/baseTaskType/task1/task1/server/scheduleServerUUID1
/rootPath/baseTaskType/task1/task1/taskItem
/rootPath/baseTaskType/task1/task1/taskItem/0
/rootPath/baseTaskType/task1/task1/taskItem/0/cur_server
/rootPath/baseTaskType/task1/task1/taskItem/0/deal_desc
/rootPath/baseTaskType/task1/task1/taskItem/0/parameter
/rootPath/baseTaskType/task1/task1/taskItem/0/req_server
/rootPath/baseTaskType/task1/task1/taskItem/0/sts

• baseTaskType（永久节点）存储调度机建立的任务信息

例如：task1是在后台配置的任务。
/rootPath/baseTaskType/task1/task1/server/scheduleServerUUID1表示能够用来处理任务的调度器，每一个factory实例能够有多个ScheduleServer实例。
/rootPath/baseTaskType/task1/task1/taskItem表示配置任务时，每一个任务能够拆分红几个小的任务项。该节点的子节点，表示这个任务项运行时的信息，例如cur_server表示这个taskItem正在被哪一个ScheduleServer处理。这些在tbschedule源码里也叫做runningInfo。

任务配置为永久节点

[zk: 172.26.50.86:2181(CONNECTED) 37] ls /rootPath/baseTaskType
[IScheduleTaskDealSingleTest]

[zk: 172.26.50.86:2181(CONNECTED) 39] get /rootPath/baseTaskType/IScheduleTaskDealSingleTest
{"baseTaskType":"IScheduleTaskDealSingleTest","heartBeatRate":5000,"judgeDeadInterval":60000,"sleepTimeNoData":500,"sleepTimeInterval":0,"fetchDataNumber":500,"executeNumber":1,"threadNumber":1,"processorType":"SLEEP","permitRunStartTime":"0 * * * * ?","expireOwnSignInterval":1.0,"dealBeanName":"iScheduleTaskDealSingleTest","taskParameter":"0","taskKind":"static","taskItems":["0"],"maxTaskItemsOfOneThreadGroup":0,"version":0,"sts":"resume"}

核心类图

TBScheduleManagerFactoryfactory 实例对象，管理这个factory内部全部的事情。
ZKManager 负责与zk之间的链接，数据交换。
IScheduleDataManager 负责/rootPath/baseTaskType及其子节点全部数据模型维护。
ScheduleDataManger4ZK 负责/rootPath/factory、/rootPath/strategy及其字节点数据模型维护。
IStrategyTask 每一个实例表明一个线程组，每一个strategy可对应多个IStrategyTask实例，来真正处理配置的任务。

类之间的关系图：

Factory 任务处理器（能够理解为JVM）
strategy 为配置的任务

一个Factory处理多个strategy，每一个strategy下有多个IStrategyTask对象。
TBScheduleManager实现IStrategyTask接口，一个TBScheduleManager实例与ScheduleServer、IScheduleProcessor、IScheduleTaskDeal是一对一关系。
ScheduleServer是针对某个task的调度器
IScheduleProcessor是处理任务的多线程任务处理器，控制咱们任务数据的循环执行（有TBScheduleProcessorSleep、TBScheduleProcessorNotSleep两种实现）
IScheduleTaskDeal是咱们须要实现的任务对象（架构组提供的AbstractTaskDealSingle、AbstractTaskDealMulti为其abstract实现）

参考文章

http://www.jianshu.com/p/e925...
http://blog.csdn.net/taosir_z...