分布式定时任务的解决方案

文章目录

    • 前言
      • 什么是分布式定时任务?
      • 分布式定时任务的意义
      • 定时任务与消息队列的区别
    • 分布式定时任务解决方案
      • 分时方案
      • HA高可用方案
      • 多路心跳方案
      • 任务抢占方案
      • 任务轮询+抢占排队方案
    • 分布式定时任务调度框架
      • quartz
      • elastic-job
      • xxl-job

前言

什么是分布式定时任务?

把分散的,可靠性差的计划任务纳入统一的平台,并实现集群管理调度和分布式部署的一种定时任务的管理方式,就叫做分布式定时任务。

它有两层含义:

  1. 它是运行在分布式集群环境下的调度任务,同⼀个定时任务程序部署多份,则同一时刻应当只允许⼀个定时任务执行。
  2. 定时任务的拆分,就是把⼀个大的作业任务拆分为多个小的作业任务,同时执行。

分布式定时任务的意义

为什么使用分布式定时任务?主要有如下两点原因:

  1. 高可用:单机版的定式任务调度只能在一台机器上运行,如果程序或者系统出现异常就会导致功能不可用,而这个对于一些核心系统功能来说是不可接受的。

  2. 单机性能瓶颈:单机能力毕竟有限(主要是CPU、内存和磁盘),随着任务量的提高,始终会有单机处理不过来的情况。

分布式定时任务使用场景:

  • 订单审核、出库、订单超时自动取消与退款
  • 优惠券生成、发放与过期
  • 物流信息推送与状态刷新
  • 数据积压监控、日志监控、服务可用性探测作业
  • 定时备份与更新数据
  • 金融系统每天的定时结算
  • 按月批量统计报表数据

单点定时任务的缺点:

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

分布式定时任务的优势:

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

定时任务与消息队列的区别

共同点

  • 异步处理:比如注册、下单事件
  • 可用于应用解耦:不管定时任务作业还是MQ都可以作为两个应用之间的齿轮实现应用解耦
  • 流量削峰去谷:电商大促销的时候,任务作业和MQ都可以用来平滑流量,后端系统根据服务能力定时处理订单或者从MQ抓取订单抓取到⼀个订单到来事件的话触发处理,对于前端用户来说看到的结果是已经下单成功了

不同点

  • 定时任务作业是时间驱动,而MQ是事件驱动;时间驱动是不可代替的,比如金融系统每⽇的利息结算,不是说利息来⼀条(利息生成事件发生)就计算一条,而是通过定时任务基于时间节点批量计算

分布式定时任务解决方案

分时方案

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

缺点:周期延长了。

HA高可用方案

正常情况下主系统工作,备用系统守候,心跳检测发现主系统出现故障备用系统启动。

缺点:单一系统,不能做负载均衡,只能垂直扩展,也就是硬件层面的升级,无法做水平扩展。

多路心跳方案

采用多路心跳,做服务级,进程级的,IP和端口级别的心跳检测,正常情况是主系统工作,备用系统守候,心跳检测主系统出现故障,备用系统启动,当再次检测到主系统工作,则将执行权交回主系统。

缺点:开发比较复杂,程序健壮性要求高。

任务抢占方案

A,B两台服务器同时工作,启动需要存在一前一后,谁先启动谁率先加锁,其他服务器只能等待,他们同时对互斥锁进行监控,一旦发现锁被释放,其他服务那个先抢到,那个运行,运行前加排他锁。

优点:可以进一步实现多服务器横向扩展。

缺点:开发难度高,会出现死锁的问题。

任务轮询+抢占排队方案

每个服务器首次启动时加入队列;

每次任务运行首先判断自己是否是当前可运行任务,如果是便运行;

如果不是当前运行的任务,检查自己是否在队列中,如果不在队列中,便加入队列。

分布式定时任务调度框架

quartz

介绍

在java编程中,常用的比较出名的任务调度工具是Quartz,该工具提供丰富的接口来帮助我们实现基于Cron
Expression的定时任务以及按照固定频率执行任务等。在运行过程中,该工具会创建线程池,所有任务会在线程池中运行,注意默认的线程池中线程数量有限,仅有10个线程,可以通过程序修改线程池的容量。当提交的job多于线程池的容量的时候,多余的job会在等待队列里进行等待,如果有一些提交的job属于长时间运行或者阻塞的任务,这样的job多于线程池的容量的时候就会导致一些job长时间处在等待队列里不能运行,这时候调度器处于阻塞状态。针对这个问题,可以采用增加线程池的容量的方法处理。

