延迟消息解决方案总结（含源码）

前言

先讲一下我们最近的两个业务场景：

1. 稿件定时签发。用户可以指定每篇稿件的签发时间，达到时间点将稿件签发。
2. 稿件发布超时触发失败。由于下游系统的一些不确定性，在10min内如果没有收到下游的回调，会将稿件置为发布失败。

看到这两种业务场景，是不是很容易联想到我们平时生活中的一些场景，例如：

• 线上购物时，在提交订单后有个15min的付款锁定，15min后如果用户还没有付款，会将订单取消，商品重新入库。
• 钉钉会议，会议开始前的15min，会提示会议即将开始。
• 点外卖时，在预计时间即将到达前10min，会提示骑手订单即将超时。

这种业务场景在生活中非常常见。那我们来思考下，应该怎么去实现。bingo！是不是脑子里蹦出来了一个词：“延迟”。

什么是延迟队列

这里的延迟队列并不是指传统意义上的"队列"这种数据结构，而是以时间为权重的一种有序堆结构，这里是指的一种广义上的概念。所以延迟队列的实现，我们首先提取出一个关键词：“有序”。我们只要考虑某种实现方案，满足有序的条件，就可以实现延迟队列。

可以实现的途径

1. 通过扫描数据库实现消息的延迟投递。例如：我们加一个延迟消息表，然后隔一段时间查询一次在当前时间之前的数据去实现延迟消息的消费。
2. 通过@Scheduled定时任务。
3. 通过xxl-job实现
4. 通过Redis键过期回调来实现。
5. 基于Redis的ZSet有序集合来实现（例如：Redission）
6. 基于JUC下的DelayQueue来实现。
7. 基于JUC下的ScheduledExecutorService来实现。
8. 基于RabbitMq的死信队列来实现。
9. 基于RabbitMq的插件实现延迟队列
10. 基于其他MQ（RocketMq，Kafka等）
11. 基于第三方调度平台（例如阿里云下的SchedulerX）

关于上述几种方案的对比

说一下自己了解过的几种方案一些浅薄的理解。

选型	优点	缺点
@Scheduled	集成项目简单，不需要安装额外的中间件	分布式系统下不适用;消息存在延迟；性能瓶颈严重
Redission	集成相对简单，上手成本低，适用于较少的延迟场景，可用于分布式系统	需要依赖于Redis；消息没有确认机制；非高可用 ，在redis突然宕机时，消息可能会丢失。
DelayQueue	集成简单，java原生支持	基于内存实现，不适用于分布式系统， 消息需要自己持久化
RabbitMq死信队列	基于队列，消息的可靠性能得到保证，性能也比较好。	延迟时长不够灵活，对单条消息设置超时时间 ，会造成消息延后的场景。
RabbitMq的插件	基于队列，消息的可靠性能得到保证，性能也比较好。消息延迟时间比较灵活	需要安装插件（rabbitmq-delayed-message-exchange），仅支持49天内的延迟消息。阿里云上的云rabbitMq仅支持一天之内的延迟消息
第三方调度平台	一般大厂的产品，性能和稳定性有保证，出了问题也好甩锅。	要钱

解决方案

最近基于springboot写了一个关于延迟消息的start。可以迅速的将延迟消息实现集成进当前项目。目前提供了三种延迟消息的实现。

• DelayQueue
• Redission
• 基于RabbitMq的插件

推荐使用Redission和基于RabbitMq的插件的方式。

项目地址：https://gitee.com/qiuyu97/delay-message