XXL-JOB

会采用配置中心来管理配置，国内使用最多的开源配置中心主要是nacos和apollo，本文来介绍下xxl-job-admin集成nacos的操作，使用nacos来管理xxl-job-admin的配置。 一、环境准备 nacos配置中心 java相关开发环境(maven、idea) 在集成完nacos后需要测试xxl-job-admin集成nacos是否成功，因此需要部署好可用的nacos。部署请仓考nacos官方文档。 二、改造步骤 2.1 下载xxl-job的源码 一般直接将源码导入到自己的开发工具中。导入后切换到官方已经发布的稳定分支做修改，如笔者修改的时候官方发布的最新版本是2.2.2。因为就直接 切换到2.2.2分支上做修改，源码地址如下： https://github.com/xuxueli/xxl-job.git 2.2 修改xxl-job-admin的pom 修改xxl-job-admin的pom，加入nacos集成的依赖，由于xxl-job-admin使用spring-boot集成，因此直接使用nacos的nacos-config-spring-boot-starter。 <dependency> <groupId>com.alibaba.boot</groupId> <artifactId>nacos-config-spring-boot-starter<

前言 我之前的工作中一直在用 Elastic-Job 来做任务调度。这也是大家为什么能在我的书籍《Spring Cloud 微服务 入门 实战与进阶》中看到 Elastic-Job 的章节。 从 2017 的 2.1.5 版本之后 Elastic-Job 没再更新过。我们在做技术选型的时候，对框架的使用范围和社区的活跃度都会比较看重，当然首先是功能点能够满足业务需求。 今天给大家新推荐一个任务调度框架，也许很多人听过甚至目前已经使用了很久。不过没关系，这也不影响你今天阅读本文章。 这个框架就是 XXL-JOB，一个轻量级分布式任务调度平台。最近在我的开源项目 Kitty-Cloud 中就采用了 XXL-JOB，还有一个原因是我目前任职的公司也一直在使用 XXL-JOB。 XXL-JOB 的前世今生 XXL-JOB 是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。 2015-11 月，XXL-JOB RELEASE 了第一个大版本 V1.0，在后面的几年里一直在更新。目前最新的版本是今年更新的 2.2.0。 功能特性 调度中心 HA（中心式） 执行器 HA（分布式） 执行器弹性扩容缩容 丰富的路由策略支持 支持高度容错故障转移 任务超时控制 任务失败重试 任务失败告警 任务动态分片 脚本任务 等等。。。

1、下载源码 下载 xxx-job源码 https://github.com/xuxueli/xxl-job 里面包含了xxl-job调度中心服务，xxl-job执行器服务 下载后的源码结构 xxl-job-admin： 调度中心服务 xxl-job-executor-sample-springboot: 执行器我这里选择的是spring boot版本。 2、然后根据xxl-job的入门文档进行配置。点击GET STARTED进入文档。 进入快速入门。执行sql，修改数据库密码配置， 修改logback日志地址配置， 编译源码 三、启动xxl-job-admin 访问 http://localhost:8080/xxl-job-admin/ 界面的效果如下图所示 四、启动xxl-job-executor-sample-springboot 修改logback的日志配置 五、在调度去里设置 来源： oschina 链接： https://my.oschina.net/u/4358286/blog/4260770

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 当初选了xxl-job就是因为它的触发机制比较靠谱，到点准时发，而且有日志可以看。 昨天突然发现部署在一台本地机器上的xxl-job到点并没有触发，且没有任何日志。通过管理页面查询触发日志，发现日志还是有的，只是和筛选条件不甚匹配。比如选取了昨天的日志，结果集中包含了今天早间的内容。初步怀疑是因为时差问题导致未能触发。 查看该机器上xxl-job对应的数据库，datetime类型的数据存储的都是标准时间，而我本地数据库中对应的是北京时间。尝试配置数据库时区： show variables like '%time_zone%'; 根据百度结果，CST可能会造成时区的混乱，所以手动将time_zone改为北京时间： SET GLOBAL time_zone = '+08:00'; SET time_zone = '+08:00'; FLUSH PRIVILEGES; 修改结果如： 然并卵，日志的日期依然不能和筛选条件相匹配。 点开xxl_job_info这张表，其中的字段trigger_next_time中的时间比job_cron中定义的触发时间多了8个小时，查看xxl-job-admin源码，trigger_next_time这个字段是程序中计算出来的，用关键字timezone搜索代码

生产端的可靠性投递 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点确认应答 完善的消息进行补偿机制 解决方案 消息落库，对消息状态进行打标 消息的延迟投递，做二次确认，回调检查 消息落库架构图 上图中BIZ DB为我们的业务库，比方说保存订单；MSG DB为消息库，保存我们发送到MQ消息。如果在Step 3的时候，网络出现故障，Confirm机制没有收到broker的消息确认。我们需要设置一个时间临界点，比如说5分钟，检索出消息库中状态为0的消息，通过分布式定时任务，比如XXL-Job或者Elastic-Job。但有可能出现消息刚发出去，还没有Confirm成功，定时任务就已经启动了，并把发送成功的消息确认为未成功，所以我们需要有一个Step 6,给入库消息一个最大的容忍时间，比如说2分钟到5分钟。比如消息入库的时候需要带上时间，我们取出状态为0的消息形成一个集合，然后过滤该集合的时间为2分钟以上的消息进行重新发送。由于MQ消息的配置本身有问题的情况下(比如说路由，队列，交换机)，会出现消息永远无法发送成功，这个时候我们需要有一个消息重试的机制，比如3次，如果3次都没有发送成功，则更新该消息状态为2，表示失败。 但是这种方式有一定的局限性，因为要做数据库的二次入库操作，磁盘io会成为瓶颈，在高并发的场景下并不合适。由于我们的业务入库是必须的

