基于 Redis 实现高性能、低延迟的延时消息的方案演进

🎉欢迎来系统设计专栏：基于 Redis 实现高性能、低延迟的延时消息的方案演进

📜其他专栏：java面试数据结构源码解读故障分析

🎬作者简介：大家好，我是小徐🥇
☁️博客首页：CSDN主页小徐的博客
🌄每日一句：好学而不勤非真好学者

📜 欢迎大家关注！ ❤️

1、前言

随着互联网的发展，越来越多的业务场景需要使用延时队列。比如:

任务调度:延时队列可以用于任务调度，将需要在未来某个特定时刻执行的任务放入队列中。消息延迟处理: 延时队列可以用于消息系统，其中一些消息需要在一段时间后才能被消费。例如，在需要进行消息重试的情况下，可以将消息放入延时队列，并在一段时间后重新处理订单处理:在电商系统中，有时需要对订单进行一些处理，例如取消未支付的订单或处理退货请求。
会员到期提醒:如果你有一个会员制度，需要提醒会员其订阅即将到期，延时队列可以用于安排在到期日期前发送提醒通知。
缓解高峰期负载:在高峰期，系统可能会面临大量的请求和负载。延时队列可以用于将一些请求推迟处理，进行削峰处理.

随着技术的进步，实现的方式也愈来愈多种多样，以 Java 语言为例，实现的方式也是多如牛毛，例如使用JDK自带的工具包实现；使用任务调度框架实现；使用Netty的时间轮询实现；使用消息队列实现；使用Redis 实现等等。本文主要探讨 Redis 实现延时消息的几种不同的方案演进。

2、技术方案

如前文所述，使用 Redis 来实现延时消息的实现方式主要有 3 种

过期事件监听
Redis zset (有序集合)
Redisson

得益于 Redis 自身设计的优点，使用 Redis 完全可以支撑高性能的要求。

从可靠性和使用便利性上来考虑，三种方案优先级排序: Redisson > zset> 过期事件监听

3、方案一: 过期事件监听

3.1 核心设计与原理

Redis 的过期事件监听是基于 pub/sub 的，key 过期时会 pub 消息到一个内置的 channel 中，客户端可以通过监听这个 channel 获取到消息，:进而实现延时队列的功能

3.2 方案缺陷

缺陷 1: 不支持持久化，可靠性低

pub/sub 模式下的过期事件监听，消息并不会做持久化，会有消息丢失的风险。

缺陷2:不保证及时性

过期事件监听的方案听起来很好理解，也似乎很完美，但事实并非如此。主要是借助 Redis 删除过期 key 的消息监听，不保证及时性

Redis 的单线程设计，如果需要支持定时过期，在 Redis 高负载的情况下或者有大量过期键需要同时处理时，会造成 Redis 服务器卡顿，影响主业务执行。考虑到可用性，Redis 的单线程机制并不能很好地支持定时删除过期 key 的场景，所以 Redis 使用惰性删除 + 定期删除key 的方式
也正因为 Redis key 的删除不是过期即删除的，所以 key 删除时发送消息的时间也不一定是 key的过期时间。

失效场景可以参考下图:

4、方案二: zset

Redis 提供了有序集合 zset，我们也可以利用 zset 封装延迟消息
zset 的常用命令及解释

ZADD key score member [score member ...]: 向有序集合 key 中添加一个或多个成员，每个成员都带有一个分值 score

ZRANGEBYSCORE key min max [WITHSCORES]: 返回有序集合 key 中分值介于 min 和 max 之间的成员。可选的 WITHSCORES 参数表示同时返回成员和分值

ZREM key member [member ...]: 从有序集合 key 中移除一个或多个成员