延时 队列

一、什么是延时队列

延时队列相比于普通队列最大的区别就体现在其延时的属性上，普通队列的元素是先进先出，按入队顺序进行处理，而延时队列中的元素在入队时会指定一个延迟时间，表示其希望能够在经过该指定时间后处理。从某种意义上来讲，延迟队列的结构并不像一个队列，而更像是一种以时间为权重的有序堆结构。

二、延时队列的应用

技术没有最好的只有最合适的。
延时队列在项目中的应用还是比较多的，尤其像电商类平台：

1. 12306 下单成功后，在半个小时内没有支付，自动取消订单。
2. 如果订单一直处于某一个未完结状态时，及时处理关单，并退还库存。
3. 淘宝新建商户一个月内还没上传商品信息，将冻结商铺等。
4. 会议预定系统，在预定会议开始前半小时通知所有预定该会议的用户。
5. 安全工单超过 24 小时未处理，则自动拉企业群提醒相关责任人。
6. 用户下单外卖以后，距离超时时间还有 10 分钟时提醒外卖小哥即将超时。
7. 外卖平台发送订餐通知，下单成功后 60s 给用户推送短信。

对于数据量比较少并且时效性要求不那么高的场景，一种比较简单的方式是轮询数据库，定期轮询一下数据库中所有数据，处理所有到期的数据。比如公司内部会议预定系统，因为数据量必然不会很大并且会议开始前提前 30 分钟提醒与提前 29 分钟提醒的差别并不大。

但是数据量比较大实时性要求比较高，尤其电商平台每天的所有新建订单 15 分钟内未支付的自动超时，数量级高达百万甚至千万，这时候轮询数据库则不可取。这种场景下，就需要使用延迟队列。延迟队列提供了一种高效的处理大量需要延迟消费消息的解决方案。

三、延时队列的实现

1️⃣DelayQueue 延时队列

JDK 中提供了一组实现延迟队列的 API，位于Java.util.concurrent包下的 DelayQueue。

DelayQueue 是一个 BlockingQueue(无界阻塞)队列，它本质就是封装了一个 PriorityQueue(优先队列)，PriorityQueue 内部使用完全二叉堆来实现队列元素排序，当向 DelayQueue 队列中添加元素时，会给元素一个 Delay(延迟时间)作为排序条件，队列中最小的元素会优先放在队首。队列中的元素只有到了 Delay 时间才允许从队列中取出。队列中可以放基本数据类型或自定义实体类，在存放基本数据类型时，优先队列中元素默认升序排列，自定义实体类就需要根据类属性值比较计算了。

先简单实现一下看看效果，添加三个 order 入队 DelayQueue，分别设置订单在当前时间的5秒、10秒、15秒后取消。

要实现 DelayQueue 延时队列，队中元素实现 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<Order> 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 框架依赖包

<dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-quartz</artifactId>
</dependency>

在启动类中使用 @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，ZSet 中每个元素都有一个对应 Score，ZSet 中所有元素是按照其 Score 进行排序的。Redis 的 ZSet 实现延迟队列逻辑如下：

1. 入队操作：zadd key timestamp task将需要处理的任务，按其需要延迟处理时间作为 Score 加入到 ZSet 中。Redis 的 zadd 的时间复杂度是 O(logN)，能相对比较高效的进行入队操作。

2. 起一个进程定时(比如每隔一秒)通过 zrangebyscore(返回指定分数范围的升序元素)方法查询 ZSet 中 Score 最小的元素，具体操作为：zrangebyscore KEY -inf +inf limit 0 1 WITHSCORES。查询结果有两种情况：
   a.查询出的分数小于等于当前时间戳，说明到这个任务需要执行的时间了，则去异步处理该任务。
   b.查询出的分数大于当前时间戳，由于刚刚的查询操作取出来的是分数最小的元素，所以说明 ZSet 中所有的任务都还没有到需要执行的时间，则休眠一秒后继续查询。

同样的，zrangebyscore的时间复杂度为O(logN + M)，其中 N 为 ZSet 中元素个数，M 为查询的元素个数，因此定时查询操作也是比较高效的。

其核心设计思路：

1. 将延迟的消息任务通过 hash 算法路由至不同的 Redis Key 上，这样做有两大好处：
   a.避免了当一个 KEY 在存储了较多的延时消息后，入队操作以及查询操作速度变慢的问题(两个操作的时间复杂度均为O(logN))。
   b.系统具有了更好的横向可扩展性，当数据量激增时，可以通过增加 Redis Key 的数量来快速的扩展整个系统，来抗住数据量的增长。

2. 每个 Redis Key 都对应建立一个处理进程，称为 Event 进程，通过上述步骤 2 中所述的zrangebyscore方法轮询 Key，查询是否有待处理的延迟消息。

3. 所有的 Event 进程只负责分发消息，具体的业务逻辑通过一个额外的消息队列异步处理，这么做的好处也是显而易见的：
   a.一方面，Event 进程只负责分发消息，那么其处理消息的速度就会非常快，就不太会出现因为业务逻辑复杂而导致消息堆积的情况。
   b.另一方面，采用一个额外的消息队列后，消息处理的可扩展性也会更好，可以通过增加消费者进程数量来扩展整个系统的消息处理能力。

