Elastic-Job

长按二维码，关注我们 老文章，由于之前手误被删除了，重新发出来 Elastic-Job是什么？ Elastic-Job是一个分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。 Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务；Elastic-Job-Cloud采用自研Mesos Framework的解决方案，额外提供资源治理、应用分发以及进程隔离等功能。 官网地址： http://elasticjob.io/ Github： https://github.com/elasticjob/elastic-job 为什么要使用Elastic-Job 目前我们公司用的是基于Linux Crontab的定时任务执行器。 存在如下问题： 无法集中管理任务 不能水平扩展 无可视化界面操作 存在单点故障 除了Linux Crontab在java这块的方案还有 Quartz，但 Quartz缺少分布式并行调度的功能。 存在的问题也很明显： 当我的项目是一个单体应用时，在里面基于Quartz起一个定时任务，可以很愉快的运行 当我的项目做了负载，扩充到3台节点时，3个节点上的任务会同时执行，数据乱了 同时执行要保证数据没问题需要引入分布式锁来调度，难度增大 怎么解决? 1.自研框架

Spring Cloud构建微服务系统性源码 spring-cloud： https://github.com/yinjihuan/spring-cloud Smconf专注于分布式环境下配置的统一管理 smconf： https://github.com/yinjihuan/smconf Elastic-Job Spring Boot 自动集成，只需要一个注解即可发布Job。 elastic-job-spring-boot-starter： https://github.com/yinjihuan/elastic-job-spring-boot-starter Spring Boot中增强Mongodb的配置，多数据源，连接池等 spring-boot-starter-mongodb-pool： https://github.com/yinjihuan/spring-boot-starter-mongodb-pool Smjdbctemplate基于Spring Jdbctemplate 做的升级版 Smjdbctemplate： https://github.com/yinjihuan/smjdbctemplate Spring Boot集成Dubbox spring-boot-starter-dubbox： https://github.com/yinjihuan

本文源码： GitHub·点这里 || GitEE·点这里 一、ElasticJob简介 1、定时任务 在前面的文章中，说过QuartJob这个定时任务，被广泛应用的定时任务标准。但Quartz核心点在于执行定时任务并不是在于关注的业务模式和场景，缺少高度自定义的功能。Quartz能够基于数据库实现任务的高可用，但是不具备分布式并行调度的功能。 -> QuartJob定时任务 2、ElasticJob说明 基础简介 Elastic-Job 是一个开源的分布式调度中间件，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。Elastic-Job-Lite 为轻量级无中心化解决方案，使用 jar 包提供分布式任务的调度和治理。 Elastic-Job-Cloud 是一个 Mesos Framework，依托于Mesos额外提供资源治理、应用分发以及进程隔离等服务。 功能特点 分布式调度协调 弹性扩容缩容 失效转移 错过执行作业重触发 作业分片一致性，保证同一分片在分布式环境中仅一个执行实例 补刀 ：人家官网这样描述的，这里赘述一下，充实一下文章。 基础框架结构 该图片来自ElasticJob官网。 由图可知如下内容： 需要Zookeeper组件支持，作为分布式的调度任务，有良好的监听机制，和控制台，下面的案例也就冲这个图解来。 3

昨天虽然试用了一下唯品会的“土星”，但是我实在没想明白他的Job该怎么用Spring来托管，所以没有使用。今天来说一下当当的Elastic-Job. 安装管理平台 先说一下Elastic-Job的管理平台跟Java的Job开发没有半毛钱关系，他只是把注册进Zookeeper的信息读取出来，进行控制。 先下载Elastic-Job的源代码git clone https://github.com/elasticjob/elastic-job-lite.git，编译之后找到elastic-job-lite-console-3.0.0.M1-SNAPSHOT.tar.gz上传到服务器，解压之后进入/bin目录。 先不要急着执行start.sh，因为这个文件里面有Windows字符，linux无法识别。 所以先执行 sed -i 's/\r$//' start.sh 改掉Windows字符。 然后执行nohup ./start.sh & 在浏览器打开服务器的8899端口(用户名root，密码root) 先配置好zookeeper的注册中心地址，命名空间，基本上这个就装好了。 编写Java Job pom <dependency> <groupId>com.github.kuhn-he</groupId> <artifactId>elastic-job-lite-spring-boot

