延时任务之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 模式目前只有广播模式，这意味着当生产者向特定频道发布一条消息时，所有订阅相关频道的消费者都能够收到该消息。

这个时候，我们需要注意多个服务实例重复处理消息的问题，这会增加代码开发量和维护难度。