如何选型一个合适的框架-分布式任务调度框架选型

1.背景

定时任务是你们再开发中一个不可避免的业务，好比在一些电商系统中可能会定时给用户发送生日券，一些对帐系统中可能会定时去对帐。大概再好久之前每一个服务可能就一台机器，再这台机器上直接搞个Timerschedule基本上就能知足咱们的业务需求，可是随着时代的变迁，单台机器已经远远不能知足咱们的须要，这个时候咱们可能须要10台，20台甚至更多机器来运行咱们的业务，接受咱们的流量，这就是咱们所说的横向扩展。可是这里就有个问题，这么多台机器若是还用咱们的Timerschedule去作会发生什么呢？再上面的电商系统中有可能会给某个用户发不少张生日券，对公司形成不少损失，因此咱们须要一些其余方法，让定时任务在多台机器上只执行一次。

这里想问下你们在没有了解过或使用过度布式任务调度框架以前你们是如何作定时任务的呢？在Spring项目中你们确定都知道Spring-Scheduler，只须要在Spring中的bean的对应方法上加上@Scheduler注解便可完成咱们的定时任务，可是光是用这个注解还远远不能保证定时任务执行屡次，咱们须要一些其余手段的保证，通常来讲方法可能不外乎下面几种（都是基于Spring的项目来讲）：

• 一台机器，咱们能够将一些不过重要的定时任务，可使用一个专门的服务台承载，而后使用单机跑，就算挂了只要咱们再可接受的时间以内将其恢复，咱们的业务也不会受到影响。

• 多台机器，加分布式锁，只要咱们执行任务的时候首先获取一把分布式锁，若是获取失败那么久证实有其余服务已经再运行，若是获取成功那么证实没有服务在运行定时任务，那么就能够执行。

• 多台机器，利用ZooKeeper对Leader机器执行定时任务，有不少业务已经使用了ZK，那么执行定时任务的时候判断本身是不是Leader，若是不是则不执行，若是是则执行业务逻辑，这样也能达到咱们的目的。

目前咱们公司作定时任务也是使用的上面三种方法，在业务初期使用这些方法基本也能大致知足，可是随着时间的迁移，咱们遇到的问题愈来愈多，这里和你们分享一下：

• 首先是单机问题，如何划分一个业务不是很重要，这一块原本就比较复杂，有可能每一个人都说本身的业务都重要，其次是若是单机挂了 这个挂有多是宕机，有多是其余的一些状况，这个时间如何能保证咱们再可接受的范围之间恢复，这些都是难点。
• 目前咱们使用定时任务的时候，若是想让它立刻执行一次，这个时候可能就须要额外再写一个Rest接口或者再另外写一个单独的Job。
• 还有个是咱们须要更改定时任务执行时间，好比如今有个需求是从每12个小时执行一次变成每6小时执行一次，咱们又得修改代码，提交pr，而后打包上线，只是修改一个时间又得花费咱们不少时间。
• 没法暂停咱们的定时任务，当咱们的定时任务可能出现一些问题，好比一些定时报警的需求，当报警忽然变得不少，这个时候须要暂停一下让其中止发送报警，这个时候可能咱们能够用一些分布式配置的开关去作，再逻辑中判判定时任务开关是否打开，而后来作。这样作虽然也比较简单，可是咱们这样须要新添加一些与任务无关的逻辑。
• 缺乏对定时任务的监控，任务失败以后开发人员无从得知，有人说不是有Error日志吗，若是一个Error日志就一次报警那大家的服务能受得了吗，通常来讲连续几回Error才会触发报警，而咱们定时任务的周期性的特性是不容易触发连续的Error。

固然还有一些或多或少的小问题这里就不一一列举了，若是你们有这种经历能够本身慢慢体会发现。

2. 调研的基本原则

上面第一章讲了咱们框架的缘由，不论你要引入或改进什么，都须要缘由，由于作任何事都有成本，我常常看到一些很小的项目就开始搞引入消息队列，或者分布式事务等等，这样作反而是本末倒置，好比可能有一些博客系统就搞个消息队列削峰减流，这样作有可能尚未同步调用来得快。

当咱们有了缘由以后，就能够着手作一些调研或者技术方案的设计。这里我讲一下个人调研框架一些基本原则，若是你们之后有相似的调研框架的需求均可以往这个里面来套。

