延迟调用设计(RabbitMq实现)

• Q1:为什么要有延迟调度任务？
• Q2:实现延迟调度任务方式有哪些？
• Q3:为什么要使用rabbitMq实现？

为什么要用延迟调度任务？

       这需要从业务场景来说起，最常见的有比如订单商品锁定，在订单未支付超过15分钟，商品解除锁定，订单状态变更为支付超时/取消。那么必要要有延迟通知的服务/线程来通知我们要解除锁定商品、变更订单的状态。那么我们就要使用延迟调度的服务去解决这种业务场景。

实现延迟调度任务方式有哪些？

        实现延迟调度的方式有很多比如 rabbitMq、Redis、DelayQueue、时间轮询等等。那么这些都有各自的优缺点比如 :redis 线程不断轮询队列头判断元素是否过期。DelayQueue和时间轮询 内存中实现无法保证消息持久化等等问题。

为什么要使用rabbitMq实现？

        互联网时代，满足大并发、高性能和高可用的分布式系统才是首选架构。rabbitMq高效，分布式特性轻易进行横向扩展，消息持久化等等，满足我们的使用场景。

实现延迟调用:

利用rabbitmq的消息TTL和死信Exchange 两个特性实现延迟调用

1. 消息的TTL（Time To Live）消息的TTL就是消息的存活时间。RabbitMQ可以对队列和消息分别设置TTL。对队列设置就是队列没有消费者连着的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们认为这个消息就死了，称之为死信。如果队列设置了，消息也设置了，那么会取小的。所以一个消息如果被路由到不同的队列中，这个消息死亡的时间有可能不一样（不同的队列设置）。这里单讲单个消息的TTL，因为它才是实现延迟任务的关键。可以通过设置消息的expiration字段或者x-message-ttl属性来设置时间，两者是一样的效果。
2. Dead Letter Exchanges 一个消息在满足如下条件下，会进死信路由，记住这里是路由而不是队列，一个路由可以对应很多队列。Dead Letter Exchange其实就是一种普通的exchange，和创建其他exchange没有两样。只是在某一个设置Dead Letter Exchange的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。

代码开源到GitHub上，开箱即用，并支持以下特性。

Features:

1. 简单:服务提供restful api 简单操作;
2. 动态:支持动态修改延迟任务的状态;
3. 任务失败重试:可配置重试机制。默认不重试,由业务方控制重试开关和次数(延迟调用 默认延迟 1分钟 第二次2分钟 第三次3分钟);
4. 分钟级别的延迟调度任务，(毫秒级也可以支持,下期优化);
5. 调度时间无限制(小于一分钟的立马执行)。
6. 支持内部(eureka)以及外部调用，任务planType 区分。
7. 支持自动删除数据任务(执行时间之前的数据)auto.delete.enabled=true 开启自动删除任务默认关闭auto.delete.retainDays删除执行日期当前时间之前的数据默认5天
8. 过期未执行任务配置是否进行消费执行。

欢迎吐槽。