转载： http://www.cn blogs.com/Hao xinyue/p/6886196.html单机定型任务调度问题需要在许多APP应用系统上定期执行一些任务。 例如，确定订单系统的超时状态、定时更新缓存数据、向平台用户发送邮件，以及定期计算的报告。 常见的处理方法是使用线程的while (真)、害羞的蛋饼、Timer计时器来触发任务或使用quartz框架。 这些方法似乎可以完美解决，为什么还要分散呢？ 主要原因有以下两个。
1 .高可用性：单机版平台任务调度只能在一台机器上运行，如果程序或系统出现异常，功能将无法使用。 虽然可以在独立程序中充分稳定地实施，但总是有机会遇到程序以外的故障。 这是一个系统的核心功能所不能接受的。
2 )单机处理极限)本来一分钟内需要处理一万个订单，现在一分钟内需要处理十万个订单； 一个统计花了1个小时，现在业务方面用10分钟进行统计。 你可能会说多线程，独立的多进程也可以处理。 确实，多线程并行处理可以提高单位时间的处理效率，但单体能力有限。 主要是CPU、内存、磁盘。 有时单独处理不完。
这个时候需要分散的定时任务。 业界常用的分布式任务解决方案主要有quartz、淘宝的TBSchedule和当时的elastic-job。
quartz群集解决方案quartz的独立版本应该是众所周知的。 那个群集解决方案是使用数据库实现的。 群集体系结构包括：
上图中的三个节点在数据库中具有相同的作业定义，如果其中一个节点被禁用，则作业将在其他节点上运行。 三个节点的Job执行代码相同，如何保证只能在一台机器上触发？ 答案是使用了数据库锁。 quartz的集群解决方案有表scheduler_locks，quartz采用悲观锁定方式锁定triggers表，保证任务同步的正确性。 当节点上的线程获取锁定时，Job将在这台计算机上运行，而锁定将被这台计算机占用。 同时另一台机器也想触发这个任务，但是锁已经被占用了，所以只能等到这个锁被释放。 然后，查看trigger状态，如果已经运行，则不运行。
简言之，quartz的分布式调度策略是以数据库为边界资源的异步策略。 每个调度程序都遵守基于数据库锁的操作规则，以确保操作的唯一性。 同时使多个节点异步运行，以确保服务的可靠性。 但是，该战略有自己的限制。 群集的特性对于具有高CPU利用率的任务非常有用，但对于大量的短任务，每个节点都会断开数据库锁定，导致大量线程等待资源。 这随着节点的增加越来越严重。
另外，quartz的分散化只是解决了高可用性的问题，并没有解决任务片的问题，还是有单独处理的局限性。
TB方案
amily:Verdana,Arial,Helvetica,sans-serif; font-size:13px"> TBSchedule是一款非常优秀的高性能分布式调度框架，广泛应用于阿里巴巴、淘宝、支付宝、京东、聚美、汽车之家、国美等很多互联网企业的流程调度系统。tbschedule在时间调度方面虽然没有quartz强大，但是它支持分片功能。和quartz不同的是，tbschedule使用ZooKeeper来实现任务调度的高可用和分片。TBSchedule的分布式机制是通过灵活的Sharding方式实现的，分片的规则由客户端决定，比如可以按所有数据的ID按10取模分片、按月份分片等等。TBSchedule的宿主服务器可以进行动态扩容和资源回收，这个特点主要是因为它后端依赖的ZooKeeper，这里的ZooKeeper对于TBSchedule来说是一个NoSQL，用于存储策略、任务、心跳信息数据，它的数据结构类似文件系统的目录结构，它的节点有临时节点、持久节点之分。调度引擎启动后，随着业务量数据量的增多，当前Cluster可能不能满足目前的处理需求，那么就需要增加服务器数量，一个新的服务器上线后会在ZooKeeper中创建一个代表当前服务器的一个唯一性路径（临时节点），并且新上线的服务器会和ZooKeeper保持长连接，当通信断开后，节点会自动摘除。
TBSchedule会定时扫描当前服务器的数量，重新进行任务分配。TBSchedule不仅提供了服务端的高性能调度服务，还提供了一个scheduleConsole的war包，随着宿主应用的部署直接部署到服务器，可以通过web的方式对调度的任务、策略进行监控管理，以及实时更新调整。
elastic-jobElastic-Job当当开源的分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。一般我们只要使用Elastic-Job-Lite就好。
Elastic-Job-Lite并没有宿主程序，而是基于部署作业框架的程序在到达相应时间点时各自触发调度。它的开发也比较简单，引用Jar包实现一些方法即可，最后编译成Jar包运行。Elastic-Job-Lite的分布式部署全靠ZooKeeper来同步状态和原数据。实现高可用的任务只需将分片总数设置为1，并把开发的Jar包部署于多个服务器上执行，任务将会以1主N从的方式执行。一旦本次执行任务的服务器崩溃，其他执行任务的服务器将会在下次作业启动时选择一个替补执行。如果开启了失效转移，那么功能效果更好，可以保证在本次作业执行时崩溃，备机之一立即启动替补执行。
Elastic-Job-Lite的任务分片也是通过ZooKeeper来实现，Elastic-Job并不直接提供数据处理的功能，框架只会将分片项分配至各个运行中的作业服务器，开发者需要自行处理分片项与真实数据的对应关系。框架也预置了一些分片策略：平均分配算法策略，作业名哈希值奇偶数算法策略，轮转分片策略。同时也提供了自定义分片策略的接口。
另外Elastic-Job-Lite还提供了一个任务监控和管理界面：Elastic-Job-Lite-Console。它和Elastic-Job-Lite是两个完全不关联的应用程序，使用ZooKeeper来交换数据，管理人员可以通过这个界面查看、监控和管理Elastic-Job-Lite的任务，必要的时候还能手动触发任务。
elastic-job结合了quartz非常优秀的时间调度功能，并且利用ZooKeeper实现了灵活的分片策略。除此之外，还加入了大量实用的监控和管理功能，以及其开源社区活跃、文档齐全、代码优雅等优点，是分布式任务调度框架的推荐选择。
Saturn
Saturn是唯品会在github开源的一款分布式任务调度产品。它是基于当当elastic-job来开发的，其上完善了一些功能和添加了一些新的feature。目前在github上开源大半年，470个star。Saturn的任务可以用多种语言开发比如python、Go、Shell、Java、Php。其在唯品会内部已经发部署350+个节点，每天任务调度4000多万次。同时，管理和统计也是它的亮点。
有兴趣的同学可以从https://github.com/vipshop/Saturn 上了解更加详细的信息。