先介绍几种比较主流的。

Elastic-Job,是当当网开源的分布式调度解决方案，支持任务分片功能，可以充分利用资源。Elastic-Job有两个独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。具体实现可以参考官方教程。其整体架构图如下。

Elastic-Job的特点：

1、分布式调度 2、作业高可用 3、任务分片执行。

另外，还有其他的一些框架，可以对比使用。比如TBSchedule是阿里巴巴开源的分布式调度框架，完全由java实现，目前被应用于淘宝，阿里巴巴，支付宝，京东， 汽车 之家等。大众点评开源的xxl-job，也是应用比较广泛的分布式调度任务。

目前我使用过的有 Elastic-Job和xxl-job。两者功能都很强大，后台管理也比较完善。很容易上手。都可以满足日常的工作需要。区别就是 Elastic-Job依赖zk，但是xxl-job不依赖zk，只依赖数据库。

目前市面上应该还有一些其他的框架，但是以上是比较主流的，可以根据自己的需要来选择。切记不要重复造轮子，造轮子需要大量的时间去验证。会让你在坑里爬不出来。

1.XXL-JOB

2.Elastic-Job

Elastic-Job 是一个分布式调度解决方案，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。

定位为轻量级无中心化解决方案，使用 jar 包的形式提供分布式任务的协调服务。

支持分布式调度协调、弹性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复等等功能特性。

分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。

Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。选择该项目可以满足大多数it企业的需求。

Elastic-Job-Cloud使用Mesos + Docker的解决方案，额外提供资源治理、应用分发以及进程隔离等服务。

轻量级无中心化：Elastic-Job-Lite并无作业调度中心节点，而是基于部署作业框架的程序在到达相应时间点时各自触发调度。

灵活的增删改查作业，集中式管理调度作业

支持高可用：一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。开启失效转移功能效果更好，可以保证在本次作业执行时崩溃，备机立即启动替补执行。

支持分片：作业分片一致性，保证同一分片在分布式环境中仅一个执行实例

任务监控：通过监听Elastic-Job-Lite的zookeeper注册中心的几个关键节点即可完成作业运行状态监控功能

一致性：使用zookeeper作为注册中心，为了保证作业的在分布式场景下的一致性，一旦作业与注册中心无法通信，运行中的作业会立刻停止执行，但作业的进程不会退出，这样做的目的是为了防止作业重分片时，将与注册中心失去联系的节点执行的分片分配给另外节点，导致同一分片在两个节点中同时执行。

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

3.opencron

opencron是一个功能完善且通用的开源定时任务调度系统，拥有先进可靠的自动化任务管理调度功能，提供可操作的 web 图形化管理满足多种场景下各种复杂的定时任务调度，同时集成了 linux 实时监控、webssh 等功能特性

4.quartz

支持集群和分布式，但是没有友好的管理界面，功能单一，对于管理调用的任务比较困难。

quartz使用数据库锁。在quartz的集群解决方案里有张表scheduler_locks，quartz采用了悲观锁的方式对triggers表进行行加锁，以保证任务同步的正确性。一旦某一个节点上面的线程获取了该锁，那么这个Job就会在这台机器上被执行，同时这个锁就会被这台机器占用。同时另外一台机器也会想要触发这个任务，但是锁已经被占用了，就只能等待，直到这个锁被释放。

quartz的分布式调度策略是以数据库为边界资源的一种异步策略。各个调度器都遵守一个基于数据库锁的操作规则从而保证了操作的唯一性。同时多个节点的异步运行保证了服务的可靠。但这种策略有自己的局限性：集群特性对于高CPU使用率的任务效果很好，但是对于大量的短任务，各个节点都会抢占数据库锁，这样就出现大量的线程等待资源。这种情况随着节点的增加会越来越严重。

缺点：quartz的分布式只是解决了高可用的问题，并没有解决任务分片的问题，还是会有单机处理的极限。

5.Saturn

Saturn

基于当当Elastic Job代码基础上自主研发的任务调度系统，是唯品会开源的分布式作业调度平台，取代传统的Linux Cron/Spring Batch Job的方式，做到统一配置，统一监控，任务高可用以及分片并发处理。主要是去中心化，高可用，可分片，动态扩容，有认证和授权功能。

主要特性

支持多种语言作业，语言无关(Java/Go/C++/PHP/Python/Ruby/shell)

支持秒级调度

支持作业分片并行执行

支持依赖作业串行执行

支持作业高可用和智能负载均衡

支持异常检测和自动失败转移

支持异地容灾

支持多个集群部署

支持跨机房区域部署

支持弹性动态扩容

支持优先级和权重设置

支持docker容器，容器化友好

支持cron时间表达式

支持多个时间段暂停执行控制

支持超时告警和超时强杀控制

