点击上方“芋道源码”，选择“设为星标”
管她前浪，还是后浪？
能浪的浪，才是好浪！
每天 10:33 更新文章，每天掉亿点点头发...
源码精品专栏
- 原创 | Java 2021 超神之路，很肝~
- 中文详细注释的开源项目
- RPC 框架 Dubbo 源码解析
- 网络应用框架 Netty 源码解析
- 消息中间件 RocketMQ 源码解析
- 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析
- 作业调度中间件 Elastic-Job 源码解析
- 分布式事务中间件 TCC-Transaction 源码解析
- Eureka 和 Hystrix 源码解析
- Java 并发源码
来源：www.cnblogs.com/
lylife/p/7881950.html
- 一、背景
- 二、几种延时队列
- 三、 基于Redis实现
- 1.0版本
- 2.0版本
一、背景
在业务发展过程中，会出现一些需要延时处理的场景，比如：
- 订单下单之后超过30分钟用户未支付，需要取消订单
- 订单一些评论，如果48h用户未对商家评论，系统会自动产生一条默认评论
- 点我达订单下单后，超过一定时间订单未派出，需要超时取消订单等。。
处理这类需求，比较直接简单的方式就是定时任务轮训扫表。这种处理方式在数据量不大的场景下是完全没问题，但是当数据量大的时候高频的轮训数据库就会比较的耗资源，导致数据库的慢查或者查询超时。所以在处理这类需求时候，采用了延时队列来完成。
“推荐下自己做的 Spring Boot 的实战项目： https://github.com/YunaiV/ruoyi-vue-pro
二、几种延时队列
*延时队列就是一种带有延迟功能的消息队列。下面会介绍几种目前已有的延时队列：***1.Java中java.util.concurrent.DelayQueue
**优点：JDK自身实现，使用方便，量小适用 缺点：队列消息处于jvm内存，不支持分布式运行和消息持久化2.Rocketmq延时队列优点：消息持久化，分布式 缺点：不支持任意时间精度，只支持特定level的延时消息3.Rabbitmq延时队列（TTL DLX实现）优点：消息持久化，分布式 缺点：延时相同的消息必须扔在同一个队列
根据自身业务和公司情况，如果实现一个自己的延时队列服务需要考虑一下几点:
* 消息存储 * 过期延时消息实时获取 * 高可用性
“推荐下自己做的 Spring Cloud 的实战项目： https://github.com/YunaiV/onemall
三、 基于Redis实现
1.0版本
- 功能特性
* 消息可靠性，消息持久化，消息至少被消费一次 * 实时性：存在一定的时间误差（定时任务间隔） * 支持指定消息remove * 高可用性
- 整体结构
- Messages Pool所有的延时消息存放，结构为KV结构，key为消息ID，value为一个具体的message（这里选择Redis Hash结构主要是因为hash结构能存储较大的数据量，数据较多时候会进行渐进式rehash扩容，并且对于HSET和HGET命令来说时间复杂度都是O(1)） - Delayed Queue是16个有序队列（队列支持水平扩展），结构为ZSET，value为messages pool中消息ID，score为过期时间（分为多个队列是为了提高扫描的速度） - Timed Task定时任务，负责扫描处理每个队列过期消息
- 消息结构
每个延时消息必须包括以下参数:
* tags：消息过期之后发送mq的tags * keys：消息过期之后发送mq的keys * body：消息过期之后发送mq的body，提供给消费这做具体的消息处理 * delayTime：延时发送时间（默认，delayTime、expectDate有一个即可） * expectDate：期望发送时间
- 流程
注：上图1、2、3或者2、3是一个事务操作 取出过期消息过程是通过一个外部定时任务每隔1min分钟去查询队列中过期的消息，然后发送mq && remove
2.0版本
1.0上有一个可改进的地方就是队列中过期的消息是通过定时任务触发查询。所有有了2.0 2.0版本在1.0上做了一个优化，废弃掉了1min定时任务触发过期消息发送，采用了java Lock await/singlal方式实现过期消息的实时发送低延时
- 多节点部署结构：
- pull job：这里分别为每一个队列创建了一个pull job thread，功能很简单，就是负责去队列中拉取过期的消息数据（这里保证一个队列有且只有一个pull job） - worker：pull job拉取到的过期消息会交给一个worker thread去处理，这样的好处是处理过期的消息实时性更高（pull job不必等去除过期消息全部处理完成在继续去拉取新的过期数据） - zookeeper coordinate：通过zk的操作来完成对队列的重新分配工作，daemon thread监听zk节点的创建和删除
- 主要流程：
服务启动会注册zk，获取分配处理的queues，启动后台线程监听zk 。为每个分配queue创建一个pull job 。pull job首先会去queue中查询是否有过期消息：Y：将取出消息交给worker处理 N：查询queue中最后一个成员（zset结构默认按score递增排序），如果为空，则await；不为空则await（成员score-System.currentTimeMillis()）
由于过期消息发送成功才会从队列中remove，所以pull job会记录上一次查询队列的一个offset，每次获取到过期消息会将offset向前偏移，过期消息交给worker处理，当worker由于某些异常原因处理失败会重置pull job中offset，这样可以避免消息发送一次失败之后没办法在继续处理（除了新节点add || remove时候）。当部署服务有新增，延时队列服务会重新计算得到当前处理队列，并将之前创建pull job cancel，为新处理队列重新创建pull job。删除同理。
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
代码语言：javascript复制文章有帮助的话，在看，转发吧。谢谢支持哟 (*^__^*）