Quartz也支持分布式的实现,任务状态信息都存储在数据库中,基于数据库引擎及 High-Available 的策略(集群的一种策略)自动协调每个节点的
Quartz。不过Quartz在实现过程中效率相对低下,因为对于任务量比较大的场景下,会涉及到频繁的任务切换,进而会涉及频繁的加锁和解锁,甚至会带来集群间的主线程等待。

  • Job:表示一个工作,要执行的具体内容。此接口中只有一个方法
    void execute(JobExecutionContext context)

  • JobDetail:表示一个具体的可执行的调度程序,Job是这个可执行程调度程序所要执行的内容,另外JobDetail还包含了这个任务调度的方案和策略。

  • Trigger代表一个调度参数的配置,什么时候去调用。

  • Scheduler代表一个调度容器,一个调度容器中可以注册多个JobDetail和Trigger。当Trigger与JobDetail组合,就可以被Scheduler容器调度了。

上图三个节点在数据库中都拥有同一份Job定义,如果某一个节点失效,那么Job会在其他节点上执行。由于三个节点上的Job执行代码是一样的,那么怎么保证只有在一台机器上触发呢?

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

优点:

保证节点高可用 (HA), 如果某一个几点挂了, 其他节点可以顶上

缺点:

  • 同一个任务只能有一个节点运行,其他节点将不执行任务,性能低,资源浪费
  • 当碰到大量短任务时,各个节点频繁的竞争数据库锁,节点越多这种情况越严重,造成性能会很低下
  • quartz 的分布式仅解决了集群高可用的问题,并没有解决任务分片的问题,不能实现水平扩展,还是会有单机处理的极限

elastic-job

介绍

elastic-job 是由当当网基于quartz 二次开发之后的分布式调度解决方案 , 由两个相对独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成 。

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

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

特点

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

任务监控和管理界面:Elastic-Job-Lite-Console。它和Elastic-Job-
Lite是两个完全不关联的应用程序,使用ZooKeeper来交换数据,管理人员可以通过这个界面查看、监控和管理Elastic-Job-Lite的任务,必要的时候还能手动触发任务。

xxl-job

介绍

许雪里个人开源的一个轻量级分布式任务调度框架 ,主要分为 调度中心和执行器两部分 ,调度中心在启动初始化的时候,会默认生成执行器的RPC代理。对象(http协议调用), 执行器项目启动之后, 调度中心在触发定时器之后通过jobHandle来调用执行器项目里面的代码,核心功能和elastic-job差不多,同时技术文档比较完善。

GitHub地址:https://github.com/xuxueli/xxl-job

设计思想:

将调度行为抽象形成“调度中心”公共平台,而平台自身并不承担业务逻辑,“调度中心”负责发起调度请求。将任务抽象成分散的JobHandler,交由“执行器”统一管理,“执行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。因此,“调度”和“任务”两部分可以相互解耦,提高系统整体稳定性和扩展性。

系统组成:

  • 调度模块(调度中心) : 负责管理调度信息,按照调度配置发出调度请求,自身不承担业务代码。调度系统与任务解耦,提高了系统可用性和稳定性,同时调度系统性能不再受限于任务模块; 支持可视化、简单且动态的管理调度信息,包括任务新建,更新,删除,GLUE开发和任务报警等,所有上述操作都会实时生效,同时支持监控调度结果以及执行日志,支持执行器Failover。
  • 执行模块(执行器) : 负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作,开发和维护更加简单和高效; 接收“调度中心”的执行请求、终止请求和日志请求等。

与quartz对比:

  1. 有任务管理界面,操作人性化
  2. 调度逻辑和QuartzJobBean任务解耦,quartz是耦合在同一个项目中的,调度任务数量逐渐增多,调度任务逻辑逐渐加重的情况下,调用系统的性能将大大受限于业务。
  3. quartz底层以“抢占式”获取DB锁并由抢占成功节点负责运行任务,会导致节点负载悬殊非常大;而XXL-JOB通过执行器实现“协同分配式”运行任务,充分发挥集群优势,负载各节点均衡。
  4. 支持多种模式的定时任务, GLUE模式(Shell) + GLUE模式(Python) + GLUE模式(NodeJS)

你可能感兴趣的:(分布式架构,分布式,定时任务,quartz)