支持灰度发布

支持异常、超时和无法高可用作业监控告警和简易的故障排除

支持失败率最高、最活跃和负荷最重的各域各节点TOP10的作业统计

优点：源码清晰，学习入手容易。应用部署简单，提供运维控制台，集中管理作业，运维控制台功能强大，提供作业统计报表 ，告警，增删改查作业，作业统一配置。

最后一个是国内团队封装的

前端时间研究了两款分布式任务调度框架，一个是XXL-Job，现在非常主流，很多常见的一些公司都在使用，像滴滴美团这样的公司都在用，这也是一款开源产品，下载下来导入IDEA就可以使用，分调度器和执行器和管理UI，有很美观的UI界面，可以对任务做增删改查，以及支持自定义开发，有很详细的帮助文档，还提供有demo，傻瓜式的，很简单，亮点是提供了管理界面。

另一个是Quartz，这个组件单机和集群都支持，单机的话是RAMJobStore任务存储，而要支持集群的话，就要将配置改成数据库方式，Quartz提供的有十几张表，其分布式的原理是利用了数据库的行锁，Quartz很简单，也是一款轻量级的开源产品，我们公司一直用这款组件，很成熟无Bug，推荐使用！

springcloudtask，springclouddataflow，正在学习中

笔者认为有以下几个方面：

一、 RoR的推波助澜

笔者认为，Ruby的成功，很大一部分是由于RoR的带动。

几年前，如果你没听过RoR倒是情有可原，但如果今天，RoR对你来说，还是一个陌生词汇的话，那你就有点危险了。:)

什么是RoR呢？

全称，Ruby on Rails，简称，RoR或者Rails。

它是个全栈的（full-stack）web应用框架，它为开发者提供了构建一个web应用所需的完整基础结构，并且严格按照MVC（模型-视图-控制器）架构进行开发。

RoR致力于提高开发者的开发效率，希望通过尽量少的代码，完成尽可能多的功能。基于这样的考虑，RoR有两大设计原则，一是，不要重复自己 （Don''t Repeat Yourself）；二是，惯例优于配置（Convention Over Configuration）。

使用RoR，你甚至可以通过简单的几条命令行、几行代码，就完成一个功能强大的web应用程序，这极大地提高了开发者的开发效率。

2004年7月，RoR一经发布，在短期内，便受到很多开发者的追捧。时至今日，RoR已经被全世界的开发者们所关注，它带给开发者的效率提升，是前所未有的；它带给业界关于软件开发的思考，也是意义深远的。

在RoR如此风行的大背景下，Ruby on Rails，这个需要使用Ruby进行开发的web框架，也自然地带动了Ruby语言的发展。

在下面的“Ruby语言受关注程度趋势图”上，可以清晰地看出，Ruby语言在RoR发布也就是2004年7月后，进入了高速发展期。

Ruby因为有了RoR这样的“杀手级”应用，变得春风得意，那么Python呢？

在《浅谈Python语言》一文中，我们提到了Python具有丰富的API库，在web开发方面，也有Django、Turbogears这样的一些框架，就运行速度而言，

Python比Ruby快；就社区而言，Python也比Ruby成熟，可是为什么Python没有产生一个像RoR这样的“杀手级”应用呢？

Python语言的创始人Guido在接受InfoQ采访时，是这样解释的：

“我不喜欢Killer

Application，因为那会让多数人或者社区将精力集中于一个地方。Python是一个应用广泛的语言，基于Python已经产生了很多好用的

Web框架，比如Django等。但是Python不Killer

Application，至少目前是这样，而且我相信随着Python社区的发展，会有很多Killer

Applications自然出现。我喜欢多样化的应用。”

通过这个观点，我们可以看出Python在其发展道路上，追求的是一种均衡，一种“大而全”。

“会有很多Killer Applications自然出现”，这点，我想我们需要拭目以待。单就“均衡”而言，笔者认为这很危险，作为一门脚本语言，试图做Java之类传统语言做的事情，不太可取。

以Java为例，在web应用上，有太多的框架可供选择，不错，“在不同的场景用不同的框架”，这想法很好。可是，在实际应用中，有多少开发者可以根据项目特点，正确、合理地选择框架？

与其到最后，用户还不知道该如何选择，还不如一开始就替用户做出一个选择。

作为Python的使用者，我更愿看到有个Python的“杀手级”应用出现，进而带动Python更快速地发展。

你可以说RoR成就了Ruby，可是Rails为什么偏偏选择了Ruby？！Ruby优势何在？

二、 Ruby的优势

1. 比Perl更强大，比Python更面向对象

“比Perl更强大，比Python更面向对象”，这是Ruby创始人Matz设计Ruby的初衷。

