Elastic-Job

前言 前文介绍了Spring Bean的生命周期，也算是XML IOC系列的完结。但是Spring的博大精深，还有很多盲点需要摸索。整合前面的系列文章，从Resource到BeanDefinition，再到容器扩展点，最后到Bean创键，这个过程中无处不存在Spring预留的扩展口。 本篇文章介绍Spring的另一种扩展点：BeanDefinition扩展点，该扩展点是为处理BeanDefinition而设计。本文主要从以下几点分析： BeanDefinition扩展点的几种方式 BeanDefinition扩展点实战 BeanDefinition扩展点的原理 BeanDefinition扩展点的几种方式 Spring中针对向上下文中添加BeanDefinition、修改上下文中的BeanDefinition可谓是提供了丰富的扩展点。既有针对XML配置的，又有针对注解配置的Bean，甚至还有自定义XML标签的。这里总结了，共有以下几种方式： BeanDefinitionRegistryPostProcessor方式 BeanFactoryPostProcessor方式 ImportBeanDefinitionRegistrar方式 BeanDefinitionParser方式 BeanDefinitionRegistryPostProcessor方式 从命名上也可以看出一些端倪

点 击 上 方 “ 中 间 件 兴 趣 圈 ” ， 选 择 “ 设 为 星 标 ” 做 积 极 的 人 ， 越 努 力 越 幸 运 ！ 真的非常开心，『中间件兴趣圈』公众号粉丝数正式迈过1W大关，达成一个重要里程碑，笔者感慨真的不容易。 2018年10月19号通过公众号发布第一篇文章，到今天为止，公众号已经发表了145篇原创文章，坚持真的很难，但只要能坚持，就一定会有好的收获，这不，你瞧，1W个人与你一起同行，这成就不可谓不大。 在持续坚持努力下，我出版了《RocketMQ技术内幕》一书，从一家名不经传的小公司顺利跳槽到快递物流头部企业：中通快递，让我能在更高的平台上发光发热，使我深深的认识到： 越努力越幸运，唯有坚持不懈 。希望能用这句话与各位粉丝朋友共勉，相互交流，共同成长。 相信各位读者朋友们也能直观的感受到『中间件兴趣圈』主要发表的文章都比较枯燥，因为大部分都是以源码分析为主，认真读完一篇文章需要极大的耐心，我从后台的统计数据上看到，每篇文章的读完率其平均值在50%左右，这足以说明大家拥有强烈的求知欲望，这里必须有掌声，为各自点个赞吧。与各位优秀的读者同行，是我的一大荣幸，未来继续加油。 『中间件兴趣圈』的定位是记录笔者的学习历程与成长历程，同时也起到驱动笔者去学习，给自己提的要求是尽最大努力保证一周一篇原创文章。 绝不注水、绝不洗稿，这是我的初心也是底线。 『中间件兴趣圈

做 积 极 的 人 ， 越 努 力 越 幸 运 ！ 真的非常开心，『中间件兴趣圈』公众号粉丝数正式迈过1W大关，达成一个重要里程碑，笔者感慨真的不容易。 2018年10月19号通过公众号发布第一篇文章，到今天为止，公众号已经发表了145篇原创文章，坚持真的很难，但只要能坚持，就一定会有好的收获，这不，你瞧，1W个人与你一起同行，这成就不可谓不大。 在持续坚持努力下，我出版了《RocketMQ技术内幕》一书，从一家名不经传的小公司顺利跳槽到快递物流头部企业：中通快递，让我能在更高的平台上发光发热，使我深深的认识到： 越努力越幸运，唯有坚持不懈 。希望能用这句话与各位粉丝朋友共勉，相互交流，共同成长。 相信各位读者朋友们也能直观的感受到『中间件兴趣圈』主要发表的文章都比较枯燥，因为大部分都是以源码分析为主，认真读完一篇文章需要极大的耐心，我从后台的统计数据上看到，每篇文章的读完率其平均值在50%左右，这足以说明大家拥有强烈的求知欲望，这里必须有掌声，为各自点个赞吧。与各位优秀的读者同行，是我的一大荣幸，未来继续加油。 『中间件兴趣圈』的定位是记录笔者的学习历程与成长历程，同时也起到驱动笔者去学习，给自己提的要求是尽最大努力保证一周一篇原创文章。 绝不注水、绝不洗稿，这是我的初心也是底线。 『中间件兴趣圈』现阶段主要以源码分析为手段成体系剖析JAVA主流中间件