• 简单-对开发者接入简单，对使用者使用简单。
• 丰富的文档，有不少开源的项目文档少之又少，固然还有一些开源项目只有英文文档，若是你英文不是很行，那可能须要考虑中文居多的文档。
• 有管理界面，很方便执行操做和统计数据。
• 支持主流框架：好比Spring,Springboot等，固然这个至少要支持大家业务中的主流框架。
• 框架轻量级，方便根据本身的需求进行定制化。
• 高性能，高可靠，高可用：不能让框架成为业务中的瓶颈。
• 代码更新频率和社区使用状况：使用的公司越多证实其越受更多人的喜好，代码更新频率越高证实出现问题就会越少，最好是由大厂开源而且维护。
• 多语言需求：若是在大家业务中有多语言需求，好比大家公司用的开发语言不少，都须要调度框架那么你须要使用多语言支持。好比Rpc支持多语言的表明就是Thrift。
• 可否解决当前的痛点：这个是最重要的，若是连你问题都解决不了那使用这个还有什么意义呢？

当咱们有了上述的几大原则以后，咱们接下来能够进入调研。

3.调研框架

3.1 TBSchedule

通常调研Java系的一些框架，能够先看看阿里是否是有开源的，毕竟最近这几年阿里在开源这一块作得是很是的好，再网上搜索到阿里在12年开源了一个调度框架叫TBSchedule，如今再去搜索代码，发现已经人走茶凉，代码都被清理干净了。固然还有一个我的项目将其Fork出来再不断维护，可是使用者实在是少这里就不说明了。 github地址：https://github.com/taobao/TBSchedule

3.2 elastic-job

elastic-Job 是当当开源的一个分布式调度解决方案，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。定位为轻量级无中心化解决方案，使用 jar 包的形式提供分布式任务的协调服务。支持分布式调度协调、弹性扩容缩容、失效转移、错过执行做业重触发、并行调度、自诊断和修复等等功能特性。

这个框架大概在2年前很火，当时使用的公司不少，想必不少人也听过了，可是很惋惜如今已经不在维护了，代码已经有2年没有更新了，这里违反了更新频率的原则，若是出现问题可能都没什么人帮助你，因此咱们并非很推荐使用。 github地址：https://github.com/elasticjob/elastic-job-lite

3.3 一些比较小众的

在网上有一些比较小众的github star不多，更新频率也不多： Uncode-Schedule，LTS,openCron等等，这些也不符合咱们的原则，都不予以考虑

3.4 XXL-JOB

因为分布式定时任务如今尚未基金会好比CNCF,Apache等，抉择起来可能不是那么难。不像消息队列再Apache里面就有好几个:Kafka,rocketmq,plusar等等，每个的社区都很庞大，可能选择是比较困难的。那么咱们基本就还剩下两个选择，一个是自研，这种任务调度框架，再研发的困难程度上是远远比不上消息队列的研发，因此其实不少公司都选择了自研，好比：美团的Crane这些。可是对于一些消息队列这些复杂的中间件可能会选择二次开发，好比美团的mafka就是基于kafka二次开发，滴滴的DDMQ也是基于Rocketmq。而咱们目前若是选择自研再资源上来讲是明显不够的，这里咱们仍是使用的是二次开发框架的策略。

固然这里还剩下一个XXL-Job:http://www.xuxueli.com/xxl-job 的选择，其基本符合咱们的原则，目前代码也在持续更新，issue做者也在积极的回复，使用的公司也有200多家,其中包括以前的点评，同时其余的原则也很符合。通常来讲当你决定选择某个框架的时候须要详细的列举一下优势，好让其余人得以信服。

xxl-job有下面一些特色：

• 简单：支持经过Web页面对任务进行CRUD操做，操做简单，一分钟上手；
• 动态：支持动态修改任务状态、启动/中止任务，以及终止运行中任务，即时生效；
• 调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA；
• 执行器HA（分布式）：任务分布式执行，任务"执行器"支持集群部署，可保证任务执行HA；
• 注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；
• 弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会从新分配任务；
• 路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不常用、最近最久未使用、故障转移、忙碌转移等；
• 故障转移：任务路由策略选择"故障转移"状况下，若是执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。
• 阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖以前调度；
• 事件触发：除了"Cron方式"和"任务依赖方式"触发任务执行以外，支持基于事件的触发任务方式。调度中心提供触发任务单次执行的API服务，可根据业务事件灵活触发。
• 任务进度监控：支持实时监控任务进度；
• Rolling实时日志：支持在线查看调度结果，而且支持以Rolling方式实时查看执行器输出的完整的执行日志

基本上上面的一些特色都是咱们业务中所须要的，因此这里最后选择了XXL-JOB

4.总结

俗话说：授人以鱼不如授人以渔，以前的文章每次都是介绍某某框架，这一次我偏向于介绍我是如何选择的这款框架，让你们再之后调研的过程当中也能够按照这个思路，若是说你也有好的而且不一样的调研思路，欢迎留言或者加群交流。固然通常调研完毕以后，做为一个调研人若是你不弄清楚这个框架的源码和实现原理，那么就是一个不合格的调研人，因此下一篇文章我会详细的介绍XXL-Job的实现原理。

若是你们以为这篇文章对你有帮助，你的关注和转发是对我最大的支持，O(∩_∩)O: