go语言分布式调度job go语言调度器

分布式任务调度框架选型，如何选择一个合适的框架？

首先，这种框架现在市面上是有的。强烈建议，不要重复造轮子。

先介绍几种比较主流的。

Elastic-Job,是当当网开源的分布式调度解决方案，支持任务分片功能，可以充分利用资源。Elastic-Job有两个独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。具体实现可以参考官方教程。其整体架构图如下。

Elastic-Job的特点：

1、分布式调度 2、作业高可用 3、任务分片执行。

另外，还有其他的一些框架，可以对比使用。比如TBSchedule是阿里巴巴开源的分布式调度框架，完全由java实现，目前被应用于淘宝，阿里巴巴，支付宝，京东， 汽车 之家等。大众点评开源的xxl-job，也是应用比较广泛的分布式调度任务。

目前我使用过的有 Elastic-Job和xxl-job。两者功能都很强大，后台管理也比较完善。很容易上手。都可以满足日常的工作需要。区别就是 Elastic-Job依赖zk，但是xxl-job不依赖zk，只依赖数据库。

目前市面上应该还有一些其他的框架，但是以上是比较主流的，可以根据自己的需要来选择。切记不要重复造轮子，造轮子需要大量的时间去验证。会让你在坑里爬不出来。

1.XXL-JOB

2.Elastic-Job

Elastic-Job 是一个分布式调度解决方案，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。

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

支持分布式调度协调、弹性扩容缩容、失效转移、错过执行作业重触发、并行调度、自诊断和修复等等功能特性。

分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。

Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。选择该项目可以满足大多数it企业的需求。

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

轻量级无中心化：Elastic-Job-Lite并无作业调度中心节点，而是基于部署作业框架的程序在到达相应时间点时各自触发调度。

灵活的增删改查作业，集中式管理调度作业

支持高可用：一旦执行作业的服务器崩溃，等待执行的服务器将会在下次作业启动时替补执行。开启失效转移功能效果更好，可以保证在本次作业执行时崩溃，备机立即启动替补执行。

支持分片：作业分片一致性，保证同一分片在分布式环境中仅一个执行实例

任务监控：通过监听Elastic-Job-Lite的zookeeper注册中心的几个关键节点即可完成作业运行状态监控功能

一致性：使用zookeeper作为注册中心，为了保证作业的在分布式场景下的一致性，一旦作业与注册中心无法通信，运行中的作业会立刻停止执行，但作业的进程不会退出，这样做的目的是为了防止作业重分片时，将与注册中心失去联系的节点执行的分片分配给另外节点，导致同一分片在两个节点中同时执行。

同时支持动态扩容，将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片

3.opencron

opencron是一个功能完善且通用的开源定时任务调度系统，拥有先进可靠的自动化任务管理调度功能，提供可操作的 web 图形化管理满足多种场景下各种复杂的定时任务调度，同时集成了 linux 实时监控、webssh 等功能特性

4.quartz

支持集群和分布式，但是没有友好的管理界面，功能单一，对于管理调用的任务比较困难。

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

quartz的分布式调度策略是以数据库为边界资源的一种异步策略。各个调度器都遵守一个基于数据库锁的操作规则从而保证了操作的唯一性。同时多个节点的异步运行保证了服务的可靠。但这种策略有自己的局限性：集群特性对于高CPU使用率的任务效果很好，但是对于大量的短任务，各个节点都会抢占数据库锁，这样就出现大量的线程等待资源。这种情况随着节点的增加会越来越严重。

缺点：quartz的分布式只是解决了高可用的问题，并没有解决任务分片的问题，还是会有单机处理的极限。

5.Saturn

Saturn

基于当当Elastic Job代码基础上自主研发的任务调度系统，是唯品会开源的分布式作业调度平台，取代传统的Linux Cron/Spring Batch Job的方式，做到统一配置，统一监控，任务高可用以及分片并发处理。主要是去中心化，高可用，可分片，动态扩容，有认证和授权功能。

主要特性

支持多种语言作业，语言无关(Java/Go/C++/PHP/Python/Ruby/shell)

支持秒级调度

支持作业分片并行执行

支持依赖作业串行执行

支持作业高可用和智能负载均衡

支持异常检测和自动失败转移

支持异地容灾

支持多个集群部署

支持跨机房区域部署

支持弹性动态扩容

支持优先级和权重设置

支持docker容器，容器化友好

支持cron时间表达式

支持多个时间段暂停执行控制

支持超时告警和超时强杀控制

支持灰度发布

支持异常、超时和无法高可用作业监控告警和简易的故障排除

支持失败率最高、最活跃和负荷最重的各域各节点TOP10的作业统计

优点：源码清晰，学习入手容易。应用部署简单，提供运维控制台，集中管理作业，运维控制台功能强大，提供作业统计报表 ，告警，增删改查作业，作业统一配置。

最后一个是国内团队封装的