Elastic-Job <dependency> <groupId>com.dangdang</groupId> <artifactId>elastic-job-lite-core</artifactId> <version>2.1.5</version> </dependency> public class MessagePushJob implements SimpleJob { @Override public void execute(ShardingContext shardingContext) { System.out.println(shardingContext); } } public class Startup { public static void main(String[] args) { new JobScheduler(createRegistryCenter(), createJobConfiguration()).init(); } private static CoordinatorRegistryCenter createRegistryCenter() { CoordinatorRegistryCenter regCenter = new ZookeeperRegistryCenter(new ZookeeperConfiguration(

生产端的可靠性投递 保障消息的成功发出 保障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会成为瓶颈，在高并发的场景下并不合适。由于我们的业务入库是必须的

分布式系统经常要遇到定时任务执行的问题，不能重复执行，但很多时候又不能统一到一个微服务里面，因为这样就失去了微服务的意义。由于我的系统只有寥寥几个定时任务，而且都是按天执行的，我就弄了这么个小东西来控制分布式定时任务。 我使用的redis分布式锁来控制分布式定时任务的方式，实际上适用于定时任务较少的情况，而且不适用于瞬时反复执行的定时任务。这种情况下，如果加上分布式定时任务框架，如Elastic-Job这种，显然就很重了，所以这是一个极轻量级的方式。这种方式显然很难支持作业分片、失效转移、重新触发执行以及执行过程中服务挂掉之后的重新执行。所以使用这种方式要慎重，如果系统存在后续定时任务大规模扩展、定时任务需要分片或者有瞬时反复执行的定时任务等情况，则这种简单的方式就不适用了。 原理其实很简单，各个微服务系统同时向redis申请加锁，由于redis是单线程的，所以只能有一个加锁成功，然后后面的全部得不到锁。得到锁的执行定时任务，得不到的，就放弃执行定时任务。 为啥要用lua脚本呢？因为好用啊，亲，操作的原子性能得到保证。 小demo： @Test public void testgg(){ try{ jedisCluster.del("schedule:lock:sss"); String dateStr = new SimpleDateFormat("yyyyMMddHHmmss"

关于spring boot 实现任务调度的方法有很多种，这里不再赘述。 首先pom只需引入 <dependency> <groupId>org.quartz-scheduler</groupId> <artifactId>quartz</artifactId> <version>2.2.1</version> </dependency> 然后application开启@EnableScheduling @SpringBootApplication @EnableAsync @EnableScheduling public class Application extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { return application.sources(Application.class); } public static void main(String[] args) throws Exception { SpringApplication.run(Application.class, args); } } 之后用嘛就很简单了 @Component

一、前言 Elastic-Job是一个优秀的分布式作业调度框架。 Elastic-Job是一个分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。 Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。 Elastic-Job-Cloud使用Mesos + Docker的解决方案，额外提供资源治理、应用分发以及进程隔离等服务。 1. Elastic-Job-Lite 分布式调度协调 弹性扩容缩容 失效转移 错过执行作业重触发 作业分片一致性，保证同一分片在分布式环境中仅一个执行实例 自诊断并修复分布式不稳定造成的问题 支持并行调度 支持作业生命周期操作 丰富的作业类型 Spring整合以及命名空间提供 运维平台 2. Elastic-Job-Cloud 应用自动分发 基于Fenzo的弹性资源分配 分布式调度协调 弹性扩容缩容 失效转移 错过执行作业重触发 作业分片一致性，保证同一分片在分布式环境中仅一个执行实例 支持并行调度 支持作业生命周期操作 丰富的作业类型 Spring整合 运维平台 基于Docker的进程隔离(TBD) 二、导读 1、Elastic-Job的核心思想 2、Elastic-Job的基本使用 三、Elastic-Job的核心思想 对于分布式计算而言