1、首先添加引用 <!-- https://mvnrepository.com/artifact/com.dangdang/elastic-job-lite-core --> <!-- 有 elastic-job-lite-spring 就不需要下面这个 pom 引用了，因为已经包含了 --> <!-- <dependency>--> <!-- <groupId>com.dangdang</groupId>--> <!-- <artifactId>elastic-job-lite-core</artifactId>--> <!-- <version>2.1.5</version>--> <!-- </dependency>--> <!-- https://mvnrepository.com/artifact/com.dangdang/elastic-job-lite-spring --> <dependency> <groupId> com.dangdang </groupId> <artifactId> elastic-job-lite-spring </artifactId> <version> 2.1.5 </version> </dependency> 2、添加配置文件信息。 server : port : 8081 elasticjob : regCenter :

大家都知道，做我们开发这行的，最核心的竞争力就是学习能力。技术一直在变化，框架一直在更新，学还是不学。 不学，你会落伍，学，太累了，根本学不过来。学习只要找对了方法，也没那么累。 最好的学习方式那就是兴趣驱使你去学习，但这种几乎很少，还有一种就是群体学习，就是大家一起学习，有问题一起讨论，这样的方式学起来会很轻松，这条路上的人多了，并不孤单。 知识星球是干嘛的？ • 知识星球是我跟大家分享，交流技术的小圈子。 • 在这里可以交流技术，工作中遇到的问题。 • 我也会定期分享自己的心得和技术文章。 • 核心就是一起学习，讨论后端技术。主要是Java方向的哈！ 有个圈子可以组队学习新技术，分享学习经验，面试经验，工作经验，理财经验等有益于成长的知识。这是我对知识星球的理解。 我希望加入星球的朋友们可以养成习惯，每日打卡，分享自己每天的学习成果，久而久之，学习将不再是一种负担，而是一种习惯。 后续计划 如果真的有更多的朋友愿意加入进来，后面我们可以一起学习，现在就已经开始了，第一个主题是阿里的Sentinel ，目前就我一个人在打卡，还没见到其他球友的打开记录，不过目前人也比较少。 还有就是我会通过各种激励的方式鼓励大家去学习，去分享，去总结，然后用奖品的方式来支持大家，比如赠书，发红包等方式，当然这个取决于后面星球的规模，规模大的话次数多点，规模小的话次数少点，但是肯定会做下去的

Java中的定时任务 现代的应用程序早已不是以前的那些由简单的增删改查拼凑而成的程序了，高复杂性早已是标配，而任务的定时调度与执行也是对程序的基本要求了。 很多业务需求的实现都离不开定时任务，例如，每月一号，移动将清空你上月未用完流量，重置套餐流量，以及备忘录提醒、闹钟等功能。 Java 系统中主要有三种方式来实现定时任务： • Timer和TimerTask • ScheduledExecutorService • 三方框架 Quartz 下面我们一个个来看。 Timer和TimerTask 先看一个小 demo，接着我们再来分析其中原理： 这种方式的定时任务主要用到两个类，Timer 和 TimerTask。其中，TimerTask 继承接口 Runnable，抽象的描述一种任务类型，我们只要重写实现它的 run 方法就可以实现自定义任务。 而 Timer 就是用于定时任务调度的核心类，demo 中我们调用其 schedule 并指定延时 1000 毫秒，所以上述代码会在一秒钟后完成打印操作，接着程序结束。 那么，使用上很简单，两个步骤即可，但是其中的实现逻辑是怎样的呢？ Timer 接口 首先，Timer 接口中，这两个字段是非常核心重要的： TaskQueue 是一个队列，内部由动态数组实现的最小堆结构，换句话说，它是一个优先级队列。而优先级参考下一次执行时间