4. Event 进程采用 Zookeeper 选主单进程部署的方式，避免 Event 进程宕机后，Redis Key 中消息堆积的情况。一旦 Zookeeper 的 leader 主机宕机，Zookeeper 会自动选择新的 leader 主机来处理 Redis Key 中的消息。

上面的例子：
通过 zadd 命令向队列 delayqueue 中添加元素，并设置 score 值表示元素过期的时间；向 delayqueue 添加三个 order1、order2、order3，分别是10秒、20秒、30秒后过期。消费端轮询队列 delayqueue，将元素排序后取最小时间与当前时间比对，如小于当前时间代表已经过期移除 key。

//消费消息
public void pollOrderQueue() {
    while (true) {
        Set<Tuple> 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 Ex

Redis 监听配置，注入 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 w2g 123 ex 3

在控制台成功监听到了这个过期的 key。

监听到过期的 key 为：w2g

5️⃣RabbitMQ 延时队列

利用 RabbitMQ 做延时队列是比较常见的一种方式，可以很好的利用 RabbitMQ 的特性，比如消息可靠发送、消息可靠投递、死信队列来保障消息至少被消费一次以及未被正确处理的消息不会被丢弃。另外，通过 RabbitMQ 集群的特性，可以很好的解决单点故障问题，不会因为单个节点挂掉导致延迟队列不可用或者消息丢失。RabbitMQ 自身并没有直接支持提供延迟队列功能，而是通过 RabbitMQ 消息队列的 TTL 和 DXL 这两个属性间接实现的。

1. Time To Live(TTL) ：

TTL 顾名思义：指的是一条消息的最大生存时间，RabbitMQ 可以通过x-message-tt来设置指定 Queue(队列)和 Message(消息)上消息的存活时间，它的值是一个非负整数，单位为微秒。如果一条消息在 TTL 设置的时间内没有被消费，那么它就会变成一条 Dead Letter(死信)。

RabbitMQ 可以从两种维度设置消息过期时间，分别是队列和消息本身。如果同时设置队列和队列中消息的 TTL，则 TTL 值以两者中较小的值为准。

①设置队列过期时间，那么队列中所有消息都具有相同的过期时间，适用于延迟队列的延迟时间为固定值的时候。直接在创建队列的时候设置整个队列的 TTL 过期时间，所有进入队列的消息，都被设置成了统一的过期时间，一旦消息过期，马上就会被丢弃，进入死信队列，参考代码如下：

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-message-ttl", 6000);
channel.queueDeclare(queueName, durable, exclusive, autoDelete, args);

②设置消息过期时间，对队列中的某一条消息设置过期时间，每条消息 TTL 都可以不同。针对单条消息设置，适用于不同的消息设置不同的延迟时间。参考代码如下，该消息被设置了6秒的过期时间：

AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder();
builder.expiration("6000");
AMQP.BasicProperties properties = builder.build();
channel.basicPublish(exchangeName, routingKey, mandatory, properties, "msg content".getBytes());

注意：使用这种方式设置的 TTL，消息可能不会按时死亡，因为 RabbitMQ 只会检查第一个消息是否过期。比如这种情况，第一个消息设置了 20s 的 TTL，第二个消息设置了 10s 的 TTL，那么 RabbitMQ 会等到第一个消息过期之后，才会让第二个消息过期。解决该问题的方法也很简单，只需要安装 RabbitMQ 的一个插件即可：https://www.rabbitmq.com/community-plugins.html。安装好后，所有的消息就都能按照被设置的 TTL 过期了。

2. 死信(Dead Letter)队列

死信队列实际上是 RabbitMQ 的一种消息处理机制，当 RabbitMQ 在生产和消费消息的时候，消息遇到如下的情况，就会变成“死信”：

1. 消息被消费端拒绝(basic.reject/basic.nack)并且不再重新投递 requeue=false。
2. 消息超时未消费，也就是 TTL 过期了。
3. 消息队列到达最大长度

消息一旦变成一条死信，便会被重新投递到死信交换机(Dead-Letter-Exchange)，然后死信交换机根据绑定规则转发到对应的死信队列上，监听该队列就可以让消息被重新消费。

3. Dead Letter Exchanges(DLX)

DLX 即死信交换机，绑定在死信交换机上的即死信队列。RabbitMQ 的 Queue 可以配置两个参数：
①x-dead-letter-exchange：队列中出现 Dead Letter 后将 Dead Letter 重新路由转发到指定 exchange(交换机)。
②x-dead-letter-routing-key(可选)：指定 routing-key 发送，一般为要指定转发的队列。

超 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️⃣TimeWheel(时间轮)

TimeWheel 算法稍微有点抽象，是一种实现延迟队列的巧妙且高效的算法，被应用在 Netty，Zookeeper，Kafka 等各种框架中。下边主要实践 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 后执行

四、总结

1️⃣Redis 的实现方案理解起来最为简单，能够快速落地，但 Redis 毕竟是基于内存的，虽然有数据持久化方案，但还是有数据丢失的可能性。
2️⃣RabbitMQ 的实现方案，由于 RabbitMQ 本身的消息可靠发送、消息可靠投递、死信队列等特性，可以保障消息至少被消费一次以及未被正确处理的消息不会被丢弃，让消息的可靠性有了保障。
3️⃣Kafka 的时间轮算法，最难理解也是一种非常巧妙实现方案。