分布式定时任务解决方案

分布式定时任务解决方案

一、背景

服务有定时任务，当服务部署到多个节点时，每个节点在同一个时间点都会执行相同的定时任务，需要做的是，让同一个时间点，每一个定时任务只在一个节点上执行，避免重复执行。

二、 解决方案思路

• 单独设置任务调度服务
• 使用Redis实现
• 使用XXL-JOB实现
• 使用Elastic-Job框架实现–参考springBoot中使用elasticjob
• 使用LTS框架实现

三、方案

3.1 方案一：单独设置任务调度服务

任务调度服务部署在单结点，定时任务以Http请求的方式去向网关调用任务请求，网关将请求分发到集群中的某一个节点，某一个节点执行任务。

3.2 方案二：使用Redis分布式锁实现

每个定时任务都在Redis中设置一个Key-Value的分布式锁，Key为自定义的每个定时任务的名字（如task1:redis:lock），Value为服务器Ip，同时设置合适的过期时间（例如设置为5min），只有获取到锁的服务才能执行任务，其他服务则只能等待轮询。

每个节点在执行时，都要进行以下操作：
1.是否存在Key，若不存在，则设置Key-Value，Value为当前节点的IP
2.若存在Key，则比较Value是否是当前Ip，若是则获取到了锁继续执行定时任务，若不是，则没有获取到锁就不往下执行并定时任务轮询 直到它抢到锁为止。

3.3 方案三：开源分布式框架（推荐）

1、使用XXL-JOB实现
xxl-job是一个轻量级的分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

xxl-job的设计思想为：

（1）将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求

（2）将任务抽象成分散的JobHandler，交由执行器统一管理，执行器负责接收调度请求并执行对应的JobHandler中业务逻辑

因此，“调度”和“任务”可以互相解偶，提高系统整体的稳定性和扩展性。

2、Elastic-Job：
Elastic-job在2.x之后，出现了两个相互独立的产品线：Elastic-job-lite和Elastic-job-cloud
Elastic-job-lite：定位为轻量级无中心化的解决方案，使用jar包的形式提供分布式任务的协调服务，外部依赖仅依赖于zookeeper。

选型

1、Quartz集群模式：Java事实上的定时任务标准，但是关注点在于定时任务而非数据，虽然实现了高可用，但是缺少分布式并行调度的功能，性能低。

2、TBSchedule：阿里早期开源的分布式任务调度系统。代码略陈旧，使用的是Timer而不是线程池执行任务调度。TBSchedule的作业类型比较单一，只能是获取/处理数据一种模式，文档缺失比较严重。

框架名称	xxl-job	elastic-job
简介	大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。	当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，并且可以支持云开发，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。
社区力量	大众点评公司下员工许雪里、贡献者16人，官网登记使用公司有133家	当当网开源，贡献者29人，官网公布使用公司有46家
链接	http://www.xuxueli.com/xxl-job/#/	http://elasticjob.io/index_zh.html
文档	完善	完善
集群部署	执行器支持集群部署，提升调度系统可用性，同时提升任务处理能力。集群部署唯一要求为：保证集群中每个执行器的配置项 “xxl.job.admin.addresses/调度中心地址” 保持一致，执行器根据该配置进行执行器自动注册等操作	作业注册中心： 基于Zookeeper和其客户端Curator实现的全局作业注册控制中心。用于注册，控制和协调分布式作业执行
多节点任务执行	使用Quartz基于数据库的分布式功能避免重复执行任务	将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片
日志跟踪	支持，有日志查询界面	可通过事件订阅的方式处理调度过程的重要事件，用于查询、统计和监控。Elastic-Job目前提供了基于关系型数据库两种事件订阅方式记录事件
监控告警	任务调度失败时邮件通知的邮箱地址，支持配置多邮箱地址，配置多个邮箱地址时用逗号分隔	通过事件订阅方式可自行实现
弹性扩容缩容	使用Quartz基于数据库的分布式功能，服务器超出一定数量会给数据库造成一定的压力	通过zk实现各服务的注册、控制及协调
并行调度	调度系统多线程（默认10个线程）触发调度运行，确保调度精确执行，不被堵塞	采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项
高可用策略	“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行	调度器的高可用是通过运行几个指向同一个ZooKeeper集群的Elastic-Job-Cloud-Scheduler实例来实现的。ZooKeeper用于在当前主Elastic-Job-Cloud-Scheduler实例失败的情况下执行领导者选举。通过至少两个调度器实例来构成集群，集群中只有一个调度器实例提供服务，其他实例处于”待命”状态。当该实例失败时，集群会选举剩余实例中的一个来继续提供服务
失败处理策略	调度失败时的处理策略，策略包括：失败告警（默认）、失败重试	弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样失效转移功能也会牺牲部分性能
难易程度	简单	较复杂，需要深入理解分片原理算法
动态分片策略	分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度(执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时传递分片参数；可根据分片参数开发分片任务)	默认包含三种分片策略： 基于平均分配算法的分片策略、 作业名的哈希值奇偶数决定IP升降序算法的分片策略、根据作业名的哈希值对Job实例列表进行轮转的分片策略，支持自定义分片策略。elastic-job的分片是通过zookeeper来实现的。分片的分片由主节点分配，如下三种情况都会触发主节点上的分片算法执行： a、新的Job实例加入集群 b、现有的Job实例下线（如果下线的是leader节点，那么先选举然后触发分片算法的执行） c、主节点选举”
侧重点	侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用	关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用
对比Quartz	1.调用API的的方式操作任务，不人性化； 2.需要持久化业务QuartzJobBean到底层数据表中，系统侵入性相当严重。 3.调度逻辑和QuartzJobBean耦合在同一个项目中，这将导致一个问题，在调度任务数量逐渐增多，同时调度任务逻辑逐渐加重的情况加，此时调度系统的性能将大大受限于业务； 4.Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能。

参考文档

[1]: XXL-JOB 官网文档地址
[2]: Elastic-Job
[3]: LTS

作者： CoffeJoy
出处：https://www.cnblogs.com/fonxian/p/10858101.html
版权：本站使用「CC BY 4.0」创作共享协议，转载请在文章明显位置注明作者及出处。