淘宝开源任务调度框架tbschedule

背景

　　分布式任务调度是很是常见的一种应用场景，通常对可用性和性能要求不高的任务，采用单点便可，例如linux的crontab，spring的quarz，可是若是要求部署多个节点，达到高可用的效果，上面的方案就不适用了。

实际上任务调度的实现有两种状况，第一种是经过mq来实现，mq作好了数据切分，负载均衡的效果，本文说的是另外一种状况。

 

 

要求

　　1、不重复

若是只达到这个要求，有不少方法，假设任务处理的是一张表中的数据，那能够根据某个字段取模达到不重复的效果。

2、不遗漏

若是用上面的方案解决了重复的问题，有一个节点挂掉，须要其余节点接管挂掉节点的任务，这就要求分布式任务调度必须有指挥中心，不然很容易形成重复或者遗漏。

 

tbschedule

　　上图是tbschedule的架构图，基本知足了分布式任务调度的要求，zookeeper有两个功能，一个是配置数据存储，另外一个是做为调度中心，管理界面直接链接zookeeper取得配置信息，而且修改配置，经过zookeeper通知任务修改配置项。

要求不高的话能够直接拿来用，虽然文档少，可是代码量不多，能够直接经过读代码了解功能。

tbschedule已经知足了大多数需求，代码写的也很是优秀，可是有几个地方是能够改进的，

一、前面提到的，通常状况下，咱们是不须要多个节点同时工做的，只要有一个节点工做，挂掉其余节点能接替就能够了。由于取数据一般不是性能瓶颈，瓶颈在处理数据，多个节点的目的无非是为了高可用。若是经过sql取模进行分片，sql的性能很是低，走不了索引。若是表数据已经作了水平拆分，那能够直接根据数据源切分任务项。

二、tbschedule是把全部任务都处理完才算结束，可是有些场景要求只执行一次，哪怕还有任务要处理，tbschedule须要增长一个配置项；

三、执行时间修改必须在每一个执行周期后才能生效，这个常常在调试的时候出现麻烦，这样作确实是最简单的作法，避免了不少问题，可是若是开发人员要配置任务每分钟执行一次，结果写错了配置成天天执行一次，就完美的落入陷阱，等半天也看不到执行，还觉得配置错了，重启能够解决；

四、没有负载均衡效果，tbschedule认为每台机器的配置都是同样的，就算配置同样，数据项不同也容易引发其中一个节点压力特别大。须要根据机器的负载状况、程序的繁忙状况作一个加权平均来作负载。