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

 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地址：github.com/taobao/TBSc…

3.2 elastic-job

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

（编辑：ASP站长网）