分布式任务调度框架，主要是为了协调多节点处理相同任务的避免数据被重复处理的框架，处理方式主要分为“抢占式”和“协同分配式”，通过集群的节点分担大批量任务的处理，提高批量任务的处理效率。

不同处理方式的任务的侧重点不同：

“抢占式”：没法把单个任务的数据，让其它节点协同处理，所以一般来说抢占式任务处理方式一般用于处理数据量比较小，任务比较多的场景；

“协同分配式”：处理可以把单个任务处理的数据均分到多个jvm中进行处理的，提高数据的并行处理能力。

常用解决方案:

“抢占式”：Quartz集群

Quartz主要以job为单位，默认的job存储使用RAMJobStore作为此存储一旦，此种job存储方式，当把job加载到内存中当jvm挂掉或者容器关闭所有存储的job也随之消失，此种方式依赖单个jvm，存在单点，扩展差，容错差等问题，所以Quartz集群一般使用JobStoreTX通过jdbc把job存储在数据库中。Quartz集群通过访问数据库，以抢占的方式，由唯一节点获取到需要执行job，完成job执行。

“协同分配式”：TBSchedule

tbschedule的目的是让一种批量任务或者不断变化的任务，能够被动态的分配到多个主机的JVM中，不同的线程组中并行执行。所有的任务能够被不重复，不遗漏的快速处理。这种框架item的分配实现了数据的不重复，又通过架构中lead的选择，存活的自我保证，完成了可用性和伸缩性的保障。

使用TBSchedule的经验分享

1、了解TBSchedule的主要结构

TBScheduleManager：

管理一组处理线程，是任务分配中作为一个分配单元存在，在不同的JVM中可以存在处理相同处理任务的Manager。

向注册中心更新服务状态，通过心跳的方式。向注册中心获取所有服务的状态重新计算分配任务，避免单点。没批次任务执行完成后重新获取执行任务的范围。

ScheduleTaskType

任务类型，任务心跳频率，一次任务执行完后的休眠时间，执行线程数等，任务相关的信息

ScheduleStrategy

任务的调度策略，指定要执行此任务的节点数，执行任务的节点ip列表

ITScheduleProcessor

在TBScheduleManager的管理下实现消费线程的多线程协同处理

ITScheduleTaskDeal

任务处理的最小单元包括任务的查询和处理，由ITScheduleProcessor调用线程组空闲的一个线程方法selectTasks获取到需要消费的任务列表。然后所有线程根据领用消费方式处理列表中任务。

2、TBSchedule启动流程，以及在中心的注册数据

3、TBSchedule正常使用

可以通过http://code.taobao.org/p/tbschedule/src/官方给出的代码查看

4、TBSchedule扩展开发

tbSchedule除了作为分布式任务架构解决动态的批量任务的分布式执行，同时可以通过一定的修改取代crontab等定时任务工具，达到定时任务的执行的高可用性和不重复性，从而加强小任务的执行效率，和可用性扩大整个框架的适用范围。

此处就是关于自己的一些修改经验，同时可以根据需要重写部分代码，完成针对不同数据源，不同分组的任务。

扩展1：相同任务规则，部分属性不同

1、从之前的启动流程可以看出，一个处理单元主要由分配策略（ScheduleStrategy

），任务类型（ScheduleTaskType）组成，以及处理单元（ITScheduleTaskDeal），

长期使用来看，大多数配置都是重复的，所以首先想到的是做一个抽象的处理单元，包括功能的分配策略和任务类型再在此基础上进行个性设置。

所以创建类：

2、在配置中进行通用的配置

3、并在后续具体配置中实现个性化

如何在不同的数据源或者分组中使用相同的处理逻辑，例如多地点部署，统一汇总报表的仓储系统。

因为处理的任务基本相同只有部分属性不同，如果正常需要配置大量的task不便于管理。所以在原有的代码的基础上通过cglib重写任务类，重新在调度中心注册任务。

工作中每天统计工作kpi等效率报表等用到过：

1）根据上面自定扩展的方式定义了多个执行任务

2）具体任务类定义（获取需要处理的任务列表，执行单个任务）

扩展2：分布式定时任务

详细了解tb流程后知道ITScheduleTaskDeal作为最小处理单元，在processor中获取任务列表时只有一个 ITScheduleTaskDeal被调用。符合不重复调用的要求，并且拥有框架数据分片的特性，所以可以作为定时任务的执行单元加以利用。

因此进行了如下改造：

实际应用：每十秒去缓存中得到最新的位置信息，比对后发送相应通知。

本文作者：刘凯毅（点融黑帮），就职于点融成都团队，workflow/crc team，主要从事j2ee方向的开发工作，对代码优化，和分布式的一些处理方案有了一定的了解。