简述分布式任务调度
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
日志可追溯
X-Job ：支持，有日志查询界面 E-Job ：可通过事件订阅的方式处理调度过程的重要事件，用于查询、统计和监控。
Elastic-Job目前提供了基于关系型数据库两种事件订阅方式记录事件。
第 肆 章
监控告警
X-Job ：调度失败时，将会触发失败报警，如发送报警邮件。 任务调度失败时邮件通知的邮箱地址，支持配置多邮箱地址，配置多个邮箱地址时用逗号分隔。
第贰章
有哪些分布式任务调度框架
第 贰 章
Quartz集群
上图三个节点在数据库中都拥有同一份Job定义，如果某一个节点失效，那 么Job会在其他节点上执行。由于三个节点上的Job执行代码是一样的，那 么怎么保证只有在一台机器上触发呢？答案是使用了数据库锁。在quartz 的集群解决方案里有张表scheduler_locks，quartz采用了悲观锁的方式 对triggers表进行行加锁，以保证任务同步的正确性。一旦某一个节点上 面的线程获取了该锁，那么这个Job就会在这台机器上被执行，同时这个锁 就会被这台机器占用。同时另外一台机器也会想要触发这个任务，但是锁 已经被占用了，就只能等待，直到这个锁被释放。之后会看trigger状态， 如果已经被执行了，则不会执行了。
开启失效转移功能效果更好，可以保证在本次作业执行时崩溃，备机立即启动替补执行。
第 肆 章
失败处理策略
X-Job ：调度失败时的处理策略，策略包括：失败告警（默认）、失败重试； E-Job ：弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业 将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。 同样失效转移功能也会牺牲部分性能。
分
常
分
有
为
布
用
布
哪
什
式
框
式
些
么
任
架
调
分
需
务
的
度
布
要
调
架
框
式
分
度
构
架
任
布
框
与
的
务
式
架
原
效
调
任
的
理
果
度
务
对
解
演
框
调
比
析
示
架
度
目录
本
来 无 一 物 ， 何 处 惹 尘 埃 ？
菩 提 本 无 树 ， 明 镜 亦 非 台
。
第壹章
为什么需要分布式任务调度
高可用问题
单机版的定式任务调度只能在 一台机器上运行，如果程序或 者系统出现异常就会导致功能 不可用。虽然可以在单机程序 实现的足够稳定，但始终有机 会遇到非程序引起的故障，而 这个对于一个系统的核心功能 来说是不可接受的。
高可用策略
X-Job E-Job
：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行； ：Elastic-Job-Lite提供最安全的方式执行作业。将分片总数设置为1，并使用多于1台的服务器执行作业，
作业将会以1主n从的方式执行。 一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。
动态分片策略
X-Job ：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理； 在进行大数据量业务操作时可显著提升任务处理能力和速度。
执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中 所有执行器执行一次任务，同时传递分片参数；可根据分片参数开发分片任务； E-Job ：支持多种分片策略，可自定义分片策略
第 肆 章
弹性扩容缩容
X-Job ：使用Quartz基于数据库的分布式功能，服务器超出一定数量会给数据库造成一定的压力 E-Job ：通过zk实现各服务的注册、控制及协调，支持并行调度
X-Job ：调度系统多线程（默认10个线程）触发调度运行，确保调度精确执行，不被堵塞。 E-Job ：采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项
简述分布式任务调度框架
-龚涛
前 言
任务调度是指基于给定时间点，给定时间间隔或者给定执行次数自动执行任务。我们经常 接触到的有 Timer, ScheduledExecutor, 开源工具包Quartz，JCronTab，Spring中也有 scheduled-tasks任务。
任务调度涉及多线程并发、运行时间规则制定及解析、运行现场保持与恢复、线程池维护 等诸多方面的工作。
E-Job ：通过事件订阅方式可自行实现。 作业运行状态监控、监听作业服务器存活、监听近期数据处理成功、数据流类型作业
（可通过监听近期数据处理成功数判断作业流量是否正常,如果小于作业正常处理的阀值，可选择报警。）、 监听近期数据处理失败（可通过监听近期数据处理失败数判断作业处理结果，如果大于0，可选择报警。）
E-Job ：当当网开源，贡献者17人; github有4173star、2003fork | QQ讨论群2个、源码讨论群１个 | 有登记在使用的超过40家公司 | 文档齐全 ｜有明确的发展计划，支持集群部署 X-Job ：集群部署唯一要求为：保证每个集群节点配置（db和登陆账号等）保持一致。
调度中心通过db配置区分不同集群。 执行器支持集群部署，提升调度系统可用性，同时提升任务处理能力。 集群部署唯一要求为：保证集群中每个执行器的配置项 “xxl.job.admin.addresses/调度中心地址” 保持一致，执行器根据该配置进行执行器自动注册等操作。
a、新的Job实例加入集群 b、现有的Job实例下线（如果下线的是leader节点，那么先选举然后触发分片算法的执行） c、主节点选举
第 肆 章
综合对比
共同点： E-Job和X-job都有广泛的用户基础和完整的技术文档，都能满足定时任务的基本功能需求。 不同点： X-Job 侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。 推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用。 E-Job 关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。 但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用。
Elastic-Job-Lite并没有宿主程序，而是基于部署作业框架的程序 在到达相应时间点时各自触发调度。它的开发也比较简单，引用Jar包实现 一些方法即可，最后编译成Jar包运行。Elastic-Job-Lite的分布式部署 全靠ZooKeeper来同步状态和原数据。实现高可用的任务只需将分片总数 设置为1，并把开发的Jar包部署于多个服务器上执行，任务将会以1主N从 的方式执行。一旦本次执行任务的服务器崩溃，其他执行任务的服务器将 会在下次作业启动时选择一个替补执行。如果开启了失效转移，那么功能 效果更好，可以保证在本次作业执行时崩溃，备机之一立即启动替补执行。
niubi-job
第叁章
分布式调度框架的效果演示
第肆章
常用框架的架构与原理解析
第 肆 章 Elastic-job运行流程
第 肆 章 xxl-job架构设计
第伍章
分布式任务调度框架的对比
第 肆 章
项目背景及社区力量
X-Job ：大众点评公司下员工许雪里、贡献者 16人; github有5569star、2392fork | QQ讨论群17个 | 有登记在使用的超过100家公司 | 文档齐全 |有明确的发展计划，支持集群部署
默认包含三种分片策略： 基于平均分配算法的分片策略、 作业名的哈希值奇偶数决定IP升降序算法的分片策略、 根据作业名的哈希值对Job实例列表进行轮转的分片策略，支持自定义分片策略。 elastic-job的分片是通过zookeeper来实现的。分片的分片由主节点分配，如下三种情况都会触发主节点上的分片算法执行：
地址：http://elasticjob.io/index_zh.html
第 贰 章
xxl-job
XXL-JOB是一个轻量级分布式任务调度平台，其核心设计目标是开发 迅速、学习简单、轻量级、易扩展。开源，开箱即用。
调度采用中心式设计，“调度中心”基于集群Quartz实现并支持集群 部署，可保证调度中心HA。
E-Job ：重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心 作业注册中心： 基于Zookeeper和其客户端Curator实现的全局作业注册控制中心。 用于注册，控制和协调分布式作业执行。
第 肆 章
多节点部署时任务不能重复执行
X-Job ：使用Quartz基于数据库的分布式功能 E-Job ：将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。 一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下， 下次任务开始前触发任务重分片。
谢谢您的观看
第 壹 章
单机处理极限问题
原本 1 分钟内需要处理 1 万 个订单，但是现在需要 1 分钟 内处理 10 万个订单；原来一 个统计需要 1 小时，现在业务 方需要 10 分钟就统计出来。 你也许会说，你也可以多线程、 单机多进程处理。的确，多线 程并行处理可以提高单位时间 的处理效率，但是单机能力毕 竟有限（主要是CPU、内存和磁 盘），始终会有单机处理不过 来的情况。
第 贰 章
Saturn
Saturn是唯品会在开源的一 款分布式任务调度产品。它 是基于elastic-job来开发 的，其上完善了一些功能和 添加了一些新的feature。
antares
基于Quartz的分布式调度。
LTS
LTS(light-taskscheduler)主要用于解决分 布式任务调度问题，支持实 时任务，定时任务和Cron任 务。好像是阿里的人写的。
地址：
第 贰 章
elastic-job
Elastic-Job当当开源的分布式调度解决方案，由两个相互独立的子 项目Elastic-Job-Lite和Elastic-Job-Cloud组成。Elastic-JobLite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的 协调服务。一般我们只要使用Elastic-Job-Lite就好。
任务分布式执行，任务“执行器”支持集群部署，可保证任务执行HA。 将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业 务逻辑，“调度中心”负责发起调度请求。 将任务抽象成分散的JobHandler，交由“执行器”统一管理，“执 行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。 因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定 性和扩展性；
地址：/xxl-job
TBSchedule
淘宝开源的分布式任务调度 框架。广泛应用于阿里巴巴、 淘宝、支付宝、京东、聚美、 汽车之家、国美等很多互联 网企业的流程调度系统。
Uncode-Schedule
基于zookeeper的分布式任 务调度组件，非常小巧，使 用简单，只需要引入jar包， 不需要单独部署服务端。确 保所有任务在集群中不重复， 不遗漏的执行。支持动态添 加和删除任务。
X-Job ：支持，有日志查询界面 E-Job ：可通过事件订阅的方式处理调度过程的重要事件，用于查询、统计和监控。
Elastic-Job目前提供了基于关系型数据库两种事件订阅方式记录事件。
第 肆 章
监控告警
X-Job ：调度失败时，将会触发失败报警，如发送报警邮件。 任务调度失败时邮件通知的邮箱地址，支持配置多邮箱地址，配置多个邮箱地址时用逗号分隔。
第贰章
有哪些分布式任务调度框架
第 贰 章
Quartz集群
上图三个节点在数据库中都拥有同一份Job定义，如果某一个节点失效，那 么Job会在其他节点上执行。由于三个节点上的Job执行代码是一样的，那 么怎么保证只有在一台机器上触发呢？答案是使用了数据库锁。在quartz 的集群解决方案里有张表scheduler_locks，quartz采用了悲观锁的方式 对triggers表进行行加锁，以保证任务同步的正确性。一旦某一个节点上 面的线程获取了该锁，那么这个Job就会在这台机器上被执行，同时这个锁 就会被这台机器占用。同时另外一台机器也会想要触发这个任务，但是锁 已经被占用了，就只能等待，直到这个锁被释放。之后会看trigger状态， 如果已经被执行了，则不会执行了。
开启失效转移功能效果更好，可以保证在本次作业执行时崩溃，备机立即启动替补执行。
第 肆 章
失败处理策略
X-Job ：调度失败时的处理策略，策略包括：失败告警（默认）、失败重试； E-Job ：弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业 将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。 同样失效转移功能也会牺牲部分性能。
分
常
分
有
为
布
用
布
哪
什
式
框
式
些
么
任
架
调
分
需
务
的
度
布
要
调
架
框
式
分
度
构
架
任
布
框
与
的
务
式
架
原
效
调
任
的
理
果
度
务
对
解
演
框
调
比
析
示
架
度
目录
本
来 无 一 物 ， 何 处 惹 尘 埃 ？
菩 提 本 无 树 ， 明 镜 亦 非 台
。
第壹章
为什么需要分布式任务调度
高可用问题
单机版的定式任务调度只能在 一台机器上运行，如果程序或 者系统出现异常就会导致功能 不可用。虽然可以在单机程序 实现的足够稳定，但始终有机 会遇到非程序引起的故障，而 这个对于一个系统的核心功能 来说是不可接受的。
高可用策略
X-Job E-Job
：“调度中心”通过DB锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行； ：Elastic-Job-Lite提供最安全的方式执行作业。将分片总数设置为1，并使用多于1台的服务器执行作业，
作业将会以1主n从的方式执行。 一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。
动态分片策略
X-Job ：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理； 在进行大数据量业务操作时可显著提升任务处理能力和速度。
执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中 所有执行器执行一次任务，同时传递分片参数；可根据分片参数开发分片任务； E-Job ：支持多种分片策略，可自定义分片策略
第 肆 章
弹性扩容缩容
X-Job ：使用Quartz基于数据库的分布式功能，服务器超出一定数量会给数据库造成一定的压力 E-Job ：通过zk实现各服务的注册、控制及协调，支持并行调度
X-Job ：调度系统多线程（默认10个线程）触发调度运行，确保调度精确执行，不被堵塞。 E-Job ：采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项
简述分布式任务调度框架
-龚涛
前 言
任务调度是指基于给定时间点，给定时间间隔或者给定执行次数自动执行任务。我们经常 接触到的有 Timer, ScheduledExecutor, 开源工具包Quartz，JCronTab，Spring中也有 scheduled-tasks任务。
任务调度涉及多线程并发、运行时间规则制定及解析、运行现场保持与恢复、线程池维护 等诸多方面的工作。
E-Job ：通过事件订阅方式可自行实现。 作业运行状态监控、监听作业服务器存活、监听近期数据处理成功、数据流类型作业
（可通过监听近期数据处理成功数判断作业流量是否正常,如果小于作业正常处理的阀值，可选择报警。）、 监听近期数据处理失败（可通过监听近期数据处理失败数判断作业处理结果，如果大于0，可选择报警。）
E-Job ：当当网开源，贡献者17人; github有4173star、2003fork | QQ讨论群2个、源码讨论群１个 | 有登记在使用的超过40家公司 | 文档齐全 ｜有明确的发展计划，支持集群部署 X-Job ：集群部署唯一要求为：保证每个集群节点配置（db和登陆账号等）保持一致。
调度中心通过db配置区分不同集群。 执行器支持集群部署，提升调度系统可用性，同时提升任务处理能力。 集群部署唯一要求为：保证集群中每个执行器的配置项 “xxl.job.admin.addresses/调度中心地址” 保持一致，执行器根据该配置进行执行器自动注册等操作。
a、新的Job实例加入集群 b、现有的Job实例下线（如果下线的是leader节点，那么先选举然后触发分片算法的执行） c、主节点选举
第 肆 章
综合对比
共同点： E-Job和X-job都有广泛的用户基础和完整的技术文档，都能满足定时任务的基本功能需求。 不同点： X-Job 侧重的业务实现的简单和管理的方便，学习成本简单，失败策略和路由策略丰富。 推荐使用在“用户基数相对少，服务器数量在一定范围内”的情景下使用。 E-Job 关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。 但是学习成本相对高些，推荐在“数据量庞大，且部署服务器数量较多”时使用。
Elastic-Job-Lite并没有宿主程序，而是基于部署作业框架的程序 在到达相应时间点时各自触发调度。它的开发也比较简单，引用Jar包实现 一些方法即可，最后编译成Jar包运行。Elastic-Job-Lite的分布式部署 全靠ZooKeeper来同步状态和原数据。实现高可用的任务只需将分片总数 设置为1，并把开发的Jar包部署于多个服务器上执行，任务将会以1主N从 的方式执行。一旦本次执行任务的服务器崩溃，其他执行任务的服务器将 会在下次作业启动时选择一个替补执行。如果开启了失效转移，那么功能 效果更好，可以保证在本次作业执行时崩溃，备机之一立即启动替补执行。
niubi-job
第叁章
分布式调度框架的效果演示
第肆章
常用框架的架构与原理解析
第 肆 章 Elastic-job运行流程
第 肆 章 xxl-job架构设计
第伍章
分布式任务调度框架的对比
第 肆 章
项目背景及社区力量
X-Job ：大众点评公司下员工许雪里、贡献者 16人; github有5569star、2392fork | QQ讨论群17个 | 有登记在使用的超过100家公司 | 文档齐全 |有明确的发展计划，支持集群部署
默认包含三种分片策略： 基于平均分配算法的分片策略、 作业名的哈希值奇偶数决定IP升降序算法的分片策略、 根据作业名的哈希值对Job实例列表进行轮转的分片策略，支持自定义分片策略。 elastic-job的分片是通过zookeeper来实现的。分片的分片由主节点分配，如下三种情况都会触发主节点上的分片算法执行：
地址：http://elasticjob.io/index_zh.html
第 贰 章
xxl-job
XXL-JOB是一个轻量级分布式任务调度平台，其核心设计目标是开发 迅速、学习简单、轻量级、易扩展。开源，开箱即用。
调度采用中心式设计，“调度中心”基于集群Quartz实现并支持集群 部署，可保证调度中心HA。
E-Job ：重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心 作业注册中心： 基于Zookeeper和其客户端Curator实现的全局作业注册控制中心。 用于注册，控制和协调分布式作业执行。
第 肆 章
多节点部署时任务不能重复执行
X-Job ：使用Quartz基于数据库的分布式功能 E-Job ：将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。 一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下， 下次任务开始前触发任务重分片。
谢谢您的观看
第 壹 章
单机处理极限问题
原本 1 分钟内需要处理 1 万 个订单，但是现在需要 1 分钟 内处理 10 万个订单；原来一 个统计需要 1 小时，现在业务 方需要 10 分钟就统计出来。 你也许会说，你也可以多线程、 单机多进程处理。的确，多线 程并行处理可以提高单位时间 的处理效率，但是单机能力毕 竟有限（主要是CPU、内存和磁 盘），始终会有单机处理不过 来的情况。
第 贰 章
Saturn
Saturn是唯品会在开源的一 款分布式任务调度产品。它 是基于elastic-job来开发 的，其上完善了一些功能和 添加了一些新的feature。
antares
基于Quartz的分布式调度。
LTS
LTS(light-taskscheduler)主要用于解决分 布式任务调度问题，支持实 时任务，定时任务和Cron任 务。好像是阿里的人写的。
地址：
第 贰 章
elastic-job
Elastic-Job当当开源的分布式调度解决方案，由两个相互独立的子 项目Elastic-Job-Lite和Elastic-Job-Cloud组成。Elastic-JobLite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的 协调服务。一般我们只要使用Elastic-Job-Lite就好。
任务分布式执行，任务“执行器”支持集群部署，可保证任务执行HA。 将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业 务逻辑，“调度中心”负责发起调度请求。 将任务抽象成分散的JobHandler，交由“执行器”统一管理，“执 行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。 因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定 性和扩展性；
地址：/xxl-job
TBSchedule
淘宝开源的分布式任务调度 框架。广泛应用于阿里巴巴、 淘宝、支付宝、京东、聚美、 汽车之家、国美等很多互联 网企业的流程调度系统。
Uncode-Schedule
基于zookeeper的分布式任 务调度组件，非常小巧，使 用简单，只需要引入jar包， 不需要单独部署服务端。确 保所有任务在集群中不重复， 不遗漏的执行。支持动态添 加和删除任务。