分布式定时任务(一)

作者: lyndon_nfc | 来源:发表于2016-09-19 21:39 被阅读9343次

    1,什么是分布式定时任务;
    2,为什么要采用分布式定时任务
    3,怎么样设计实现一个分布式定时任务
    4,当前比较流行的分布式定时任务框架

    1,什么是分布式定时任务

    • 首先,我们要了解计划任务这个概念,计划任务是指由计划的定时运行或者周期性运行的程序。我们最常见的就是Linux的‘crontab’和Windows的‘计划任务’。

    • 那么什么是分布式定时任务,个人总结为:把分散的,可靠性差的计划任务纳入统一的平台,并实现集群管理调度和分布式部署的一种定时任务的管理方式。叫做分布式定时任务。

    2,为什么要采用分布式定时任务

    单点定时任务的缺点:

    • 功能相对简单,交互性差,任务部署效率低,开发和维护成本比较高,不能很好的满足各系统定时任务的管理和控制,尤其在多系统的环境下更加明显;
    • 许多任务都是单机部署,可用性差;
    • 任务跟踪和告警难以实现。

    分布式定时任务的优势

    • 通过集群的方式进行管理调度,大大降低了开发和维护成本;
    • 分布式部署,保证了系统的高可用性,伸缩性,负载均衡,提高了容错;
    • 可以通过控制台部署和管理定时任务,方便灵活高效;
    • 任务都可以持久化到数据库,避免了宕机和数据丢失带来的隐患,同时有完善的任务失败重做机制和详细的任务跟踪及告警策略。

    3,怎么样设计和实现一个分布式定时任务
    3.1 分时方案

    • 严格划分时间片,交替运行计划任务,当主系统宕机后,备用系统仍然工作,但是处理初期被拉长了。
    • 缺点:周期延长了。
    untitled.png

    3.2 HA高可用方案:

    • 正常情况下主系统工作,备用系统守候,心跳检测发现主系统出现故障备用系统启动。
    • 缺点:单一系统,不能做负载均衡,只能垂直扩展,也就是硬件层面的升级,无法做水平扩展。
    untitled1.png

    3.3 多路心跳方案:

    • 采用多路心跳,做服务级,进程级的,IP和端口级别的心跳检测,正常情况是主系统工作,备用系统守候,心跳检测主系统出现故障,备用系统启动,当再次检测到主系统工作,则将执行权交回主系统。
    • 缺点:开发比较复杂,程序健壮性要求高。
    untitled2.png

    3.4 任务抢占方案:

    • A,B两台服务器同时工作,启动需要存在一前一后,谁先启动谁率先加锁,其他服务器只能等待,他们同时对互斥锁进行监控,一旦发现锁被释放,其他服务那个先抢到,那个运行,运行前加排他锁。
    • 优点:可以进一步实现多服务器横向扩展。
    • 缺点:开发复杂,程序健壮性要求高,有时候会出现不释放锁的问题。
    untitled4.png

    3.5 任务轮询或任务轮询+抢占排队方案

    • 每个服务器首次启动时加入队列;
    • 每次任务运行首先判断自己是否是当前可运行任务,如果是便运行;
    • 如果不是当前运行的任务,检查自己是否在队列中,如果在,便推出,如果不在队列中,便键入队列。
    untitled5.png

    通过以上这些方案,可以看出3.5的方案才是优先选择的,扩展性好,开发复杂度不是很高。那么这种方案需要的需要的技术原理是什么呢,那就是分布式互斥锁和队列。

    3.6 原理

    • 分布式互斥锁:
      互斥锁也叫排他锁,用于并发时管理多进程和多进程同一时刻只能有一个进程或者线程操作一个功能。我们将进程,线程中的锁延伸到互联网上,实现对一个节点运行的进程或线程加 锁,解锁操作。这样便能控制节点上的进程或线程的并发。如下图:
    untitled7.png

    有两台服务器运行定时任务,其中serverA的T2做了加锁操作,其他程序必须等它释放锁了才能运行。 那么如果serverA在加锁的过程中,出现宕机怎么办,是否会一直处于别锁状态。那么我们可以在每个锁都设置一个超时阈值,一旦超时便自动解锁。这样就不会因为宕机导致锁一直不被释 放。另外我们还要考虑命名空间的问题,主要是防止出现同名锁,导致被覆盖。

    • 队列:
      在上面的基础上,排队运行任务。
    untitled8.png

    从上图中可以看出,TaskQueue中排队情况,运行是自上而下的,当然这个顺序可以自己设置规则,只需要先进先出的远程即可。另外,Task Queue我们需要做至少两个节点,他们遵循主 从结构的原则,主节点需要实时向从节点同步数据,保证在主节点不可用,从节点可以替代。当然,这里可以使用权重轮询的方式,加上数据异步同步,让所有节点都可以做主从的切换, 根据运行状况来分配,可能会更好,但是这样开发难度也有所提高,但是大大增加了高可用性。

    3.7 总结:

    • 最后,我们要根据我们实际的情况,需要提供数据库和缓存方面的一些配套服务,这里就不做详解;

    • 这样我们整体的一个分布式定时任务平台就可以实现了,就可以保证计划任务的分布式运行。

    4,当前比较流行的分布式定时任务框架:
    4.1 Quartz:

    • Quartz是Java领域最著名的开源任务调度工具。Quartz提供了极为广泛的特性如持久化任务,集群和分布式任务
    • 特点:
      • 完全由Java写成,同时可以很方便的和java的另外一个框架spring集成;
      • 强大的调度功能:支持丰富多样的调度方法,可以满足各种常规及特殊需求;
      • 灵活的应用方式:支持任务和调度的多种组合方式,支持调度数据的多种存储方式;
      • 分布式和集群能力,负载均衡和高可用性;

    4.2 Elastic-job:

    • Elastic-Job是ddframe中dd-job的作业模块中分离出来的分布式弹性作业框架。去掉了和dd-job中的监控和ddframe接入规范部分。该项目基于成熟的开源产品Quartz和 Zookeeper及其客户端Curator进行二次开发

    • 项目开源地址:https://github.com/dangdangdotcom/elastic-job

    • 特点:

      • 定时任务:基于成熟的定时任务作业框架Quartz cron表达式执行定时任务;
      • 作业注册中心:基于Zookeeper和其客户端Curator实现全局作业注册控制中心。用于注册,控制和协调分布式作业执行。
      • 作业分片:将要给任务分片成多个小任务项到多服务器上同时执行;
      • 弹性扩容缩容:运行中的作业服务器崩溃,或新增N台作业服务器,作业框架将在下次作业执行前重新分片,不影响当前作业执行;
    • 支持多种作业执行模式:支持OneOff,Perpetual和SequenecePerpetual三种作业模式;

    • 失效转移:运行中的作业服务器崩溃不会导致重新分片,只会在下次作业启动时分片。启用失效转移功能可以在本次作业执行过程中,监测其他作业服务器空闲,抓取未完成的孤儿分片项 执行;

    • 运行时状态收集:监控作业运行时状态,统计最近一段时间处理的数据成功和失败数量,记录作业上次运行开始时间,结束时间和下次运行时间;

    • 作业停止,恢复和禁用:用于操作作业启动和停止,并可以禁止某作业运行,一般在上线时常用;

    • 被错过执行的作业重触发:自动记录错过执行的作业,并在上次作业完成后自动触发。

    • 多线程快速处理数据:使用多线程处理抓取到的数据,提升吞吐量;

    • 幂等性:重复作业任务项判定,不重复执行已运行的作业任务项;

    • 容错处理:作业服务器和Zookeeper服务器通信失败后则立即停止作业运行,防止作业注册中心将失效的分片分项配给其他作业服务器,而当前作业服务器任在执行任务,导致重复执行。

    • Spring支持:支持Spring容器,自定义命名空间,支持占位符;

    • 运维平台:提供了运维平台,可以管理作业和注册中心。

    从以上可以看出Elastic-job是在Quartz的基础上又做了一次全面的升级,做了配套的周边基础服务工作,完全成为了一个成熟的分布式定时任务框架。后面会分别介绍Quartz和 Elastic-job的详细原理和具体的使用方法。

    关于quartz分布式定时任务,可以参考
    分布式定时任务(二)
    分布式定时任务(三)

    相关文章

      网友评论

      本文标题:分布式定时任务(一)

      本文链接:https://www.haomeiwen.com/subject/kxmnettx.html