阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 www.cnblogs.com/lylife/p/7881950.html 「Simple」欢迎转载，保留摘要，谢谢！

• 一、背景
• 二、几种延时队列
• 三、 基于Redis实现
  • 1.0版本
  • 2.0版本

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

一、背景

在业务发展过程中，会出现一些需要延时处理的场景，比如：

1. 订单下单之后超过30分钟用户未支付，需要取消订单
2. 订单一些评论，如果48h用户未对商家评论，系统会自动产生一条默认评论
3. 点我达订单下单后，超过一定时间订单未派出，需要超时取消订单等。。

处理这类需求，比较直接简单的方式就是定时任务轮训扫表。这种处理方式在数据量不大的场景下是完全没问题，但是当数据量大的时候高频的轮训数据库就会比较的耗资源，导致数据库的慢查或者查询超时。所以在处理这类需求时候，采用了延时队列来完成。

二、几种延时队列

*延时队列就是一种带有延迟功能的消息队列。下面会介绍几种目前已有的延时队列： ***1.Java中java.util.concurrent.DelayQueue

**优点：JDK自身实现，使用方便，量小适用 缺点：队列消息处于jvm内存，不支持分布式运行和消息持久化 2.Rocketmq延时队列 优点：消息持久化，分布式 缺点：不支持任意时间精度，只支持特定level的延时消息 3.Rabbitmq延时队列（TTL+DLX实现） 优点：消息持久化，分布式 缺点：延时相同的消息必须扔在同一个队列

根据自身业务和公司情况，如果实现一个自己的延时队列服务需要考虑一下几点:

* 消息存储 * 过期延时消息实时获取 * 高可用性

三、 基于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。删除同理。