前端时间研究了两款分布式任务调度框架，一个是XXL-Job，现在非常主流，很多常见的一些公司都在使用，像滴滴美团这样的公司都在用，这也是一款开源产品，下载下来导入IDEA就可以使用，分调度器和执行器和管理UI，有很美观的UI界面，可以对任务做增删改查，以及支持自定义开发，有很详细的帮助文档，还提供有demo，傻瓜式的，很简单，亮点是提供了管理界面。

另一个是Quartz，这个组件单机和集群都支持，单机的话是RAMJobStore任务存储，而要支持集群的话，就要将配置改成数据库方式，Quartz提供的有十几张表，其分布式的原理是利用了数据库的行锁，Quartz很简单，也是一款轻量级的开源产品，我们公司一直用这款组件，很成熟无Bug，推荐使用！

springcloudtask，springclouddataflow，正在学习中

相关问答

Q1: 分布式调度任务技术选型-xxl-job二次开发优化

任务调度是日常开发中非常常见的一个业务场景。目前系统采用的是Quartz框架进行任务调度，但与业务系统耦合性太高，极端情况下，耗时任务甚至会耗尽调度线程，导致大量任务堵塞与延迟。也可能拖垮业务系统。

另一方面Quartz没有后台管理界面。问题定位排查 手动触发任务，随时修改任务执行时间等较难。

1：有良好的后台管理页面。

2：任务动态分片，数据庞大的大任务处理。

3：任务阻塞，路由及报警策略。

4：开发文档和社区完善。

此次主要对xxl-job(大众)，Elastic-job（当当），staturn（唯品会），lts，TBSchedule（阿里）五种调度框架进行综合对比。

e-Job和xxl-job都有广泛的用户基础和的技术文档，都能满足定时任务的基本功能需求。

e-Job已有2年左右没更新，社区也已经不维护，后续稳定性无法保证。

xxl-job 文档详细，且任务报警、阻塞及路由策略丰富，社区完善。

 因此采用xxl-job调度框架。

-路由策略：- 阻塞处理策略 -子任务：-失败报警 -分片广播 动态分片 等 

这里就不照搬官网参数，参考：

- 任务调度错过触发时间时的处理策略：

可能原因：服务重启；调度线程被阻塞，线程被耗尽；上次调度持续阻塞，下次调度被错过；

处理策略：

过期超5s：本次忽略，当前时间开始计算下次触发时间

过期5s内：立即触发一次，当前时间开始计算下次触发时间

1、在上万任务同时并发时 。发现有部分任务丢失问题。

      此问题可通过以下三种方案提升并发量：

    a.通过加大调度线程池数量。

    b.增加调度中心集群数量。

    c.修改过期任务处理策略，默认为5秒。

    官方数据：单机并发5千，目前本地实测：单机并发1千

2、因外部因素导致服务宕机时，正在执行的任务可能会丢失。例如：服务器断电。kill -9

    此问题通过二次开发解决，方案如下：

    a.心跳检测时，将下线的机器中正在执行的任务标记为失败，并重试。(默认30秒检测一次，3次失败则将此执行器下线，如果执行器在心跳检测间隔期重启完成，则正在执行中的任务会卡住无结果，解决方案参考b)

    b.有新执行器注册时，查找此执行器是否有正在执行中的任务，有则标记为失败，任务会自动重试。

3、不支持重复性一次性任务

       二次开发可以解决，即利用同一个任务，每次通过接口方式传入需要执行的参数，例如：订单号10086在15分钟后超时取消。 通过调用启动任务接口，动态传参即可

1、在admin后台添加对应的执行器。AppName为唯一标识

2、添加Maven依赖

dependency

    groupIdcom.xuxueli/groupId

    artifactIdxxl-job-core/artifactId

    version2.1.1-SNAPSHOT/version

/dependency

3、添加xxl-job.properties

### 调度中心部署跟地址：如调度中心集群部署存在多个地址则用逗号分隔。执行器将会使用该地址进行"执行器心跳注册"和"任务结果回调"；为空则关闭自动注册；

xxl.job.admin.addresses=

### 执行器AppName：(在admin后台配置的AppName) 执行器心跳注册分组依据；为空则关闭自动注册,同一个执行器集群内AppName需要保持一致；调度中心根据该配置动态发现不同集群的在线执行器列表。

xxl.job.executor.appname=top-service-job

### 执行器IP：默认为空表示自动获取IP，多网卡时可手动设置指定IP，该IP不会绑定Host仅作为通讯实用；地址信息用于 "执行器注册" 和 "调度中心请求并触发任务"；

xxl.job.executor.ip=

### 执行器端口号 ：小于等于0则自动获取；默认端口为9999，单机部署多个执行器时，注意要配置不同执行器端口；

xxl.job.executor.port=9999

### 执行器通讯TOKEN ：非空时启用；

xxl.job.accessToken=

### 执行器运行日志文件存储磁盘路径 ：需要对该路径拥有读写权限；为空则使用默认路径；

