从定时器的选型，到透过源码看XXL-Job（上）

此内容来自一位好朋友的分享，也是当初建议我写博客提升的朋友。内容只做转载，未做修改。

定时任务选型

背景

　　目前项目定时任务采用Spring Task实现，随着项目需求的迭代，新增的定时任务也越来越多。我们也即将面临如下

问题：

• 任务维护管理（不够直观，不方便管理）

• 单机事故 （故障）

• 任务调度混乱（串行，并行。串行可能阻塞）

那么，我们的需求是什么？

• 图形化管理
• 支持集群，甚至分布式
• 任务调度灵活

选型

　　重点看了几个目前比较流行的框架：

• quartz
• xxl-job
• elastic-job
• saturn

　　豪不夸张的说，java技术栈中的定时任务框架有两种: quartz 和 其它。

Quartz

　　quartz是一个基于数据库的调度框架。支持集群，调度灵活。

缺点：

• 无图形化界面，只提供了API，不方便管理
• 通过抢占数据库锁来防止多个节点执行同个任务。这也意味着当存在过多节点，任务多且执行频繁的时候可能会有性能问题。

xxl-job

　　xxl-job是一款基于quartz封装框架。相比quartz, 其支持友好的图形化界面，功能更为强大。

特色功能：

• 调度器与执行器分离设计
• 支持集群，支持分布式（通过分片可完美支持）
• 任务管理灵活、强大（调度器管理页面可直接写源码）
• 多语言支持
• 调度日志及执行日志
• 负载均衡
• 故障转移、失败重试
• 全异步，更轻量
• 线程隔离（快、慢线程池）

缺点：

• 抢占锁问题

Elastic-job-lite

　　elastic-job也是一款基于quartz封装的框架。对比xxl-job， 两者设计上完全不同，xxl-job为中心化设计，通过调度中心下发调度指令给执行中心。而elastic-job则为无中心化设计。

特色功能：

• 无中心化设计
• 解决了quartz的抢占数据库锁问题，改为了zookeeper。
• 分片功能强大（整体都倾向于分片设计）

缺点：

• 引入分片机制后，会引入更多复杂的问题，例如拿到分片的机器执行失败怎么处理等，目前还不是很完善
• 引入注册中心zookeeper。 比较重，还要考虑zookeeper集群

Saturn

　　saturn 是基于elastic-job-lite的封装，整体特性与elastic-job-lite相似。故不作具体描述。

对比

以上，分别简述了各个框架，接下来，来个更为直观的表格：