延时任务最佳实践方案总结
https://mp.weixin.qq.com/s/yDeH0ei6Sq4zos11K0I9Rg
一、应用场景
在需求开发过程中，我们经常会遇到一些类似下面的场景：
a. 外卖订单超过15分钟未支付，自动取消
b. 使用抢票软件订到车票后，1小时内未支付，自动取消
c. 待处理申请超时1天，通知审核人员经理，超时2天通知审核人员总监
d. 客户预定自如房子后，24小时内未支付，房源自动释放
二、JDK 延时队列实现
DelayQueue 是 JDK 中 java.util.concurrent 包下的一种无界阻塞队列，底层是优先队列 PriorityQueue。对于放到队列中的任务，可以按照到期时间进行排序，只需要取已经到期的元素处理即可。
具体的步骤是，要放入队列的元素需要实现 Delayed 接口并实现 getDelay 方法来计算到期时间，compare 方法来对比到期时间以进行排序。一个简单的使用例子如下：
package com.lyqiang.delay.jdk;
import java.time.LocalDateTime;
import java.util.concurrent.DelayQueue;
import java.util.concurrent.Delayed;
import java.util.concurrent.TimeUnit;
/**
* @author lyqiang
*/
public class TestDelayQueue {
public static void main(String[] args) throws InterruptedException {
// 新建3个任务，并依次设置超时时间为 20s 10s 30s
DelayTask d1 = new DelayTask(1, System.currentTimeMillis() + 20000L);
DelayTask d2 = new DelayTask(2, System.currentTimeMillis() + 10000L);
DelayTask d3 = new DelayTask(3, System.currentTimeMillis() + 30000L);
DelayQueue<DelayTask> queue = new DelayQueue<>();
queue.add(d1);
queue.add(d2);
queue.add(d3);
int size = queue.size();
System.out.println("当前时间是：" + LocalDateTime.now());
// 从延时队列中获取元素， 将输出 d2 、d1 、d3
for (int i = 0; i < size; i++) {
System.out.println(queue.take() + " ------ " + LocalDateTime.now());
}
}
}
class DelayTask implements Delayed {
private Integer taskId;
private long exeTime;
DelayTask(Integer taskId, long exeTime) {
this.taskId = taskId;
this.exeTime = exeTime;
}
@Override
public long getDelay(TimeUnit unit) {
return exeTime - System.currentTimeMillis();
}
@Override
public int compareTo(Delayed o) {
DelayTask t = (DelayTask) o;
if (this.exeTime - t.exeTime <= 0) {
return -1;
} else {
return 1;
}
}
@Override
public String toString() {
return "DelayTask{" +
"taskId=" + taskId +
", exeTime=" + exeTime +
'}';
}
}
代码的执行结果如下：
使用 DelayQueue, 只需要有一个线程不断从队列中获取数据即可，它的优点是不用引入第三方依赖，实现也很简单，缺点也很明显，它是内存存储，对分布式支持不友好，如果发生单点故障，可能会造成数据丢失，无界队列还存在 OOM 的风险。
三、时间轮算法实现
1996 年 George Varghese 和 Tony Lauck 的论文《Hashed and Hierarchical Timing Wheels: Data Structures for the Efficient Implementation of a Timer Facility》中提出了一种时间轮管理 Timeout 事件的方式。其设计非常巧妙，并且类似时钟的运行，如下图的原始时间轮有 8 个格子，假定指针经过每个格子花费时间是 1 个时间单位，当前指针指向 0，一个 17 个时间单位后超时的任务则需要运转 2 圈再通过一个格子后被执行，放在相同格子的任务会形成一个链表。
Netty 包里提供了一种时间轮的实现——HashedWheelTimer，其底层使用了数组+链表的数据结构，使用方式如下：
package com.lyqiang.delay.wheeltimer;
import io.netty.util.HashedWheelTimer;
import java.time.LocalDateTime;
import java.util.concurrent.TimeUnit;
/**
* @author lyqiang
*/
public class WheelTimerTest {
public static void main(String[] args) {
//设置每个格子是 100ms, 总共 256 个格子
HashedWheelTimer hashedWheelTimer = new HashedWheelTimer(100, TimeUnit.MILLISECONDS, 256);
//加入三个任务，依次设置超时时间是 10s 5s 20s
System.out.println("加入一个任务，ID = 1, time= " + LocalDateTime.now());
hashedWheelTimer.newTimeout(timeout -> {
System.out.println("执行一个任务，ID = 1, time= " + LocalDateTime.now());
}, 10, TimeUnit.SECONDS);
System.out.println("加入一个任务，ID = 2, time= " + LocalDateTime.now());
hashedWheelTimer.newTimeout(timeout -> {
System.out.println("执行一个任务，ID = 2, time= " + LocalDateTime.now());
}, 5, TimeUnit.SECONDS);
System.out.println("加入一个任务，ID = 3, time= " + LocalDateTime.now());
hashedWheelTimer.newTimeout(timeout -> {
System.out.println("执行一个任务，ID = 3, time= " + LocalDateTime.now());
}, 20, TimeUnit.SECONDS);
System.out.println("等待任务执行===========");
}
}
代码执行结果如下：
四、Redis ZSet 实现
Redis 里有 5 种数据结构，最常用的是 String 和 Hash，而 ZSet 是一种支持按 score 排序的数据结构，每个元素都会关联一个 double 类型的分数，Redis 通过分数来为集合中的成员进行从小到大的排序，借助这个特性我们可以把超时时间作为 score 来将任务进行排序。
使用 zadd key score member 命令向 redis 中放入任务，超时时间作为 score, 任务 ID 作为 member, 使用 zrange key start stop withscores 命令从 redis 中读取任务，使用 zrem key member 命令从 redis 中删除任务。代码如下：
package com.lyqiang.delay.redis;
import java.time.LocalDateTime;
import java.util.Set;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
/**
* @author lyqiang
*/
public class TestRedisDelay {
public static void main(String[] args) {
TaskProducer taskProducer = new TaskProducer();
//创建 3个任务，并设置超时间为 10s 5s 20s
taskProducer.produce(1, System.currentTimeMillis() + 10000);
taskProducer.produce(2, System.currentTimeMillis() + 5000);
taskProducer.produce(3, System.currentTimeMillis() + 20000);
System.out.println("等待任务执行===========");
//消费端从redis中消费任务
TaskConsumer taskConsumer = new TaskConsumer();
taskConsumer.consumer();
}
}
class TaskProducer {
public void produce(Integer taskId, long exeTime) {
System.out.println("加入任务， taskId: " + taskId + ", exeTime: " + exeTime + ", 当前时间：" + LocalDateTime.now());
RedisOps.getJedis().zadd(RedisOps.key, exeTime, String.valueOf(taskId));
}
}
class TaskConsumer {
public void consumer() {
Executors.newSingleThreadExecutor().submit(new Runnable() {
@Override
public void run() {
while (true) {
Set<String> taskIdSet = RedisOps.getJedis().zrangeByScore(RedisOps.key, 0, System.currentTimeMillis(), 0, 1);
if (taskIdSet == null || taskIdSet.isEmpty()) {
//System.out.println("没有任务");
} else {
taskIdSet.forEach(id -> {
long result = RedisOps.getJedis().zrem(RedisOps.key, id);
if (result == 1L) {
System.out.println("从延时队列中获取到任务，taskId:" + id + " , 当前时间：" + LocalDateTime.now());
}
});
}
try {
TimeUnit.MILLISECONDS.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
});
}
}
执行结果如下：
相比前两种实现方式，使用 Redis 可以将数据持久化到磁盘，规避了数据丢失的风险，并且支持分布式，避免了单点故障。
五、MQ 延时队列实现
以 RabbitMQ 为例，它本身并没有直接支持延时队列的功能，但是通过一些特性，我们可以达到实现延时队列的效果。
RabbitMQ 可以为 Queue 设置 TTL,，到了过期时间没有被消费的消息将变为死信——Dead Letter。我们还可以为Queue 设置死信转发 x-dead-letter-exchange，过期的消息可以被路由到另一个 Exchange。下图说明了这个流程，生产者通过不同的 RoutingKey 发送不同过期时间的消息，多个队列分别消费并产生死信后被路由到 exe-dead-exchange，再有一些队列绑定到这个 exchange，从而进行不同业务逻辑的消费。
使用 MQ 实现的方式，支持分布式，并且消息支持持久化，在业内应用比较多，它的缺点是每种间隔时间的场景需要分别建立队列。
六、总结
通过上面不同实现方式的比较，可以很明显的看出各个方案的优缺点，在分布式系统中我们会优先考虑使用 Redis 和 MQ 的实现方式。
在需求开发中实现一个功能的方式多种多样，需要我们进行多维度的比较，才能选择出合理的、可靠的、高效的并且适合自己业务的解决方案。
https://mp.weixin.qq.com/s/VqXjGvfMunE4DWGXOOXVWg
引言
很多时候，业务系统有延时处理任务的需求，当任务量很大时，可能需要维护大量的定时器，或者进行低效的扫描。例如：电商下单成功后60s之后给用户发送短信通知；电商下单后30分钟未支付，自动取消订单；出行乘客叫单后30秒没有司机接单，重新给周边司机推单等。实现这类需求有一些常见方案。
在讨论方案前我们需要搞清楚，延时任务与定时任务究竟有啥区别？定时任务有明确的执行时间或周期性，比如定时充电，要选开始充电的具体时间点，再比如每10分钟做一次未支付订单的状态检查。而延时任务没有这些特性，它具有不确定性，是在某个事件触发后一段时间内执行。
下面以“出行乘客叫单后30秒内没有司机接单，重新给周边司机推单，直到司机接单”为例，讲解每种方案的实现。
方案分析
一、轮询扫描
启动一个Timer，30秒间隔轮询扫描订单表，检查每个未接订单创建时间是否超过30秒的整数倍，如果超过，重新给周边司机推送订单。
优点：简单易行。
缺点：如果订单量过大，延迟会比较高。
适用范围：这种方案一般适用于延时任务量比较少，对于延时精确度要求不高的任务。
二、多Timer触发
为每个订单创建一个Timer，并且设置为30秒的触发时间间隔，事件触发后检查订单状态，如果是初始状态，则继续执行，否则停止并释放Timer。
优点：简单易行，不需要轮询，精确度较高。
缺点：但每个订单要启动一个Timer，比较耗资源。
适用范围：同样适用于延时任务量比较少的系统。
三、RabbitMQ死信队列
死信：Dead Letter，是指被拒绝或TTL过期或队列已达到最大长度限制，无法再入队的消息。利用DLX，当消息在一个队列中变成死信之后，它能被重新publish到另一个Exchange，这个Exchange就是DLX。
（死信队列生产消费模型）
利用死信队列可以实现延时任务，每个订单创建一个消息，消息的TTL被设置为30秒。当消息过期后，通过交换机转发给业务消费队列，消费处理程序订阅业务消费队列，有消息则进行处理，检查订单状态，如果是初始状态，则重新对该订单创建一个消息。
优点：不需要轮询，精确度高。
缺点：引入消息组件，系统复杂度提高。
适用范围：适用于有大量延时任务需求的系统。
四、环形队列
环形队列本质上就是一个数组，首尾相接，形成一个环。数组中的每个索引位称为槽（Slot），每个槽中放一个集合，用于存放需要处理的任务。启动一个Timer，从Slot=0处开始，每秒钟向前移动一次，拿到当前Slot中任务数据进行处理，直到数组的最后一个Slot，再从Slot=0开始，循环往复。
（环形队列任务处理流程）
实际的业务场景中还要考虑任务不丢失，故障恢复等问题，所以增加了持久化任务队列和移除任务队列，将新加入槽中的任务持久化到Redis，将处理完的任务清除出Redis，进程故障恢复后初始化时将保存在Redis中的任务还原到环形队列的相应槽位中。
实际的业务场景中还要考虑任务不丢失，故障恢复等问题，所以增加了持久化任务队列和移除任务队列，将新加入槽中的任务持久化到Redis，将处理完的任务清除出Redis，进程故障恢复后初始化时将保存在Redis中的任务还原到环形队列的相应槽位中。
（推单任务处理模型）
总结
本文主要讲解了实现延时任务的不同方案，各自有不同的优缺点及适用范围，大家有延时任务的需求时可参考，希望给大家带来帮助。
一口气说出 6种 延时队列的实现方案，面试稳稳的_博客_云社区_开发者中心-华为云 https://bbs.huaweicloud.com/blogs/174555
下边会介绍多种实现延时队列的思路，哪种方式都没有绝对的好与坏，只是看把它用在什么业务场景中，技术这东西没有最好的只有最合适的。
一、延时队列的应用
什么是延时队列？顾名思义：首先它要具有队列的特性，再给它附加一个延迟消费队列消息的功能，也就是说可以指定队列中的消息在哪个时间点被消费。
延时队列在项目中的应用还是比较多的，尤其像电商类平台：
1、订单成功后，在30分钟内没有支付，自动取消订单
2、外卖平台发送订餐通知，下单成功后60s给用户推送短信。
3、如果订单一直处于某一个未完结状态时，及时处理关单，并退还库存
4、淘宝新建商户一个月内还没上传商品信息，将冻结商铺等
。。。。
上边的这些场景都可以应用延时队列解决。
二、延时队列的实现
我个人一直秉承的观点：工作上能用JDK自带API实现的功能，就不要轻易自己重复造轮子，或者引入三方中间件。一方面自己封装很容易出问题（大佬除外），再加上调试验证产生许多不必要的工作量；另一方面一旦接入三方的中间件就会让系统复杂度成倍的增加，维护成本也大大的增加。
1、DelayQueue 延时队列
JDK 中提供了一组实现延迟队列的API，位于Java.util.concurrent包下DelayQueue。
DelayQueue是一个BlockingQueue（***阻塞）队列，它本质就是封装了一个PriorityQueue（优先队列），PriorityQueue内部使用完全二叉堆（不知道的自行了解哈）来实现队列元素排序，我们在向DelayQueue队列中添加元素时，会给元素一个Delay（延迟时间）作为排序条件，队列中最小的元素会优先放在队首。队列中的元素只有到了Delay时间才允许从队列中取出。队列中可以放基本数据类型或自定义实体类，在存放基本数据类型时，优先队列中元素默认升序排列，自定义实体类就需要我们根据类属性值比较计算了。
先简单实现一下看看效果，添加三个order入队DelayQueue，分别设置订单在当前时间的5秒、10秒、15秒后取消。
要实现DelayQueue延时队列，队中元素要implements Delayed 接口，这哥接口里只有一个getDelay方法，用于设置延期时间。Order类中compareTo方法负责对队列中的元素进行排序。
public class Order implements Delayed {
/**
* 延迟时间
*/
@JsonFormat(locale = "zh", timezone = "GMT+8", pattern = "yyyy-MM-dd HH:mm:ss")
private long time;
String name;
public Order(String name, long time, TimeUnit unit) {
this.name = name;
this.time = System.currentTimeMillis() + (time > 0 ? unit.toMillis(time) : 0);
}
@Override
public long getDelay(TimeUnit unit) {
return time - System.currentTimeMillis();
}
@Override
public int compareTo(Delayed o) {
Order Order = (Order) o;
long diff = this.time - Order.time;
if (diff <= 0) {
return -1;
} else {
return 1;
}
}
}DelayQueue的put方法是线程安全的，因为put方法内部使用了ReentrantLock锁进行线程同步。DelayQueue还提供了两种出队的方法 poll() 和 take() ， poll() 为非阻塞获取，没有到期的元素直接返回null；take() 阻塞方式获取，没有到期的元素线程将会等待。
public class DelayQueueDemo {
public static void main(String[] args) throws InterruptedException {
Order Order1 = new Order("Order1", 5, TimeUnit.SECONDS);
Order Order2 = new Order("Order2", 10, TimeUnit.SECONDS);
Order Order3 = new Order("Order3", 15, TimeUnit.SECONDS);
DelayQueue delayQueue = new DelayQueue<>();
delayQueue.put(Order1);
delayQueue.put(Order2);
delayQueue.put(Order3);
System.out.println("订单延迟队列开始时间:" + LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
while (delayQueue.size() != 0) {
/**
* 取队列头部元素是否过期
*/
Order task = delayQueue.poll();
if (task != null) {
System.out.format("订单:{%s}被取消, 取消时间:{%s}\n", task.name, LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
}
Thread.sleep(1000);
}
}
}上边只是简单的实现入队与出队的操作，实际开发中会有专门的线程，负责消息的入队与消费。
执行后看到结果如下，Order1、Order2、Order3 分别在 5秒、10秒、15秒后被执行，至此就用DelayQueue实现了延时队列。
订单延迟队列开始时间:2020-05-06 14:59:09
订单:{Order1}被取消, 取消时间:{2020-05-06 14:59:14}
订单:{Order2}被取消, 取消时间:{2020-05-06 14:59:19}
订单:{Order3}被取消, 取消时间:{2020-05-06 14:59:24}2、Quartz 定时任务
Quartz一款非常经典任务调度框架，在Redis、RabbitMQ还未广泛应用时，超时未支付取消订单功能都是由定时任务实现的。定时任务它有一定的周期性，可能很多单子已经超时，但还没到达触发执行的时间点，那么就会造成订单处理的不够及时。
引入quartz框架依赖包
org.springframework.boot
spring-boot-starter-quartz
复制代码
在启动类中使用@EnableScheduling注解开启定时任务功能。
@EnableScheduling
@SpringBootApplication
public class DelayqueueApplication {
public static void main(String[] args) {
SpringApplication.run(DelayqueueApplication.class, args);
}
}编写一个定时任务，每个5秒执行一次。
@Component
public class QuartzDemo {
//每隔五秒
@Scheduled(cron = "0/5 * * * * ? ")
public void process(){
System.out.println("我是定时任务！");
}
}3、Redis sorted set
Redis的数据结构Zset，同样可以实现延迟队列的效果，主要利用它的score属性，redis通过score来为集合中的成员进行从小到大的排
通过zadd命令向队列delayqueue 中添加元素，并设置score值表示元素过期的时间；向delayqueue 添加三个order1、order2、order3，分别是10秒、20秒、30秒后过期。
zadd delayqueue 3 order3消费端轮询队列delayqueue， 将元素排序后取最小时间与当前时间比对，如小于当前时间代表已经过期移除key。
/**
* 消费消息
*/
public void pollOrderQueue() {
while (true) {
Set set = jedis.zrangeWithScores(DELAY_QUEUE, 0, 0);
String value = ((Tuple) set.toArray()[0]).getElement();
int score = (int) ((Tuple) set.toArray()[0]).getScore();
Calendar cal = Calendar.getInstance();
int nowSecond = (int) (cal.getTimeInMillis() / 1000);
if (nowSecond >= score) {
jedis.zrem(DELAY_QUEUE, value);
System.out.println(sdf.format(new Date()) + " removed key:" + value);
}
if (jedis.zcard(DELAY_QUEUE) <= 0) {
System.out.println(sdf.format(new Date()) + " zset empty ");
return;
}
Thread.sleep(1000);
}
}我们看到执行结果符合预期
2020-05-07 13:24:09 add finished.
2020-05-07 13:24:19 removed key:order1
2020-05-07 13:24:29 removed key:order2
2020-05-07 13:24:39 removed key:order3
2020-05-07 13:24:39 zset empty 4、Redis 过期回调
Redis 的key过期回调事件，也能达到延迟队列的效果，简单来说我们开启监听key是否过期的事件，一旦key过期会触发一个callback事件。
修改redis.conf文件开启notify-keyspace-events Ex
notify-keyspace-events ExRedis监听配置，注入Bean RedisMessageListenerContainer
@Configuration
public class RedisListenerConfig {
@Bean
RedisMessageListenerContainer container(RedisConnectionFactory connectionFactory) {
RedisMessageListenerContainer container = new RedisMessageListenerContainer();
container.setConnectionFactory(connectionFactory);
return container;
}
}编写Redis过期回调监听方法，必须继承KeyExpirationEventMessageListener ，有点类似于MQ的消息监听。
@Component
public class RedisKeyExpirationListener extends KeyExpirationEventMessageListener {
public RedisKeyExpirationListener(RedisMessageListenerContainer listenerContainer) {
super(listenerContainer);
}
@Override
public void onMessage(Message message, byte[] pattern) {
String expiredKey = message.toString();
System.out.println("监听到key：" + expiredKey + "已过期");
}
}到这代码就编写完成，非常的简单，接下来测试一下效果，在redis-cli客户端添加一个key 并给定3s的过期时间。
set xiaofu 123 ex 3在控制台成功监听到了这个过期的key。
监听到过期的key为：xiaofu5、RabbitMQ 延时队列
利用 RabbitMQ 做延时队列是比较常见的一种方式，而实际上RabbitMQ 自身并没有直接支持提供延迟队列功能，而是通过 RabbitMQ 消息队列的 TTL和 DXL这两个属性间接实现的。
先来认识一下 TTL和 DXL两个概念：
Time To Live(TTL) ：
TTL 顾名思义：指的是消息的存活时间，RabbitMQ可以通过x-message-tt参数来设置指定Queue（队列）和 Message（消息）上消息的存活时间，它的值是一个非负整数，单位为微秒。
RabbitMQ 可以从两种维度设置消息过期时间，分别是队列和消息本身
- 设置队列过期时间，那么队列中所有消息都具有相同的过期时间。
- 设置消息过期时间，对队列中的某一条消息设置过期时间，每条消息
TTL都可以不同。
如果同时设置队列和队列中消息的TTL，则TTL值以两者中较小的值为准。而队列中的消息存在队列中的时间，一旦超过TTL过期时间则成为Dead Letter（死信）。
Dead Letter Exchanges（DLX）
DLX即死信交换机，绑定在死信交换机上的即死信队列。RabbitMQ的 Queue（队列）可以配置两个参数x-dead-letter-exchange和 x-dead-letter-routing-key（可选），一旦队列内出现了Dead Letter（死信），则按照这两个参数可以将消息重新路由到另一个Exchange（交换机），让消息重新被消费。
x-dead-letter-exchange：队列中出现Dead Letter后将Dead Letter重新路由转发到指定 exchange（交换机）。
x-dead-letter-routing-key：指定routing-key发送，一般为要指定转发的队列。
队列出现Dead Letter的情况有：
- 消息或者队列的
TTL过期 - 队列达到最大长度
- 消息被消费端拒绝（basic.reject or basic.nack）
下边结合一张图看看如何实现超30分钟未支付关单功能，我们将订单消息A0001发送到延迟队列order.delay.queue，并设置x-message-tt消息存活时间为30分钟，当到达30分钟后订单消息A0001成为了Dead Letter（死信），延迟队列检测到有死信，通过配置x-dead-letter-exchange，将死信重新转发到能正常消费的关单队列，直接监听关单队列处理关单逻辑即可。
发送消息时指定消息延迟的时间
public void send(String delayTimes) {
amqpTemplate.convertAndSend("order.pay.exchange", "order.pay.queue","大家好我是延迟数据", message -> {
// 设置延迟毫秒值
message.getMessageProperties().setExpiration(String.valueOf(delayTimes));
return message;
});
}
}设置延迟队列出现死信后的转发规则
/**
* 延时队列
*/
@Bean(name = "order.delay.queue")
public Queue getMessageQueue() {
return QueueBuilder
.durable(RabbitConstant.DEAD_LETTER_QUEUE)
// 配置到期后转发的交换
.withArgument("x-dead-letter-exchange", "order.close.exchange")
// 配置到期后转发的路由键
.withArgument("x-dead-letter-routing-key", "order.close.queue")
.build();
}6、时间轮
前边几种延时队列的实现方法相对简单，比较容易理解，时间轮算法就稍微有点抽象了。kafka、netty都有基于时间轮算法实现延时队列，下边主要实践Netty的延时队列讲一下时间轮是什么原理。
先来看一张时间轮的原理图，解读一下时间轮的几个基本概念
wheel ：时间轮，图中的圆盘可以看作是钟表的刻度。比如一圈round 长度为24秒，刻度数为 8，那么每一个刻度表示 3秒。那么时间精度就是 3秒。时间长度 / 刻度数值越大，精度越大。
当添加一个定时、延时任务A，假如会延迟25秒后才会执行，可时间轮一圈round 的长度才24秒，那么此时会根据时间轮长度和刻度得到一个圈数 round和对应的指针位置 index，也是就任务A会绕一圈指向0格子上，此时时间轮会记录该任务的round和 index信息。当round=0，index=0 ，指针指向0格子 任务A并不会执行，因为 round=0不满足要求。
所以每一个格子代表的是一些时间，比如1秒和25秒 都会指向0格子上，而任务则放在每个格子对应的链表中，这点和HashMap的数据有些类似。
Netty构建延时队列主要用HashedWheelTimer，HashedWheelTimer底层数据结构依然是使用DelayedQueue，只是采用时间轮的算法来实现。
下面我们用Netty 简单实现延时队列，HashedWheelTimer构造函数比较多，解释一下各参数的含义。
ThreadFactory：表示用于生成工作线程，一般采用线程池；tickDuration和unit：每格的时间间隔，默认100ms；ticksPerWheel：一圈下来有几格，默认512，而如果传入数值的不是2的N次方，则会调整为大于等于该参数的一个2的N次方数值，有利于优化hash值的计算。
public HashedWheelTimer(ThreadFactory threadFactory, long tickDuration, TimeUnit unit, int ticksPerWheel) {
this(threadFactory, tickDuration, unit, ticksPerWheel, true);
}TimerTask：一个定时任务的实现接口，其中run方法包装了定时任务的逻辑。Timeout：一个定时任务提交到Timer之后返回的句柄，通过这个句柄外部可以取消这个定时任务，并对定时任务的状态进行一些基本的判断。Timer：是HashedWheelTimer实现的父接口，仅定义了如何提交定时任务和如何停止整个定时机制。
public class NettyDelayQueue {
public static void main(String[] args) {
final Timer timer = new HashedWheelTimer(Executors.defaultThreadFactory(), 5, TimeUnit.SECONDS, 2);
//定时任务
TimerTask task1 = new TimerTask() {
public void run(Timeout timeout) throws Exception {
System.out.println("order1 5s 后执行 ");
timer.newTimeout(this, 5, TimeUnit.SECONDS);//结束时候再次注册
}
};
timer.newTimeout(task1, 5, TimeUnit.SECONDS);
TimerTask task2 = new TimerTask() {
public void run(Timeout timeout) throws Exception {
System.out.println("order2 10s 后执行");
timer.newTimeout(this, 10, TimeUnit.SECONDS);//结束时候再注册
}
};
timer.newTimeout(task2, 10, TimeUnit.SECONDS);
//延迟任务
timer.newTimeout(new TimerTask() {
public void run(Timeout timeout) throws Exception {
System.out.println("order3 15s 后执行一次");
}
}, 15, TimeUnit.SECONDS);
}
}从执行的结果看，order3、order3延时任务只执行了一次，而order2、order1为定时任务，按照不同的周期重复执行。
order1 5s 后执行
order2 10s 后执行
order3 15s 后执行一次
order1 5s 后执行
order2 10s 后执行原文链接：https://blog.51cto.com/14570694/2502712
