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

原创
2016/03/14 10:38
阅读数 1.5K

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

问题描述

非常简单的定时调度任务,只是定时触发执行任务,这个任务量是非常少的,单机实现就可以的任务,这种场景使用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个调度管理器,因此调度管理器的数量受实现配置的队列数的约束,当我们在生产环境遇到任务量骤然增加的情况(比如电商系统的双十一、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


展开阅读全文
加载中
点击加入讨论🔥(5) 发布并加入讨论🔥
打赏
5 评论
1 收藏
1
分享
返回顶部
顶部