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

分布式调度任务技术选型-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接入完成，即可开始开发任务。

go语言能做什么？

很多朋友可能知道Go语言的优势在哪，却不知道Go语言适合用于哪些地方。

1、 Go语言作为服务器编程语言，很适合处理日志、数据打包、虚拟机处理、文件系统、分布式系统、数据库代理等；网络编程方面。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语言能做什么的内容介绍了。

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

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

先介绍几种比较主流的。

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，正在学习中

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

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

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

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

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

安装 Mysql

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

部署项目（War或Spring Boot）

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

Quartz

Jetty

Hessian

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

分布式定时任务调度框架实践

分布式任务调度框架几乎是每个大型应用必备的工具，本文介绍了任务调度框架使用的需求背景和痛点，对业界普遍使用的开源分布式任务调度框架的使用进行了探究实践，并分析了这几种框架的优劣势和对自身业务的思考。

一、业务背景

1.1 为什么需要使用定时任务调度

（1）时间驱动处理场景： 整点发送优惠券，每天更新收益，每天刷新标签数据和人群数据。

（2）批量处理数据： 按月批量统计报表数据，批量更新短信状态，实时性要求不高。

（3）异步执行解耦： 活动状态刷新，异步执行离线查询，与内部逻辑解耦。

1.2 使用需求和痛点

（1）任务执行监控告警能力。

（2）任务可灵活动态配置，无需重启。

（3）业务透明，低耦合，配置精简，开发方便。

（4）易测试。

（5）高可用，无单点故障。

（6）任务不可重复执行，防止逻辑异常。

（7）大任务的分发并行处理能力。

二、开源框架实践与 探索

2.1 Java 原生 Timer 和

ScheduledExecutorService

2.1.1 Timer使用

Timer缺陷：

由于上述缺陷，尽量不要使用Timer， idea中也会明确提示，使用ScheduledThreadPoolExecutor替代Timer 。

2.1.2 ScheduledExecutorService使用

ScheduledExecutorService对于Timer的缺陷进行了修补，首先ScheduledExecutorService内部实现是ScheduledThreadPool线程池，可以支持多个任务并发执行。

对于某一个线程执行的任务出现异常，也会处理，不会影响其他线程任务的执行，另外ScheduledExecutorService是基于时间间隔的延迟，执行不会由于系统时间的改变发生变化。

当然，ScheduledExecutorService也有自己的局限性：只能根据任务的延迟来进行调度，无法满足基于绝对时间和日历调度的需求。

2.2 Spring Task

2.2.1 Spring Task 使用

spring task 是spring自主开发的轻量级定时任务框架，不需要依赖其他额外的包，配置较为简单。

此处使用注解配置

2.2.2 Spring Task缺陷

Spring Task 本身不支持持久化，也没有推出官方的分布式集群模式，只能靠开发者在业务应用中自己手动扩展实现，无法满足可视化，易配置的需求。

2.3 永远经典的 Quartz

2.3.1 基本介绍

Quartz框架是Java领域最著名的开源任务调度工具，也是目前事实上的定时任务标准，几乎全部的开源定时任务框架都是基于Quartz核心调度构建而成。

2.3.2 原理解析

核心组件和架构

关键概念

（1） Scheduler ：任务调度器，是执行任务调度的控制器。本质上是一个计划调度容器，注册了全部Trigger和对应的JobDetail， 使用线程池作为任务运行的基础组件，提高任务执行效率。

（2） Trigger ：触发器，用于定义任务调度的时间规则，告诉任务调度器什么时候触发任务，其中CronTrigger是基于cron表达式构建的功能强大的触发器。

（3） Calendar ：日历特定时间点的集合。一个trigger可以包含多个Calendar，可用于排除或包含某些时间点。

（4） JobDetail ：是一个可执行的工作，用来描述Job实现类及其它相关的静态信息，如Job的名称、监听器等相关信息。

（5） Job ：任务执行接口，只有一个execute方法，用于执行真正的业务逻辑。

