消息队列Redis实现

文章目录

消息队列

  • 消息队列:存储和管理队列,消息代理
  • 生产者:发送消息到消息队列
  • 消费者:从消息队列获取消息并处理消息

优点

  • 消息队列独立于jvm存在,不依赖jvm内存
  • 消息队列会确保数据安全,会对其中的数据持久化,会在消息头这里要求消费者做确认,消费者没有确认就一直存在

Redis实现方式

redis提供了三种不同的方式实现消息队列

  • list结构:基于list结构模拟消息队列

    • 使用brlush,blpop实现阻塞获取和添加
    • 缺点:无法避免数据丢失,如果刚从队列中取出Redis就宕机了,那么数据就丢失了,只支持单消费者
    • 优点:基于Redis,可以持久化数据,不受限于jvm,满足消息有序性
  • pubsub:基本的点对点消息模型

    • 消费者可以订阅一个或多个channel,生产者向对应channel发送消息后,所有订阅者都能收到相关消息,就实现了多消费者

      bash 复制代码
      subscribe channel[channel] #订阅一个或多个频道
      publish channel msg #向一个频道发送消息
      psubscribe pattern[pattern] #订阅与pattern格式匹配的所有频道
    • 缺点:不支持数据持久化,无法避免数据丢失,消息堆积有上限,超出时数据丢失

  • Stream:比较完善的消息队列模型

    • Redis5引入的一种新的数据类型

    • 消息可以回溯,可以被多个消费者读取

    • 但是由于$代表读最新的消息,如果我们处理一条消息的过程中,又有超过一条消息到达消息队列,则下次只能获取最新的那条消息,出现漏读消息的问题

消费者组

基于Stream的消息队列

将多个消费者划分到一个组中,监听同一个队列

  • 消息分流:队列中的消息会分流给组内不同的消费者,从而加快消息处理的速度
  • 消费者组会维护一个标识,记录最后一个被处理的消息,就算redis宕机重启,还会从标识之后读取消息,防止了漏读消息问题
  • 消息确认:消费者获取消息后消息处于pending状态,并存入一个pending-list,处理完成后要通过xack来确认消息,消息确认后才会被从pending-list中移除,防止了消费者获取消息后宕机,导致消息丢失的问题

一般不需要手动创建消费者,当我们指定一个组去监听消息时,如果他发现组中没有消费者,会自动帮我们创建

确定消息被处理过了

bash 复制代码
xack key group id[id......]

Stream类型消息队列的xreadgroup命令特点

  • 消息可回溯
  • 可以多消费者争抢资源,加快消费速度
  • 可以阻塞读取
  • 没有消息漏读风险
  • 有消息确认机制,保证消息至少被消费一次
相关推荐
得物技术24 分钟前
MySQL单表为何别超2000万行?揭秘B+树与16KB页的生死博弈|得物技术
数据库·后端·mysql
christine-rr4 小时前
linux常用命令(4)——压缩命令
linux·服务器·redis
可涵不会debug4 小时前
【IoTDB】时序数据库选型指南:工业大数据场景下的技术突围
数据库·时序数据库
ByteBlossom4 小时前
MySQL 面试场景题之如何处理 BLOB 和CLOB 数据类型?
数据库·mysql·面试
麦兜*4 小时前
MongoDB Atlas 云数据库实战:从零搭建全球多节点集群
java·数据库·spring boot·mongodb·spring·spring cloud
Slaughter信仰5 小时前
深入理解Java虚拟机:JVM高级特性与最佳实践(第3版)第十章知识点问答(10题)
java·jvm·数据库
麦兜*5 小时前
MongoDB 在物联网(IoT)中的应用:海量时序数据处理方案
java·数据库·spring boot·物联网·mongodb·spring
-Xie-5 小时前
Mysql杂志(十六)——缓存池
数据库·mysql·缓存
七夜zippoe5 小时前
缓存与数据库一致性实战手册:从故障修复到架构演进
数据库·缓存·架构