xxl.job.executor.logpath=/data/applogs/xxl-job/jobhandler

### 执行器日志保存天数 ：值大于3时生效，启用执行器Log文件定期清理功能，否则不生效；

xxl.job.executor.logretentiondays=-1

至此xxl-job接入完成，即可开始开发任务。

Q2: 《分布式_Job》——定时XXL_JOB_使用总结

XXL-JOB 是一个轻量级中心式定时任务框架。

1、调度中心： 负责管理调度信息，触发调度请求。

2、执行器：负责接收调度请求并执行任务逻辑。

将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑。“调度中心”负责发起调度请求，“执行器”接收调度请求并运行任务逻辑。实现“调度”和“任务”的解耦。

安装 Mysql

编译“调度中心”和“执行器Example”

部署项目（War或Spring Boot）

新建测试任务（参考Example项目）

Quartz

Jetty

Hessian

[xxl_job相关详细概念请参考: ]

Q3: go语言能做什么？

很多朋友可能知道Go语言go语言分布式调度job的优势在哪go语言分布式调度job，却不知道Go语言适合用于哪些地方。

1、 Go语言作为服务器编程语言go语言分布式调度job，很适合处理日志、数据打包、虚拟机处理、文件系统、分布式系统、数据库代理等go语言分布式调度job；网络编程方面。Go语言广泛应用于Web应用、API应用、下载应用等；除此之外，Go语言还可用于内存数据库和云平台领域，目前国外很多云平台都是采用Go开发。

2、 其实Go语言主要用作服务器端开发。其定位是用来开发"大型软件"的，适合于很多程序员一起开发大型软件，并且开发周期长，支持云计算的网络服务。Go语言能够让程序员快速开发，并且在软件不断的增长过程中，它能让程序员更容易地进行维护和修改。它融合了传统编译型语言的高效性和脚本语言的易用性和富于表达性。

3、 Go语言成功案例。Nsq：Nsq是由Go语言开发的高性能、高可用消息队列系统，性能非常高，每天能处理数十亿条的消息；

4、 Docker：基于lxc的一个虚拟打包工具，能够实现PAAS平台的组建。

5、 Packer：用来生成不同平台的镜像文件，例如VM、vbox、AWS等，作者是vagrant的作者

6、 Skynet：分布式调度框架。

7、 Doozer：分布式同步工具，类似ZooKeeper。

8、 Heka：mazila开源的日志处理系统。

9、 Cbfs：couchbase开源的分布式文件系统。

10、 Tsuru：开源的PAAS平台，和SAE实现的功能一模一样。

11、 Groupcache：memcahe作者写的用于Google下载系统的缓存系统。

12、 God：类似redis的缓存系统，但是支持分布式和扩展性。

13、 Gor：网络流量抓包和重放工具。

以上的就是关于go语言能做什么的内容介绍了。

Q4: 分布式调度系统（3）——任务分配

将任务分配到具体执行节点。

以上配置信息保存在 /config/job/{jobName} 节点。

任务分配的目标是：让当前工作尽可能均衡地在各执行节点上执行。

触发任务分配的事件，可能是：

任务分配单元 ： 将任务拆分为最小可执行的粒度，如：一个父任务、一个shard子任务，一个子任务，作为一个分配单元。每个分配单元包括：（父任务名称，子任务shardItem序号/childIndex流水号，load）。

待分配任务列表 ：按任务分类，每个任务形成一个待分配列表，按load倒叙、sharingItem/childIndex正序 排序。

节点下线 ：在节点下线的场景，需要将故障节点下的任务摘下，按任务放入多个待分配任务列表。

任务启动 ：对于任务启动的场景，任务下所有的任务分配单元均需要重新分配，都放入到待分配任务列表中。

节点上线 ：在节点上线的场景中，需读取 /config/node/{nodeName} 数据， 确定受影响的任务。读取 /runtime/job/{jobName}/availableNodes/{nodeName} 确认受影响的节点。 计算新节点上线后平均每节点load，从负载最多的节点摘下。摘取时，每次摘取不同任务，直至节点node在平均值以下。

构建节点列表，构建 MapString /*node name*/ , Long /*node load*/ 。

逐个任务分配，优先分配总load高的任务。

每个任务按load倒叙，每次分配分配到不同节点，优先分配总load低的node。

如果节点load已经高出平均值，则退出待分配node列表。

集群启动过程中， 节点不断加进来， 不断触发任务重新分配， 这是没有必要的。

冷冻时间 ：集群初始启动过程中，第1个启动的节点确认没有其他节点后，会创建 /runtime/frozonTime 节点，节点数据为解冻的时间点（一般为5分钟后）。

在解冻时间到达之前，不触发任务分配。

创建冷冻节点的同时，清理availableNodes，和 /runtime/node/{nodeName}/job 。

集群收到 shutdown 调用后，开始关闭集群，关闭顺序：

关于go语言分布式调度job和go语言调度器的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。