Redis实现消息队列的4种方案

liuyong00 2020-06-14

原文链接:Redis实现消息队列的方案

Redis作为内存中的数据结构存储,常用作数据库、缓存和消息代理。它支持数据结构,如 字符串,散列,列表,集合,带有范围查询的排序集(sorted sets),位图(bitmaps),超级日志(hyperloglogs),具有半径查询和流的地理空间索引。Redis具有内置复制,Lua脚本,LRU驱逐,事务和不同级别的磁盘持久性,并通过Redis SentinelRedis Cluster自动分区。

为了实现其出色的性能,Redis使用内存数据集(in-memory dataset)

MQ应用有很多,比如ActiveMQ,RabbitMQ,Kafka等,但是也可以基于redis来实现,可以降低系统的维护成本和实现复杂度,本篇介绍redis中实现消息队列的几种方案。

  • 基于List的 LPUSH+BRPOP 的实现
  • PUB/SUB,订阅/发布模式
  • 基于Sorted-Set的实现
  • 基于Stream类型的实现

基于异步消息队列List lpush-brpop(rpush-blpop)

使用rpushlpush操作入队列,lpoprpop操作出队列。

List支持多个生产者和消费者并发进出消息,每个消费者拿到都是不同的列表元素。

但是当队列为空时,lpop和rpop会一直空轮训,消耗资源;所以引入阻塞读blpop和brpop(b代表blocking),阻塞读在队列没有数据的时候进入休眠状态

一旦数据到来则立刻醒过来,消息延迟几乎为零。

注意

你以为上面的方案很完美?还有个问题需要解决:空闲连接的问题。

如果线程一直阻塞在那里,Redis客户端的连接就成了闲置连接,闲置过久,服务器一般会主动断开连接,减少闲置资源占用,这个时候blpop和brpop或抛出异常

所以在编写客户端消费者的时候要小心,如果捕获到异常,还有重试。

缺点:

  • 消费者确认ACK麻烦,不能保证消费者消费消息后是否成功处理的问题(宕机或处理异常等),通常需要维护一个Pending列表,保证消息处理确认。
  • 不能做广播模式,如pub/sub,消息发布/订阅模型
  • 不能重复消费,一旦消费就会被删除
  • 不支持分组消费

如何实现:Redis应用-异步消息队列与延时队列

PUB/SUB,订阅/发布模式

SUBSCRIBE,用于订阅信道

PUBLISH,向信道发送消息

UNSUBSCRIBE,取消订阅

此模式允许生产者只生产一次消息,由中间件负责将消息复制到多个消息队列,每个消息队列由对应的消费组消费。

优点

典型的广播模式,一个消息可以发布到多个消费者

多信道订阅,消费者可以同时订阅多个信道,从而接收多类消息

消息即时发送,消息不用等待消费者读取,消费者会自动接收到信道发布的消息

缺点

消息一旦发布,不能接收。换句话就是发布时若客户端不在线,则消息丢失,不能寻回

不能保证每个消费者接收的时间是一致的

若消费者客户端出现消息积压,到一定程度,会被强制断开,导致消息意外丢失。通常发生在消息的生产远大于消费速度时

可见,Pub/Sub 模式不适合做消息存储,消息积压类的业务,而是擅长处理广播,即时通讯,即时反馈的业务。

基于Sorted-Set的实现

Sortes Set(有序列表),类似于java的SortedSet和HashMap的结合体,一方面她是一个set,保证内部value的唯一性,另一方面它可以给每个value赋予一个score,代表这个value的

排序权重。内部实现是“跳跃表”。

有序集合的方案是在自己确定消息顺ID时比较常用,使用集合成员的Score来作为消息ID,保证顺序,还可以保证消息ID的单调递增。通常可以使用时间戳+序号的方案。确保了消息ID的单调递增,利用SortedSet的依据

Score排序的特征,就可以制作一个有序的消息队列了。

优点

就是可以自定义消息ID,在消息ID有意义时,比较重要。

缺点

缺点也明显,不允许重复消息(因为是集合),同时消息ID确定有错误会导致消息的顺序出错。

基于Stream类型的实现

Redis实现消息队列的4种方案

 剩下的东西有待补充

相关推荐