首页  思维导图  详情



 



Redis延迟队列

2023-07-11 17:09:51   2  举报





AI智能生成

Redis延迟队列方案及优劣

Redis

延迟队列

模板推荐

作者其他创作

大纲/内容

监听过期KEY

发布订阅模式

keyspace notifications

以__keyspace@<db>__:为前缀

后面跟的是key的名称

以__keyevent@<db>__:为前缀

后面跟的是消息事件类型

例：__keyevent@0__:expired

延迟队列实现原理

其实就是当这个key过期之后，Redis会发布一个key过期的事件到__keyevent@<db>__:expired这个channel， 只要我们的服务监听这个channel，那么就能知道过期的Key，从而就算实现了延迟队列功能

这种方式有什么坑

依赖key清除时机，时效性较差

惰性删除

定时删除

丢消息太频繁

Redis实现的发布订阅模式，消息是没有持久化机制，当消息发布到某个channel之后，如果没有客户端订阅 这个channel，那么这个消息就丢了，并不会像MQ一样进行持久化，等有消费者订阅的时候再给消费者消费。

消息消费只有广播模式

只有这一种模式

多个消费者订阅同一个channel，那么每个消费者都能消费到发布 到这个channel的所有消息

如果通过监听channel来获取延迟任务，那么一旦服务实例有多个的话， 还得保证消息不能重复处理，额外地增加了代码开发量

接收到所有key的某个事件

这个不属于Redis发布订阅模式的问题，而是Redis本身事件通知的问题

当消费者监听了以__keyevent@<db>__:开头的消息，那么会导致所有的key发生了事件都会被通知给消费者

Redisson实现

相对于第一种的优势

任务延迟的问题

Redisson方案理论上是没有延迟的，但是当消息数量增加，消费者消费缓慢这个情况下可能会导致延迟任务消费的延迟

丢消息的问题

Redisson方案很大程度上减轻了丢消息的可能性，因为所有的任务都是存在list和sorted set两种数据类型中， Redis有持久化机制，就算Redis宕机了，也就可能会丢一点点数据

广播消费任务的问题

这个是不会出现的，因为每个客户端都是从同一个目标队列中获取任务的

channel发布事件的问题

 Collect

Get Started

延迟发货处理

 Collect

Get Started

TTL+死信队列实现延迟队列

 Collect

Get Started

kafka延迟队列

 Collect

Get Started

延迟队列02





0 条评论

下一页