Redis学习路线(7)—— Redis的实现MQ

一、Redis的消息队列

  • list结构: 基于List结构模拟MQ
  • PubSub: 基本的 P2P 模式的 MQ模型
  • Stream: 比较完善的MQ模型

1、List模拟MQ: 通过LPUSH推送消息,RPOP接收消息,若想要阻塞队列的效果,可以通过BLPUSH,BRPOP指令进行。

(1)优点:

  • 利用Redis存储,内存上限高
  • 基于Redis的持久化机制,保证数据安全
  • 可以满足消息有序性

(2)缺点:

  • 无法避免消息丢失
  • 只支持单消费者

(3)命令行形式进行模拟

sh 复制代码
#存储商铺id, 优惠券id,用户id,并设置 3s 的TTL,避免等待时间过长
BLPUSH task:taskid voulerid uid
EXPIRE task:taskid 3
#取消息
BRPOP task:taskid

2、基于PubSub的消息队列: 一种Redis2.0版本引入的消息传递模型,消费者可以定义多个或多个通道,生产者想对应的通道发送消息后,所有订阅者都能收到相关消息。

(1)Redis命令:

  • SUBSCRIBE channel channel ... : 订阅多个频道
  • PUBLISH channel msg: 向一个频道发送消息
  • PSUBSCRIBE pattern pattern...: 订阅与pattern格式匹配的所有频道

(2)优点:

  • 采用发布订阅模型,支持多生产、多消费者的项目

(3)缺点:

  • 不支持数据持久化
  • 无法避免消息丢失
  • 消息堆积有上限,超出时数据丢失

3、基于Stream的消息队列: Stream是Redis5.0发布的数据类型,支持数据持久化

(1)Redis指令:

  • XADD key NOMKSTREAM MAXLEN \| MINID \[= \| \~ threshold LIMIT count] * |id field value field value:
    • NOMKSTREAM: 若队列不存在是否自动创建队列,默认是自动创建。
    • MAXLEN \| MINID \[= \| \~ threshold LIMIT count]: 设置消息队列最大消息数量
    • * |id: * 代表Redis自动生成ID【格式:"时间戳-递增数字"】,id 代表用户指定ID
  • XREAD COUNT count BLOCK milliseconds STREAMS key key... ID ID...:
    • COUNT count: 每次读取消息的最大数量
    • BLOCK milliseconds: 当没有消息时,是否阻塞、阻塞长
    • STREAMS key key...: 从指定队列读取
    • ID ID...: 起始id,只返回大于该ID的消息,0 = 表示从第一个开始,$ = 代表从最新的消息开始

(2)特点:

  • 消息可回溯
  • 一个消息可以被多个消费者获取
  • 可以阻塞读取
  • 有消息漏读的风险(同一时间内有多条消息)

4、基于Stream的消息队列-消费者分组

(1)消费者组的特点:

  • 消息可回溯: 支持持久化缓存数据。
  • 消息分流: 队列中的消息会分流给组内不同的消费者,而不是重复消费,从而加快消息处理的速度。
  • 消息读取: 可以阻塞读取消息,消费者组会维护一个标识,记录最后一个被处理的消息,每次读取消息都根据标识开始读取。
  • 消息确认机制: 消费者获取消息后,消息状态处于pending,并存入一个pending-list,当处理完成后通过XACK确认消息,标记消息已被处理,才会从pending-list移除。

(2)Redis命令:

  • XGROUP CREATE key groupName ID MKSTREAM: 创建消费组
  • XGROUP DESTROY key groupName: 删除消费组
  • XGROUP CREATECONSUMER key groupName consumername: 给指定的消费者组添加消费者
  • XGROUP DELCONSUMER key groupname consumername: 删除指定消费组的指定消费者
  • XREADGROUP GROUP group cunsumer COUNT count BLOCK milliseconds STREAMS key key... ID ID...: 指定消费者组读取消息,若不存在消费者,则自动创建,ID 可以使用 > 表示从下一个未消费的消息开始读取
  • XPADING key group \[IDLE min-idle-time start end count consumer ]: 读取消息队列中存在的未被处理的消息,通过设置空闲处理时间(通过- + 表示从最小到最大),读取数量来获取消息,指定消费者。

5、Redis三种消息队列的对比

List PubSub Stream
消费持久化 支持 不支持 支持
阻塞读取 支持 支持 支持
消息堆积处理 受限于内存空间,可以利用多消费者加快处理 受限于消费者缓冲区 受限于队列长度,利用消费者组加快消费速度
消息确认机制 不支持 不支持 不支持
消息回溯 不支持 不支持 支持
相关推荐
AIgorithmGEEK1 小时前
MySQL 索引全解(下):建、查、删实战与知识速查表
数据库·mysql·b+树·索引
滕州市燕猫虎计算机科技工作室个体工商户3 小时前
《Rust程序设计》学习笔记八:结构体
笔记·学习·rust·rust程序设计
行百里er3 小时前
Redis 完结篇——Redis 热点问题在 Spring Boot 项目中实战
redis·后端
唠点键盘之外的3 小时前
26 向量数据库实战:从 0 搭一条能用的检索链路(pgvector + Spring AI)
数据库·人工智能·spring
云和恩墨3 小时前
数据库监控简史:监控不止于告警——从图表大爆发到健康管理闭环
数据库
别动我齐刘海3 小时前
Linux 系统调试学习1
linux·运维·服务器·c++·学习·机器学习·机器人
ly76894 小时前
MongoDB 事务开销实测:快照隔离下的写冲突、重试与分片事务边界
数据库·mongodb·事务·分片集群·快照隔离·写冲突
豆角焖肉4 小时前
Spring AOP 自定义注解实现系统操作日志
数据库·自定义注解·springaop·操作日志·aop 切面
金伟API10245 小时前
不会写复杂SQL怎么办?
数据库·sql
xier_ran5 小时前
【infra之路】AI 编译器学习笔记(二):重拾 C++——移动语义与 LLVM 风格的类型转换
人工智能·笔记·学习