生产端的可靠性投递 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点确认应答 完善的消息进行补偿机制 解决方案 消息落库，对消息状态进行打标 消息的延迟投递，做二次确认，回调检查 消息落库架构图 上图中BIZ DB为我们的业务库，比方说保存订单；MSG DB为消息库，保存我们发送到MQ消息。如果在Step 3的时候，网络出现故障，Confirm机制没有收到broker的消息确认。我们需要设置一个时间临界点，比如说5分钟，检索出消息库中状态为0的消息，通过分布式定时任务，比如XXL-Job或者Elastic-Job。但有可能出现消息刚发出去，还没有Confirm成功，定时任务就已经启动了，并把发送成功的消息确认为未成功，所以我们需要有一个Step 6,给入库消息一个最大的容忍时间，比如说2分钟到5分钟。比如消息入库的时候需要带上时间，我们取出状态为0的消息形成一个集合，然后过滤该集合的时间为2分钟以上的消息进行重新发送。由于MQ消息的配置本身有问题的情况下(比如说路由，队列，交换机)，会出现消息永远无法发送成功，这个时候我们需要有一个消息重试的机制，比如3次，如果3次都没有发送成功，则更新该消息状态为2，表示失败。 但是这种方式有一定的局限性，因为要做数据库的二次入库操作，磁盘io会成为瓶颈，在高并发的场景下并不合适。由于我们的业务入库是必须的

一、Runtime.getRuntime().exec()的阻塞问题 这个问题也不能算是XXL-JOB的问题，而是Java的Runtime.getRuntime().exec()造成的，BufferedReader的缓冲区大小有限，当不能及时从缓冲区中把输出取走，那么缓冲区满了之后就会导致程序阻塞； 1、如何解决 最简单的方式就是将正常输出和异常输出使用两个不同的线程进行操作 Process process = Runtime.getRuntime().exec(command); StreamOutter errorGobbler = new StreamOutter(process.getErrorStream(), "ERROR"); // any output? StreamOutter outputGobbler = new StreamOutter(process.getInputStream(), "OUTPUT"); // kick them off errorGobbler.start(); outputGobbler.start(); // command exit process.waitFor(); public class StreamOutter extends Thread { InputStream is; String type; public

在朋友那里偶然听说到了 XXL-JOB，一个轻量级分布式任务调度平台，之前接触过 Quartz，那么这个 XXL-JOB 的优势又在哪里呢？先看下这个框架的特性以及对比 Quartz 的优势。 特性 1、简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手； 2、动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效； 3、调度中心HA（中心式）：调度采用中心式设计，“调度中心”自研调度组件并支持集群部署，可保证调度中心HA； 4、执行器HA（分布式）：任务分布式执行，任务"执行器"支持集群部署，可保证任务执行HA； 5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址； 6、弹性扩容缩容：一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务； 7、路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH、最不经常使用、最近最久未使用、故障转移、忙碌转移等； 8、故障转移：任务路由策略选择"故障转移"情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。 9、阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度； 10、任务超时控制

简述 本文简单描述如何使用xxl-job-spring-boot-starter开发xxl-job的执行器服务。 开发步骤 添加依赖 创建一个Spring Boot项目 添加依赖包 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>2.1.4.RELEASE</version> <exclusions> <!-- exclude tomcat --> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-undertow</artifactId> <version>2.1.4.RELEASE</version> </dependency> <dependency> <groupId>cn

概述 Xxl-Job 简述 XXL-JOB是一个国内轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。基于Java技术栈，调度中心与执行器通信基于作者另一个开源项目 xxl-rpc ，采用自建注册中心，整体架构简单明了，易于上手。 图片来源:http://www.xuxueli.com/xxl-job/#/?id=_533-架构图 项目地址 Github： xuxueli/xxl-job Azkaban 简述 Azkaban为LinkedIn开源的分布式工作流调度框架，项目起源于解决Hadoop Jop依赖管理问题，但实际已经是一个通用的工作流调度框架，适用于不同业务场景。 图片来源：https://github.com/azkaban/azkaban/blob/master/docs/figures/azkaban2overviewdesign.png 项目地址 Github： azkaban/azkaban Airflow 简述 Apache-Airflow 是Airbnb开源的一款数据流程工具，已经在Apache孵化成功，成为Apache的顶级项目。以非常灵活的方式来支持数据的ETL过程，同时还支持非常多的插件来完成诸如HDFS监控、邮件通知等功能。Airflow支持单机和分布式两种模式，支持Master-Slave模式，支持Mesos等资源调度