java分布式定时任务对比学习

【引言】

上篇博客，使用xxl-job分布式定时任务框架简单实现了一个demo实例，而java实现分布式定时任务远不止这一个框架，所以，本篇博客的主要内容是将java的几个分布式定时任务框架做个对比总结。

【框架列举】

单机

1. timer：是一个定时器类，通过该类可以为指定的定时任务进行配置。TimerTask类是一个定时任务类，该类实现了Runnable接口，缺点异常未检查会中止线程
2. ScheduledExecutorService：相对延迟或者周期作为定时任务调度，缺点没有绝对的日期或者时间
3. spring定时框架：配置简单功能较多，如果系统使用单机的话可以优先考虑spring定时器

分布

1. Quartz：Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能
2. Spring batch：轻量级的，完全面向Spring的批处理框架，可以应用于企业级大量的数据处理系统。Spring Batch以POJO和Spring框架为基础，使开发者更容易的访问和利用企业级服务。Spring Batch可以提供大量的，可重复的数据处理功能，包括日志记录/跟踪，事务管理，作业处理统计工作重新启动、跳过，和资源管理等重要功能。
3. TBSchedule：阿里早期开源的分布式任务调度系统。使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式。文档缺失比较严重。
4. elastic-job：当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，目前是版本2.15，并且可以支持云开发
5. xxl-job: 是大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

【框架对比】

下面主要将xxl-job和elastic-job进行简单对比。

公司

     x-job：个人，大众点评公司员工许雪里，贡献者3人；

     e-job：当当网开源，贡献者17人；

支持集群部署

     x-job：保证每个集群节点配置（db和登陆账号等）保持一致。调度中心通过db配置区分不同集群。执行器支持集群部署，提升调度系统可用性，同时提升任务处理能力。集群部署唯一要求为：保证集群中每个执行器的配置项 “xxl.job.admin.addresses/调度中心地址” 保持一致，执行器根据该配置进行执行器自动注册等操作。

    e-job：重写Quartz基于数据库的分布式功能，用Zookeeper实现注册中心。作业注册中心： 基于Zookeeper和其客户端Curator实现的全局作业注册控制中心。用于注册，控制和协调分布式作业执行。

多节点部署时任务不能重复执行

    x-job：使用Quartz基于数据库的分布式功能

    e-job：将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片。

日志

    x-job：支持日志可追溯，有日志查询界面

    e-job：可通过事件订阅的方式处理调度过程的重要事件，用于查询、统计和监控。Elastic-Job目前提供了基于关系型数据库两种事件订阅方式记录事件

监控报警

    x-job：调度失败时，将会触发失败报警，如发送报警邮件。任务调度失败时邮件通知的邮箱地址，支持配置多邮箱地址，配置多个邮箱地址时用逗号分隔

    e-job：通过事件订阅方式可自行实现

弹性扩容缩容

    x-job：使用Quartz基于数据库的分布式功能，服务器超出一定数量会给数据库造成一定的压力

    e-job：通过zk实现各服务的注册、控制及协调

支持并行调度

     x-job：调度系统多线程（默认10个线程）触发调度运行，确保调度精确执行，不被堵塞

     e-job：采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项

高可用策略

    x-job：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行

    e-job：调度器的高可用是通过运行几个指向同一个ZooKeeper集群的Elastic-Job-Cloud-Scheduler实例来实现的。ZooKeeper用于在当前主Elastic-Job-Cloud-Scheduler实例失败的情况下执行领导者选举。通过至少两个调度器实例来构成集群，集群中只有一个调度器实例提供服务，其他实例处于”待命”状态。当该实例失败时，集群会选举剩余实例中的一个来继续提供服务

失败处理策略

     x-job：调度失败时的处理策略，策略包括：失败告警（默认）、失败重试

     e-job：弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样失效转移功能也会牺牲部分性能

【对比总结】

共同点

x-Job和e-job都有广泛的用户基础和完整的技术文档，都能满足定时任务的基本功能需求。

不同点

    x-Job 侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用

    e-Job 关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用

【学习总结】

考虑公司项目进度，优先选择了学习成本较低的x-job，对比总结是学习x-job的一个基石，有了宏观认识，才能更好地深入。