昨天叫外卖的时候，发现一个很奇怪的现象，就是在我下完单之后，没有及时付款，结果过了15分钟后，收到短信说，我的订单已取消！可能有些人不以为意，但是天真无邪我真想知道这背后是谁在捣鬼，所以恶补了一番，才知道这就是延迟队列。
其实在我们日常生活中很多类似的场景，尤其在电商类平台：
- 下订单成功后，在30分钟内没有支付，自动取消订单
- 用户多少天未登录给用户做召回推送短信
- 外卖平台发送订餐通知，下单成功后60s给用户推送短信
- 淘宝新建商户一个月内还没上传商品信息，将冻结商铺等
1. 什么是延迟队列
首先它要有队列的特性，再加上延迟消息的特性，就是指定队列中的消息在某个时间点，然后再等一段的时间后被消费。
可能有些人会马上想到定时任务，但是仔细想想后会发现，定时任务和延迟队列还真不一样。
（1）定时任务
好比我们平时用的闹钟，指定某个时间，定时触发，或者轮询，比如：每天早上7:30执行或者每个月周末凌晨2::30 执行一次，这样周期执行。
（2）延迟队列
而延迟队列就没有执行周期，它是在某个事件发生后等一段时间再执行，而我们也无法确定这个事件何时发生。
明确了什么是延迟队列，我们来看看分布式环境如何实现！
2. 延迟队列怎么实现
单机环境实现延迟队列，相信大家有很多办法，但是在分布式环境下，该怎么做呢？
可能有些人还是会想，定时任务每5分钟，查询一次数据库，不就实现延迟队列了吗（前提是忽略5分钟的误差），但是不停的查，会一直阻塞，很耗费资源，而大家其实都清楚，在高并发场景下CPU资源有多珍贵。
其实成熟的实现方式还是很多的，比如：
基于Redis的zset数据结构或者基于Redis的事件监听
基于kafka的 delay_topic 或者 单层文件时间轮
阿里开源的RocketMQ延迟消息
而本次我们通过RabbitMQ的方式，通过死信队列实现一个延迟消息队列，通过消息监听，也缓解了定时任务不断轮询的缺点。
3. RabbitMQ 延迟队列
RabbitMQ是可以对指定消息接收存储和转发的消息队列。它本身并没有延迟队列的特性，但是我们可以过期时间（TTL）和死信队列（DXL）实现。
先来认识一下 TTL和 DXL两个概念：
- TTL ：指的是消息的存活时间，RabbitMQ可以通过x-message-tt参数来设置指定Queue（队列）和 Message（消息）上消息的存活时间，它的值是一个非负整数，单位为微秒。
- DXL：DLX即死信交换机，绑定在死信交换机上的即死信队列。RabbitMQ的 Queue（队列）可以配置两个参数x-dead-letter-exchange 和 x-dead-letter-routing-key（可选），一旦队列内出现了Dead Letter（死信），则按照这两个参数可以将消息重新路由到另一个Exchange（交换机），让消息重新被消费。
那么什么情况下会出现死信（DL）呢？上网查了一下：
- 消息或者队列过期（延迟队列就靠它）
- 队列达到最大长度
- 消息被消费端拒绝消费
模拟场景分析：加入我们下单超时15分钟没有支付订单，则关闭并取消订单。
- 在下单的时候，我们开启一个带有过期时间的消息队列
- 如果15分钟后，该消息还没有被消费，就会过期进入到死信队列
- 此时我们提前已经绑定好了路由关单交换机，所以会将该消息路由到关闭订单的交换机，进入关闭订单的消息队列
- 监听并消费关闭订单的消息，检查数据库该订单的支付状态，若未支付，就关闭订单，并且发送短信提醒客户。
大概处理流程，也许是下面这样：
主流程代码实现如下：
- 用户下订单
@Override
- 发送消息
public void sendMessage(String orderId, final Long delayTimes) {
- 消费消息
@RabbitHandler
当然，RabbitMQ也有缺点，因为它需要依赖运维维护一套RabbitMQ组件，增加一定的复杂度和维护成本。
4. 每日一题
题目描述
请定义一个队列并实现函数 max_value 得到队列里的最大值，要求函数max_value、push_back 和 pop_front 的均摊时间复杂度都是O(1)。
实现思路
我们都知道，队列是先进先出的，我们可以使用一个单调的双端对列 Deque,在插入每一个元素 value 时，从队列d尾部依次取出比当前元素 value 小的元素，直到遇到一个比当前元素大的元素 value，这样保证双端队列首部永远是最大的一个元素。class MaxQueue {
Queue<Integer> q;