1 、什么是分布式任务调度？ 任务调度是指基于给定的时间点，给定的时间间隔或者给定执行次数自动的执行任务。任务调度是是操作系统的重要组成部分，而对于实时的操作系统，任务调度直接影响着操作系统的实时性能。任务调度涉及到多线程并发、运行时间规则定制及解析、线程池的维护等诸多方面的工作。 WEB 服务器在接受请求时，会创建一个新的线程服务。但是资源有限，必须对资源进行控制，首先就是限制服务线程的最大数目，其次考虑以线程池共享服务的线程资源，降低频繁创建、销毁线程的消耗；然后任务调度信息的存储包括运行次数、调度规则以及运行数据等。一个合适的任务调度框架对于项目的整体性能来说显得尤为重要。 2 、常见的任务调度框架有哪些？ 我们在实际的开发工作中，或多或少的都会用到任务调度这个功能。常见的分布式任务调度框架有： cronsun 、 Elastic-job 、 saturn 、 lts 、 TBSchedule 、 xxl-job 、 Quartz 等。 在这里我们着重介绍 elastic-job 和 xxl-job 4 、业务场景 当 我们遇到定期任务，比如订单 30 分钟后自动回收 定期执行任务：如每天 0 点做资源稽查； Elastic-job ： elastic-Job 是当当开源的一个分布式调度解决方案，由两个相互独立的子项目 Elastic-Job-Lite 和 Elastic

1.业务场景 保险人管系统每月工资结算，平安有150万代理人，如何快速的进行工资结算(数据运算型) 保险短信开门红/电商双十一 1000w+短信发送(短时汇聚型) 工作中业务场景非常多，所涉及到的场景也各不相同，这使得我们定时任务系统应该集管理、调度、任务分配、监控预警为一体的综合调度系统,如何打造一套健壮的、适应不同场景的系统，技术选型尤其重要。 针对以上场景我们需要我们的分布式任务系统具备以下能力： 1.支持多种作业类型(shell作业/Java作业) 2.支持作业HA，负载均衡和失败转移 3.支持弹性扩容(应对开门红以及促销活动) 4.支持Job Timeout 处理 5.支持统一监控和告警 6.支持作业统一配置 7.支持资源隔离和作业隔离 2.定时任务调度的特点 任务调度就是设点某一时间点自动触发的任务，该任务可以在时间规律上去循环执行。一般的技术quartz、spring task、java.util.Timer，这几种如果在单一机器上跑其实问题不大，但是如果一旦应用于集群环境做分布式部署，就会带来一个致命的问题，那就是重复执行，当然解决方案有，但是必须依赖数据库，将任务执行状态持久化下来。 特点： 时间驱动：系统一般可以通过时间来驱动，定时定点定次。 批量处理：批量处理堆积的数据更加高效，在不需要实时性的情况下比消息中间件更有优势。而且有的业务逻辑只能批量处理

1什么是分布式任务调度 1.1任务举例-定时任务 1.1.1实际案例 1.1.1.1网贷-日终任务 1.1.1.2其它业务-全日频繁 1.1.1.3 Crontab、shell 1.2产生问题 PK 解决问题 1.2.1迎面遇到第一个问题：集群重复执行 每台虚机在同一时间都会执行定时任务： Tomcat Nginx Tomcat 尝试解决：将任务单独拆出放入一台虚机(TASK)。 Nginx Tomcat TASK Tomcat 产生新的问题： 1.即便TASK 100%可靠永远不宕。也有极大的停机风险，不确定在停机期间是否有任务被遗漏( misfire )。 2.任务更多，更复杂，占越来越多的资源，性能问题凸显，任务队列阻塞风险。 1.2.2Quartz集群 Nginx Tomcat Tomcat DB(quartz) 之后看了眼quartz官方logo，感觉自己萌萌的。 1.2.3管理、调度任务产生问题 萌不过三天。发现这个定时任务策略要修改， 同样，下面这个任务不需要做，取消掉 也无法及时监控：报错了吗，运行成功了吗？ 随着业务发展暴露出越来越多的问题： 例如： ---- 截图摘自沈建林“分布式调度系统介绍”中的五个问题 1.2.4解决问题 解决问题 解决问题 集思广益造轮子： Quartz，Xxl-job，elastic-job，tbschedule，uncode

分布式定时任务调度系统技术解决方案(xxl-job、Elastic-job、Saturn) 参考文章： （1）分布式定时任务调度系统技术解决方案(xxl-job、Elastic-job、Saturn) （2）https://www.cnblogs.com/rainswinds/p/10930495.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4438370/blog/4651504