在很多场景我们需要用到延时任务，比如给客户异步转账操作超时后发通知告知用户，还有客户下单后多长时间内没支付则取消订单等等，这些都可以使用延时任务来实现。
延时队列：顾名思义，是一个用于做消息延时消费的队列。但是它也是一个普通队列，所以它具备普通队列的特性，相比之下，延时的特性就是它最大的特点。所谓的延时就是将我们需要的消息，延迟多久之后被消费。普通队列是即时消费的，延时队列是根据延时时间，多久之后才能消费的。
例如：pdd下单,但是没有付款,那么24小时候，订单会自动取消。收货后，如果一直不进行确认，那么默认七天后自动确认收货等等。
由于最近在使用Spring Cloud的Zuul网关的过程中，发现超时的可能性很多，出于性能的调优，所有想通过测试，了解一些参数的作用。在文章最后贴上推荐方案。
2.获取mntr的信息，缓存conf就是conf信息，可以找出监控项并且监控，搭配zabbix监控 echo mntr | nc 127.0.0.1 2181
第一次执行任务的延时时间（initialDelay），周期执行的时间间隔（period）。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
本节探讨定时任务，定时任务的应用场景是非常多的，比如： 闹钟程序或任务提醒，指定时间叫床或在指定日期提醒还信用卡 监控系统，每隔一段时间采集下系统数据，对异常事件报警 统计系统，一般凌晨一定时间统计昨日的各种数据指标 在Java中，有两种方式实现定时任务： 使用java.util包中的Timer和TimerTask 使用Java并发包中的ScheduledExecutorService 它们的基本用法都是比较简单的，但如果对它们没有足够的了解，则很容易陷入其中的一些陷阱，下面，我们就来介绍它们
* 按时间顺序发生的数据1 -> 2，本来应该是1先发送，1先到达，但是在1发送过程中，因为网络延时之类的原因，导致1反而到达晚了，变成2先到达，也就造成所谓的接收乱序；
继之前用rabbitMQ实现延时队列，Redis由于其自身的Zset数据结构，也同样可以实现延时的操作
这些情况都可以使用延时队列来做，实现延时队列比较场景的有使用消息队列MQ来实现，比如RocketMQ等等，也可以使用Redis来实现，本博客主要介绍一下Redis实现延时队列
DelayQueue 是BlockingQueue接口的实现类，它根据"延时时间"来确定队列内的元素的处理优先级（即根据队列元素的“延时时间”进行排序）。另一层含义是只有那些超过“延时时间”的元素才能从队列里面被拿出来进行处理。
这里为了方便，采用spring-boot-starter-data-redis来快速完成对redis客户端的搭建工作。
延迟队列，想必大家都不陌生，顾名思义，它是一个带有延迟功能的队列。那么到底为什么需要延迟，怎么延迟呢？考虑一下下面的应用场景。
本节，我们来探讨Java并发包中的各种队列。Java并发包提供了丰富的队列类，可以简单分为： 无锁非阻塞并发队列：ConcurrentLinkedQueue和ConcurrentLinkedDeque 普通阻塞队列：基于数组的ArrayBlockingQueue，基于链表的LinkedBlockingQueue和LinkedBlockingDeque 优先级阻塞队列：PriorityBlockingQueue 延时阻塞队列：DelayQueue 其他阻塞队列：SynchronousQueue和LinkedT
地址：www.cnblogs.com/xiaowei123/p/13222710.html
DelayedQueue是一个无界阻塞队列，内部有一个优先队列，当使用put方法添加元素到DelayQueue时，会塞一个延时条件，DelayedQueue会按照延时条件排序，最先过期的排在队首，只有元素过期了，才能从队首取出数据，取出数据的方法有take和poll
Java的线程池是块硬骨头，对线程池的源码做深入研究不仅能提高对Java整个并发编程的理解，也能提高自己在面试中的表现，增加被录取的可能性。
通过前面两篇文章，我们对队列有了了解及已经认识了常用阻塞队列中的三个了。本篇我们继续介绍剩下的几个队列。
一个男人只能有一个媳妇「正常情况」，一个人只能有一张嘴，通常一个公司只有一个 CEO ，一个狼群中只有一个狼王等等
利用JDK自带的DelayQueue来实现， 无界阻塞队列，该队列只有在延迟期满的时候才能从中获取元素，放入DelayQueue中的对象，必须实现Delayed接口。
现代的应用程序早已不是以前的那些由简单的增删改查拼凑而成的程序了，高复杂性早已是标配，而任务的定时调度与执行也是对程序的基本要求了。
前面我们一起学习了普通任务、未来任务的执行流程，今天我们再来学习一种新的任务——定时任务。
在开发中经常会遇到延时任务的需求，例如在12306购买车票，若生成订单30分钟未支付则自动取消；还有在线商城完成订单后48小时不评价 ，自动5星好评。像这类在某事件触发后一段时间内执行的需求任务我们称之为 延时任务。
在生产者投递消息时指定mandatory或者imrnediate参数设为 true 时，RabbitMQ 会把无法投递的消息通过Basic.Return 命令将消息返回给生产者，此时生产者需要调用channel.addReturnListener 来添加 ReturnListener 监昕器实现监听投递失败的消息
注意这里的场景是延时，不是定时。当然，解决了延时，定时就很简单了（定时=当前时刻+间隔时间）。
关于redis分布式锁, 查了很多资料, 发现很多只是实现了最基础的功能, 但是, 并没有解决当锁已超时而业务逻辑还未执行完的问题, 这样会导致: A线程超时时间设为10s(为了解决死锁问题), 但代码执行时间可能需要30s, 然后redis服务端10s后将锁删除, 此时, B线程恰好申请锁, redis服务端不存在该锁, 可以申请, 也执行了代码, 那么问题来了, A、B线程都同时获取到锁并执行业务逻辑, 这与分布式锁最基本的性质相违背: 在任意一个时刻, 只有一个客户端持有锁, 即独享。
这个太简单了，就是在查询的时候判断是否失效，如果失效了就给他设置失效状态。但是弊端也很明显，每次查询都要对未失效的订单做判断，如果用户不查询，订单就不失效，那么如果有类似统计失效状态个数的功能，将会受到影响，所以只能适用于简单独立的场景。简直low爆了。
下单后,30分钟内未付款就自动取消订单等； 支付后，24小时未评论自动好评； 在我们实际开发过程中，应用场景很多...
定时/延时消息在业务开发中使用非常广泛，比如分布式定时调度（在分布式定时调度场景下，需要实现各类精度的定时任务，例如每天5点执行文件清理，每隔2分钟触发一次消息推送等需求）和任务超时处理（以电商交易场景为例，订单下单后暂未支付，此时不可以直接关闭订单，而是需要等待一段时间后才能关闭订单）。
上篇文章介绍了RocketMQ整体架构和原理有兴趣的可以阅读一下，在这篇文章中的延时消息部分，我写道开源版的RocketMQ只提供了18个层级的消息队列延时，这个功能在开源版中显得特别鸡肋，但是在阿里云中的RocketMQ却提供了支持40天之内任意秒级延时队列，果然有些功能你只能充钱才能拥有。当然你或许想换一个开源的消息队列，在开源社区中消息队列延时消息很多都没有被支持比如：RabbitMQ,Kafka等，都只能通过一些特殊方法才能完成延时的功能。为什么这么多都没有实现这个功能呢？是因为技术难度比较复杂吗？接下来我们分析一下如何才能实现一个延时消息。
java.util.concurrent.ScheduledThreadPoolExecutor 是 JDK1 .6之后自带的 包，功能强大，能实现定时器和延时加载的功能
饿汉式的单例实现方式就是说在类加载的时候就已经创建并初始化好了，所以实例的创建过程是线程安全的
public interface BlockingQueue<E> extends Queue<E> {
死信队列实现篇，参考文章：【SpringBoot】60、SpringBoot中整合RabbitMQ实现延时队列（死信队列篇）
ActiveMQ的延时消息是一个让人又爱又恨的功能，具体使用可参考上篇ActiveMQ笔记(6)：消息延时投递，在很多需要消息延时投递的业务场景十分有用，但是也有一个缺陷，在一些大访问量的场景，如果瞬间向MQ发送海量的延时消息，超过MQ的调度能力，就会造成很多消息到了该投递的时刻，却没有投递出去，形成积压，一直停留在ActiveMQ web控制台的Scheduled面板中。 下面的代码演示了，如何清理activemq中的延时消息（包括：全部清空及清空指定时间段的延时消息），这也是目前唯一可行的办法。 为了演
广播模式：每个队列绑定到Exchange(交换机) 交换机把消息发送给绑定的所有队列
https://www.cnblogs.com/poloyy/category/1814570.html
双击退出程序的原理无非就是设置一个退出标识（询问是否退出），如果改变了这个标识（确认退出），则再次点击时立马退出，如果规定时间内没有退出，则延时重置这个标识（不退出）。
最近1-2周, 业务侧基于性能和一致性的需求，测试和验证基于sofa-jraft的框架。由于上线后事关生产环境的稳定性，于是加入调研jraft/raft相关领域调研，确保生产环境即使在极端情况下，也在我们考量的范围之内。
核心功能 提供重试工具类， 支持传入操作、重试次数和延时时间。 支持定义不再重试的异常和条件。
我们都知道Redis是一种基于内存的单进程单线程数据库（Redis6.0开始之后支持多线程啦！），处理速度都非常快。那么为何Redis又能慢呢？原来，这里说的慢是指Redis可以设置一些参数达到慢处理的结果。
后面了解到包括Java单机版的DelayQueue以及RabbitMQ延时队列/延迟重试等相对更靠谱一些。
rabbitMq是受欢迎的消息中间件之一，相比其他的消息中间件，具有高并发的特性（天生具备高并发高可用的erlang语言编写），除此之外，还可以持久化，保证消息不易丢失，高可用，实现集群部署，提供灵活的路由和可靠性，可视化管理等等的优点。
之前写过两篇关于WAF分块传输绕过内容对文章，对于分块传输不太熟悉的可以先看前两篇内容，本篇文章也是在其基础内容上进行扩充。
小结：不建议使用双重锁判定机制，单例对象、资源占用少，枚举要比饿汉好，目前用的较多的是枚举。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
