需求分析：
30分钟未支付则自动取消订单，订单生成60s后给用户发送短信
延时任务的实现，与定时任务区别比较大。
延时任务实现方案：
- 数据库轮询
- JDK延时队列
- 时间轮算法
- Redis缓存
- 消息队列
数据库轮询
数据库定时扫描筛选超时订单
优点：简单、支持集群
缺点：内存消耗大、存在延迟、数据库消耗极大（频繁查询）
JDK延时队列（生产者消费者）
使用JDK的DelayQueue实现，无界队列，只有延迟期满才能从中获取元素
放入DelayQueue的对象需要实现Delayed接口。
poll获取并移除超时元素， 没有则返回空。
task获取并移除超时元素，没有则wait当前线程，直到元素满足超时条件。
优点：效率高、任务触发延迟低
缺点：重新数据消息、扩展麻烦、内存限制，容易出现OOM、代码复杂度高
时间轮算法
比如一个时间环型有8个节点，分别是0-1-2-3-4-5-6-7-0，每个节点都存在一条链表，链表表携带过期时间和订单号，每一秒调动一格。
比如延时队列需要20s后执行，当前指针指向1位置，那么数据要加入到5位置上（20%8+1）.
优点：效率高、代码复杂度低、延迟时间低
缺点：宕机会导致数据丢失、扩展麻烦、订单太多会导致OOM
Redis缓存
方案1：
Zset有序队列+每个元素关联score
将订单超时时间戳和订单号分配设置为score和member，系统扫描判断是否超时。（生产者消费者模式）
以上实现存在问题：多线程多消费者存在消费同一个资源的问题
解决方案：加入分布式锁
方案2：
使用Redis的失效通知机制（Keyspace Notifucations），Redis2.8以上才支持
这种pub/sub机制存在一个硬伤，客户端服务重启，期间的消息会丢失，对数据可靠性无法得到保证
消息队列方案：
结合RabbitMQ的延时对队列特性，针对Queue和Message设置x-message-tt控制消息生存时间，超时则消息变为dead letter
通过Queue配置重新路由，配置参数为x-dead-letter-exchange和x-dead-letter-routing-key进行配置
优点：高效、支持横向扩展、支持持久化
缺点：复杂度和成本变高
