分布式定时任务设计及其框架

在很多应用系统中，我们常常要定时或周期性执行一些任务。比如，订单系统的超时状态判断、缓存数据的定时更新、定时给用户发邮件，甚至是一些定期计算的报表等。单机程序中常见的处理方式有线程的 while(true) 和 sleep 组合，使用定时器触发任务。

1、为什么需要分布式定时任务

• 高可用：单机版的定时任务调度只能在一台机器上运行，如果程序或者系统出现异常，就会导致功能不可用。

• 多任务管理复杂：一个系统可能会有很多需要定时执行的任务。当出现单机无法承载所有的任务时，一般会简单地进行拆分，让不同的机器各自承担一定数量的任务。在这种方式下，需要由开发人员人工管理和分配各个机器上所负责运行的任务。并且可能因为人工分配的不合理而造成系统负载不均。

• 单机处理极限：原本 1min 内需要处理 1 万个订单，但是现在需要 1min 内处理 10 万个订单；原来一个统计需要 1h，现在业务方需要 10min 就统计出来。虽然我们也可以采用多线程、单机多进程处理等方式提高单位时间的处理效率，但是单机能力毕竟有限（主要是 CPU、内存和磁盘），始终会有单机处理不过来的情况。

2、分布式定时任务设计思路

分布式定时任务是把分散的、可靠性差的计划任务纳入统一的平台，并实现集群管理调度和分布式部署的一种定时任务的管理方式。

核心设计思路基本都是将“调度”和“任务”两部分解耦。任务节点是分布式部署的，通过特定的均衡调度算法触发指定节点上的任务执行，如果节点任务运行异常就会被自动调度到其他节点重试，以提高系统整体稳定性和可扩展性。

• 调度模块（调度中心）： 负责管理调度信息，按照调度配置发出调度请求，自身不承担业务执行。调度系统与任务解耦，提高了系统可用性和稳定性，同时调度系统性能不再受限于任务模块；支持可视化、简单且动态的调度信息管理，包括任务新建、更新、删除、调度运行和任务告警等。所有上述操作都会实时生效，同时支持监控调度结果以及执行日志，支持执行器故障转移。

• 执行模块（执行器）：负责接收调度请求并执行任务的业务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效；任务一般是“无状态”的，在任何一个节点运行都可以。执行模块接收调度中心的执行请求、终止请求和日志请求等。

3、分布式定时任务框架

• Quartz 是 Java 领域著名的开源任务调度工具，是开源组织 OpenSymphony 在 Jobscheduling 领域的一个开源项目。Quartz 完全由 Java 编写而成，可以很方便地和 Java 的另一个框架 Spring 集成。支持丰富多样的调度方法，可以满足各种常规及特殊需求。支持任务和调度的多种组合方式，支持调度数据的多种存储方式。支持分布式和集群能力，负载均衡和高可用性。

• Elastic-job 是当当网开发的弹性分布式任务调度系统，功能丰富强大。由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。Elastic-Job-Lite 定位为轻量级无中心化解决方案，使用 jar 包的形式提供分布式任务的协调服务；Elastic-Job-Cloud 采用自研 Mesos Framework 的解决方案，额外提供资源治理、应用分发以及进程隔离等功能。Elastic-job 采用去中心化设计，主要分为注册中心、数据分片、分布式协调、定时任务处理和定制化流程型任务等模块。

• TBSchedule 是淘宝早期开源的分布式调度框架，基于 ZooKeeper 的纯 Java 实现。其目的是让一种批量任务或者不断变化的任务，能够被动态地分配到多个主机的 JVM 中的不同线程组中并行执行。所有的任务能够被不重复、无遗漏地快速处理。这种框架任务的分配通过分片实现了无重复调度，又通过架构中 Leader 的选择，存活的自我保证，提供了可用性和可伸缩性的保障。

• SchedulerX 是阿里云基于 Akka 架构自研的新一代功能强大、成熟稳定的分布式任务调度平台。SchedulerX 为用户提供各种各样精确到秒级的高可用的任务调度服务，每日精准触发调度万亿次，允许用户配置任意周期性调度的单机或者分布式任务，提供精准、高可靠的定时任务触发，上百万超大规模任务高效并发处理和均衡调度。