（6） JobStore ：任务存储方式，主要有RAMJobStore和JDBCJobStore，RAMJobStore是存储在JVM的内存中，有丢失和数量受限的风险，JDBCJobStore是将任务信息持久化到数据库中，支持集群。

2.3.3 实践说明

（1）关于Quartz的基本使用

（2）业务使用要满足动态修改和重启不丢失， 一般需要使用数据库进行保存。

（3）组件化

（4）扩展

2.3.4 缺陷和不足

（1）需要把任务信息持久化到业务数据表，和业务有耦合。

（2）调度逻辑和执行逻辑并存于同一个项目中，在机器性能固定的情况下，业务和调度之间不可避免地会相互影响。

（3）quartz集群模式下，是通过数据库独占锁来唯一获取任务，任务执行并没有实现完善的负载均衡机制。

2.4 轻量级神器 XXL-JOB

2.4.1 基本介绍

XXL-JOB是一个轻量级分布式任务调度平台，主打特点是平台化，易部署，开发迅速、学习简单、轻量级、易扩展，代码仍在持续更新中。

主要提供了任务的动态配置管理、任务监控和统计报表以及调度日志几大功能模块，支持多种运行模式和路由策略，可基于对应执行器机器集群数量进行简单分片数据处理。

2.4.2 原理解析

2.1.0版本前核心调度模块都是基于quartz框架，2.1.0版本开始自研调度组件，移除quartz依赖 ，使用时间轮调度。

2.4.3 实践说明

详细配置和介绍参考官方文档。

2.4.3.1 demo使用：

@JobHandler(value="offlineTaskJobHandler") ，实现业务逻辑即可。（注：此次引入了dubbo，后文介绍）。

（滑动可查看）

示例2：分片广播任务。

（滑动可查看）

2.4.3.2 整合dubbo

（1）引入dubbo-spring-boot-starter和业务facade jar包依赖。

（滑动可查看）

（2）配置文件加入dubbo消费端配置（可根据环境定义多个配置文件，通过profile切换）。

（滑动可查看）

（3）代码中通过@Reference注入facade接口即可。

（滑动可查看）

（4）启动程序加入@EnableDubboConfiguration注解。

（滑动可查看）

2.4.4 任务可视化配置

内置了平台项目，方便了开发者对任务的管理和执行日志的监控，并提供了一些便于测试的功能。

2.4.5 扩展

（1）任务监控和报表的优化。

（2）任务报警方式的扩展，比如加入告警中心，提供内部消息，短信告警。

（3）对实际业务内部执行出现异常情况下的不同监控告警和重试策略。

2.5 高可用 Elastic-Job

2.5.1 基本介绍

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

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

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

可惜的是已经两年没有迭代更新记录。

2.5.2 原理解析

2.5.3 实践说明

2.5.3.1 demo使用

（1）安装zookeeper，配置注册中心config，配置文件加入注册中心zk的配置。

（滑动可查看）

（滑动可查看）

（2）配置数据源config，并配置文件中加入数据源配置。

（滑动可查看）

（滑动可查看）

（3）配置事件config。

（滑动可查看）

（4）为了便于灵活配置不同的任务触发事件，加入ElasticSimpleJob注解。

（滑动可查看）

（5）对配置进行初始化。

（滑动可查看）

（6）实现 SimpleJob接口，按上文中方法整合dubbo, 完成业务逻辑。

（滑动可查看）

2.6 其余开源框架

（1） Saturn ：Saturn是唯品会开源的一个分布式任务调度平台，在Elastic Job的基础上进行了改造。

（2） SIA-TASK ：是宜信开源的分布式任务调度平台。

三、优劣势对比和业务场景适配思考

业务思考：

四、结语

对于并发场景不是特别高的系统来说，xxl-job配置部署简单易用，不需要引入多余的组件，同时提供了可视化的控制台，使用起来非常友好，是一个比较好的选择。希望直接利用开源分布式框架能力的系统，建议根据自身的情况来进行合适的选型。

附：参考文献

高可用架构

改变互联网的构建方式

分布式调度系统（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 调用后，开始关闭集群，关闭顺序：