延时任务之Redis 过期事件监听原理与缺陷
一、实现原理
Redis过期事件监听实现延时任务功能主要基于其发布/订阅(pub/sub)机制和键空间通知功能。具体原理如下:
- 发布/订阅机制:Redis从2.0版本开始支持发布/订阅功能,该机制类似于消息队列。其中引入了“channel(频道)”的概念,发布者可以向某个频道发布消息,订阅者可以订阅相应的频道以接收消息。
- 键空间通知:Redis提供了一些默认的channel用来通知特定事件的发生,其中包括
__keyevent@<db>__:expired
频道,专门用于通知key的过期事件。这里的<db>
是指Redis数据库编号(0-15)。当某个设置了过期时间的key被Redis删除时,Redis会向__keyevent@<db>__:expired
频道发布一条消息,通知这个key已过期,消息内容为过期的key名称。 - 延时任务实现流程:首先,使用
SET key value EX seconds
等命令设置一个带有过期时间的键,将任务相关信息存储在value中,过期时间即为任务的延时时间。然后,在应用中启动一个订阅者,订阅__keyevent@<db>__:expired
频道。当key到期并被Redis删除时,对应的过期事件消息会发布到该频道,订阅者收到通知后,根据获取到的过期key名称,从Redis或其他存储中获取任务详情,进而执行相应的延时任务逻辑。
二、存在的缺陷
-
时效性差
Redis 删除过期键采用 惰性删除(访问时才检查)和 定期删除(每隔一段时间批量检查)策略,而非过期瞬间立即删除。因此,过期事件的触发可能存在延迟(极端情况下甚至长时间不触发),导致任务执行时间不准。 -
消息丢失风险
Redis 的 Pub/Sub 是 无状态 的:若订阅者断线重连,断线期间的事件消息会丢失;且 Redis 本身不存储消息,若订阅者处理能力不足,也可能漏处理事件。 -
多服务实例下存在消息重复的问题
Redis 的 pub/sub 模式目前只有广播模式,这意味着当生产者向特定频道发布一条消息时,所有订阅相关频道的消费者都能够收到该消息。
这个时候,我们需要注意多个服务实例重复处理消息的问题,这会增加代码开发量和维护难度。