余昭辉：去哪儿网任务调度中心

在大型系统中，任务调度是一项基础性的需求。对于一些需要重复、定时执行或者耗时比较长的任务经常会被剥离出来单独处理，而随着任务规模与复杂性的上升，任务调度系统也就随需而生。设计良好的任务调度系统具备可靠性及伸缩性，它可以管理并监控任务的执行流程，以保证任务的正确执行。去哪儿网的工程师余昭辉曾参与开发了去哪儿网的任务调度中心基础组件，InfoQ 就任务调度中心对他进行了采访。

InfoQ：请您介绍下去哪儿网的任务调度中心。

余昭辉：一般在交易系统中会存在各种各样的后台任务，有的可能是定时运行，有的就是一直在幕后默默执行。比如每间隔一段时间我们需要两个系统之间进行对账，每天某个固定时刻我们开始发起所有符合条件的退款操作等等。原先我们的各种后台都是由自行开发，有的使用开源的 Quartz，有的就直接使用 java 自带的线程池等。使用这些方式在早期可以很快的满足我们的需求，但是随着系统越来越庞大，大量的后台任务越来越难以管理和维护。第一个是缺少一个集中的管理方式，可以以很好的可视化的方式监视所有任务的执行状态，跟踪任务的执行历史。第二是大部分任务都存在单点问题 (因为很多任务同时只能有一个实例运行，简单的实现方式难以做到分布式)。还有其他一些各方面的小问题，促使自己开发一个分布式的任务调度系统来解决这些问题。首先我们开发的这个系统应该能够记录下任务的所有执行记录，当出现问题的时候我们可以很容易的追踪任务的历史执行轨迹。我们还要集中的管理所有任务，即使一个新人也可以立即知晓我们的系统中有多少任务在运行。最后，我们我们要能让执行任务的应用多台部署，但又要保证只有单个实例在运行。

在技术方面，我们的任务调度中心使用 Zookeeper 来实现任务调度中心集群的 failover。执行任务应用机器的上下线也是通过 Zookeeper 来实现的。任务执行过程中所生成的日志通过 Alibaba 开源的 Dubbo 汇集到中心，然后存储在 HBase 里备查。任务中心和执行任务的应用之间会传递心跳信息，通过心跳信息不断地交换当前正在执行的任务的执行状态。

InfoQ：我们都知道，Quartz 是一个使用 Java 语言编写的开源的作业调度框架，发展也相对比较成熟，去哪儿网的调度中心是基于 Quartz 么？

余昭辉：我们的调度中心没有基于 Quartz，在调度方面是完全自己开发的。当时开发的时候确实有想过是不是直接使用 Quartz，但是最后看 Quartz 的代码发现代码量真不少。Quartz 提供了很多非常丰富的特性，很多特性我觉得并不是我们所需要的，所以我不愿意承担这个复杂性。最后开发完也证明了这一点，任务调度的地方并没有多少代码量，因为自己写也更熟悉，也可以更好的利用公司现有的一些框架类库。我们的任务调度中心支持 Cron Expression，执行任务的应用也支持集群部署。提供了多种错误恢复和报警策略，可以由业务自行选择。

InfoQ：第三方应用是如何接入任务调度中心的？任务调度中心和应用之间是如何通讯的？

余昭辉：在使用上我们的任务中心还是挺方便的。因为我们公司大部分 Java 项目都是基于 Spring 的，所以我们提供了自定义的 Annotation，只需要在你想调度的方法上标记该 Annotation，任务就可以自动注册到任务中心里，然后就可以在任务中心的管理后台进行各种参数配置和监控。

任务中心与执行任务的应用之间是通过发消息通信的，这里使用了我们团队自己开发的一个可靠消息中间件。第三方应用作为消息的消费者。任务中心负责调度，当要开始调度一个任务的时候，就往这个应用发送一条消息，第三方应用收到消息后就开始执行任务。

InfoQ：调度中心是否支持开始 / 暂停任务以及修改任务的执行时间？

余昭辉：调度中心支持任务的开始和修改任务的执行时间的，但是不支持将一个正在运行的任务暂停下来，主要是我们觉得安全地暂停正在执行的任务还是挺困难的，不是任务中心提供了这个功能，这个任务就可以暂停，还需要执行任务的应用配合，如果一旦误用可能还会带来很多其他问题，所以我们没有提供这个功能。

InfoQ：任务调度中心是否支持负载均衡，如何实现的？

余昭辉：我们默认使用的是随机的负载均衡策略。为了实现高可用，任务调度中心自身也是一个集群，前面也提到执行任务的应用也是集群，而且要保证一个任务同一时刻只有一个实例在运行。当时实现这块儿想到两个方案，一个就是去中心化。任务中心集群的每个节点都可以进度调度，通过协调保证每个任务只有单实例运行。但是这种实现方式虽然看起来很好，但实现还是非常复杂，定位问题也很困难。最后我们选择了中心化的策略。我们利用 Zookeeper 的选举机制，在任务中心集群里选出一个 Leader 节点进行任务调度，而其他节点负责心跳跟踪，日志汇总等。当任务调度的节点出现故障，我们可以快速的 failover 到其他节点上。这样一来整个实现方案就简单得多了，到现在运行有半年多时间，总共有上千的任务在上调度一直工作良好。

但这也是这个任务中心最大的缺陷，可能未来某天单个节点难以承载这么大的任务量 (其实任务调度也就是要在内存里维护任务的一些元素据信息，而这些信息都不大，我计算了一下，要超过单个节点的容量任务至少要到 10 万级)，如果到这个时候我们计划 Leader 节点不再进行任务调度，只进行任务分发。就像发扑克牌一样，这个周期内这个任务发给这个节点了就一直由这个节点进行调度。但是整个架构我还是更青睐中心化的方案。