Python既支持面向过程的编程也支持面向对象的编程，而Ruby则是完全面向对象。

在Ruby中，任何东西都是对象，包括Python中的基本数据类型；每个过程或函数都是方法。

例如，取-3的绝对值，在Python中，是这样的：abs(-3)。

而在Ruby中，则是这样的：-3.abs。这种OO的方式，显得更加直观。

2. 强大的语法功能

单就语法的简单性而言，Ruby不及Python。但解决一些较复杂的问题，Ruby强大的语法功能，有助于降低问题的复杂度。

例如：

Ruby以“块”的方式来实现列表内的条件、循环语句，比Python的更灵活、更具通用性。

Ruby具有类似Lisp的彻底的函数方式的条件、循环语句等。

Ruby的迭代器功能可以将流程控制结构抽象化。

3. 强大的字符串处理、正则表达式功能

Matz认为：Ruby >(Smalltalk + Perl) / 2。

Ruby类库是对Perl语言功能的面向对象方式的重组，因为借鉴了很多Perl的东西，使得字符串处理、正则表达式这块，Ruby同样强大。

4. 不会僵住的“胶水语言”

同样是“胶水语言”，Ruby比Python更灵活。

使用过一段时间的Python，你会发现，Python比较依赖第三方的东西。相比较，Ruby则更依赖自身。例如，Ruby可以使用（UNIX的）绝大部分的系统调用，单独使用Ruby也可以进行系统编程等。

有优势，Ruby就一定可以成功了？Python同样也有很多优势！对，还得看当时所处的环境。

三、 时势造英雄

这点还得回到RoR的崛起。

Ruby，1995年12月正式发布，2000年进入美国；2004年7月，RoR正式发布。

RoR的出现时间，值得玩味。

在下面的“Java语言受关注程度趋势图”上，可以看到，2004年7月前后，Java处于一个相对“衰退期”。

提到Java，大家应该都会想到J2EE。

J2EE应用程序的广泛实现是从1999、2000年开始的，它的出现带来了诸如事务管理之类的核心中间层概念的标准化，但是因其开发效率、学习难度和实 际性能的问题，在实践中没有获得完全的成功。作为J2EE核心技术的EJB（2.x），更是因其高昂的学习代价、极低的开发效率和极高的资源消耗，备受指 责。

在这样一个大背景下，2003年，Spring框架诞生了。

Spring的设计思想在于“使J2EE开发更加简单”。这个设计思想，在包括Java领域在内的众多软件开发领域引起了广泛关注。软件开发者们开始思考，如何让开发向着一个更简单的方向发展。

RoR在这一时期出现，无疑是顺应了这样一个潮流。

可以这么说，是历史选择了RoR，当然也选择了Ruby。

遇到合适的机遇，还不够，俗话说得好：“众人拾柴火焰高”。

四、 众星捧月

Ruby的出现，受到了两大主流平台Java和.NET的极力追捧。

2006年9月，SUN雇佣了JRuby的主要开发者Charles Nutter和Thomas Enebo；一年不到，2007年6月14号，JRuby 1.0正式发布。SUN在其Java IDE NetBeans 6.0 M10中，更是集成了对Ruby/JRuby的支持。反观Python的Java实现——Jython，则没有这么幸运，发展至今，它并没有得到SUN的 支持。

而Microsoft，也在2007年7月，推出了Ruby的.NET实现——IronRuby的预览版。

相信SUN和Microsoft对Ruby的竞相推崇，必然推动Ruby的进一步发展。

基于以上几点，笔者认为Ruby的成功不是偶然，并且相信这样的成功还会持续下去。对于Python的未来，我们也将拭目以待。

iBATIS提供的持久层框架包括SQL Maps和Data Access Objec

ibatis框架

ts（DAO），同时还提供一个利用这个框架开发的JPetStore实例。

相对Hibernate和ApacheOJB等“一站式”ORM解决方案而言，ibatis 是一种“半自动化”的ORM实现。

iBATIS 目前提供了三种语言实现的版本，包括：Java、.NET以及Ruby。右图是iBATIS的架构图：

目前主流

所谓“半自动”，可能理解上有点生涩。纵观目前主流的 ORM(对象关系映射)，无论 Hibernate还是ApacheOJB，都对数据库结构提供了较为完整的封装，提供了从POJO到数据库表的全套映射机制。程序员往往只需定义好了POJO 到数据库表的映射关系，即可通过 Hibernate或者OJB 提供的方法完成持久层操作。程序员甚至不需要对 SQL 的熟练掌握，Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的 SQL 并调用 JDBC 接口加以执行。

大多数情况下（特别是对新项目，新系统的开发而言），这样的机制无往不利，大有一统天下的势头。但是，在一些特定的环境下，这种一站式的解决方案却未必灵光。