延迟任务在电商的业务下使，用的场景还是非常多的，比如订单下单未支付的取消时间、定时确认收货以及促销活动提醒等，目前实现这块的方案也有好些。
1、基于纯内存的DelayQueue
2、基于中间件的消息队列延迟消息的方式，主流的消息队列如Rocketmq、Rabbitmq都这方面的方案
3、基于Redis作为存储的实现方式，而基于Redis作为存储又分为两派，一派以sorted set作为数据结构，另一派以List作为数据结构，很多大厂都是基于此方案。
4、基于Key-Value的RocksDB作为数据存储实现延迟任务队列。
本文主要是基于Redis为存储方式去实现千万级的任务延迟队列的方式，会从架构层面较为系统的去介绍，主要的实现思路来源于Rocketmq的延迟队列+死信队列的方式。
一、整体设计
从整体来看，主要分为四块：任务池、执行任务池、重试任务池以及死信任务池。
任务池：主要是存储还未即将进行执行的任务,这个主要的数据存储结构为SortSet，按照执行时间的绝对长短进行排序
执行任务池：存储的是接近要执行的任务，这个主要数据存储结构为List，采用LIst的FIFO的方式去消费执行。
重试任务池：存储的是处于重试次数范围内的任务
死信任务池：存储的是经过了重试最大次数后，依然没有办法执行成功的任务。
一个任务可能会经过从任务池-》执行任务池-》重试任务池-》死信任务池这几个阶段。
二、任务写入当任务写入时，会产生一个JobId，随机分配一个Queue，这个Queue 主要是将任务进行打散，可以增加一些负载均衡的一些算法来决定是否那个Queue，这个jobid会由时间戳、延迟秒数以及随机数组成。
任务的Key :{queue}/{Jobid}
之后在根据延迟时间来决定是放到Ready pool还是放在Job Pool里面。
delay = 0，表示不需要延时则直接写到 Ready Pool queue为list 数据结构delay = n(n > 0)，表示需要延时，将延时加上当前系统时间作为绝对时间戳写到SortSet正是利用了Redis SortSet的排序特点，再通过其他线程轮询的方式将即将过期的任务从Job Pool 转移到Ready Pool中去。
三、任务消费
当业务从Job Pool 转移到Ready Pool中去之后，就可以通过消费Ready Pool的List 采用RPOP的方式进行任务消费，将从Pool池中取出任务，再将任务发送给消费者，同时进行重试次数-1，直到重试次数为零，即将任务转存至Retry Pool。
这里有两个点需要特别注意：
1、因为Redis List 通过RPOP进行弹出时，此时Pool将不在有该任务，因此需将任务转存至其他地方，等待业务执行完回调。
2、任务重试的策略需要进行设计，否则会出现一个任务阻塞一个队列的这种情况，要尽可能避免这种情况的出现，如未进行考虑，将会出现极端情况，整个Ready Pool 消费直接崩溃。
四、任务消费如何进行伸缩
当任务出现较多时会出现List 较f长，从而导致执行效率退化，从而导致整体消费吞吐变低，在这里可以参考Rocketmq的消费模型，动态的去调整Queue的方式，去提升消费端的速率，从而增大消费侧的吞吐。
