taobao-pamirs-schedule2.0设计和实现的局限性

不适合简单的少许任务调度

问题描述

很是简单的定时调度任务，只是定时触发执行任务，这个任务量是很是少的，单机实现就能够的任务，这种场景使用taobao-pamirs-schedule就会存在开发、配置和使用很是繁琐的问题，须要不少的配置、编写更多的代码大，产生更多的对象和线程，这是很是不适合的。

解决方案

请根据具体使用场景选择本产品，大批量任务须要处理的场景才选择使用taobao-pamirs-schedule。少许任务定时调度的场景请使用Timer，Spring调度等简单的调度解决方案，若是要实现多实例的高可用，能够经过分布式锁来实现（好比redis，zookeeper等都可以实现）。

强依赖Spring

问题描述

该项目是强依赖Spring容器的，并且依赖的是Spring2.5.6.SEC02的版本。这样可能会跟集成应用自己的版本冲突。而且它的类TBScheduleManagerFactory是实现了Spring的接口ApplicationContextAware，所以若使用该工厂则必须在Spring环境下使用淘宝调度2.0.

解决方案

1.只在Spring环境下使用该项目。因为本项目对Spring的依赖较轻，只是依赖一个ApplicationContextAware接口，所以能够在Spring2.5.6以上的环境下都是能够的。

2.在非Spring环境下，能够从新编译该项目，建立一个不依赖于Spring接口的TBScheduleManagerFactory实现类。

调度频繁的场景资源消耗大

问题描述

项目的实现中能够看出调度从新恢复会建立Processor对象，又会建立和启动配置的多个线程，这是一个很是重的操做，当调度暂停后，从新恢复的时候又会从新建立新的对象，那么以前建立的对象和线程都会被销毁，对象和线程没法复用，当咱们的调度在很是频繁的进行恢复和暂停之间切换的时候，会致使大量的对象和线程的建立及销毁，系统各类资源的损耗过大。

解决方案

1.避免配置一个很是短暂的调度启动和恢复间隔。

2.修改源码使得在调度和暂停切换的过程当中能够复用Processor对象。

系统伸缩性受队列数限制

问题描述

淘宝调度的任务队列须要提早配置，系统启动后会将任务队列分配给制定调度管理器，任务队列和调度管理器的关系是1..n：1，也就是一个队列组多只能分配给1个调度管理器，所以调度管理器的数量受实现配置的队列数的约束，当咱们在生产环境遇到任务量骤然增长的状况（好比电商系统的双11、618大促）下，但愿经过扩展机器来提升任务处理能力的时候就没法动态伸缩了。

解决方案

调度器改进：

改进调度的实现，增长动态增长任务队列的管理功能，动态增长后的队列能够分配给新增长的机器。

任务生产者改进：

任务生产者的队列数也应该能够经过管理器动态增长新的队列，生产系统能够动态的向新增长的队列增长任务。

数据库做为配置管理中心性能较差

问题描述

taobao-pamirs-schedule的默认配置管理中心的实现是基于数据库的，因为每一个任务类型都会生成对应的管理器对象，管理器会维持心跳信息，按期的会调用更新信息接口维持本身的服务器心跳信息，还有不少信息的增删改查都会涉及到数据库的操做，而且有些操做还会利用数据库的锁，当服务器数据量较多的状况下，会比较容易出现性能瓶颈。

解决方案

使用其它一些高性能的、高可扩展的配置管理实现方案替代数据库，好比：zookeeper、reddis等实现配置管理器的功能，可以得到更好的性能，支持更高的并发方案。

taobao-pamirs-schedule项目3.0版本目前已经改名为tbschedule，它的配置管理中心的默认实现就是基于zookeeper实现的，项目主页参考：http://code.taobao.org/p/tbschedule/src/

它的基于zookeeper的配合管理中心请查看http://code.taobao.org/p/tbschedule/src/trunk/src/main/java/com/taobao/pamirs/schedule/zk/ScheduleDataManager4ZK.java