Redis消息队列初探

已于 2024-02-16 17:26:25 修改
阅读量247 收藏
点赞数
分类专栏： redis 消息队列 分布式 文章标签： redis 分布式
于 2023-08-23 11:16:14 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Musclewl/article/details/132389105
版权
redis 同时被 3 个专栏收录
13 篇文章 0 订阅
订阅专栏
分布式
3 篇文章 0 订阅
订阅专栏
消息队列
1 篇文章 0 订阅
订阅专栏

什么是消息队列？

消息队列（Message Queue/Broker），顾名思义：存放消息的队列。是分布式系统中重要的组件，利用高效可靠的消息传递机制进行与平台解耦的数据通信。主要解决应用耦合、异步处理、流量削锋等问题。

Redis实现消息队列

  • 基于List数据结构实现消息队列
  • 基于发布订阅机制实现消息队列
  • 基于Stream数据结构实现消息队列

基于List数据结构实现消息队列

Redis的List结构基于双向链表实现，所以基于lpush和rpop或者rpush和lpop指令即可，同时支持阻塞获取指令BRPOP或BLPOP。

127.0.0.1:6379> LPUSH queue 1 2 3 4
(integer) 4
127.0.0.1:6379> Rpop queue
"1"
127.0.0.1:6379> Rpop queue
"2"
127.0.0.1:6379> Rpop queue
"3"
127.0.0.1:6379> Rpop queue
"4"
127.0.0.1:6379> Rpop queue
(nil)

由于列队的特性是：先进先出，所以只要从list结构一端进，另一端出即可。上述demo中时使用LPUSH和RPOP实现简单队列的效果， 当队列中不存在元素时，返回nil。

若要支持阻塞获取队列元素时，需要结合LPUSH和BRPOP命令使用。

使用BRPOP命令会阻塞当前客户端，直到队列中存在元素或等待时间达到。
在这里插入图片描述

127.0.0.1:6379> LPUSH queue 15 16
(integer) 2

127.0.0.1:6379> BRPOP queue 100
1) "queue" --队列名称
2) "15"   --消息体
(5.16s) --获取消息等待的时间

优点：

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

缺点：

  • 不能保证消息被消费（无法避免消息丢失）
  • 不能重复消费，一旦消费就被删除（无法被多个消费者 消费同一条消息）

基于发布订阅机制实现消息队列

Pubsub (发布订阅)是Redis2.0版本引入的消息传递模型。顾名思义，消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息。

  • 一个channel可以有一个或多个订阅者
  • 一个发布者可向多个channel发送消息

PUBLISH 发布

PUBLISH channel message
summary: Post a message to a channel
retuen: the number of clients that received the message.

PUBLISH channel（通道name）message（消息体）
返回：接受该消息的客户端数量，包括匹配模式。

SUBSCRIBE 订阅

SUBSCRIBE channel [channel …]
summary: Listen for messages published to the given channels

127.0.0.1:6379> SUBSCRIBE channel1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel1"
3) (integer) 1
...阻塞等待channel中的消息...

当channel收到消息时：

127.0.0.1:6379> SUBSCRIBE channel1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel1"
3) (integer) 1
1) "message"
2) "channel1"
3) "k1=v1"

PSUBSCRIBE 模式匹配订阅

PSUBSCRIBE pattern [pattern …]
summary: Listen for messages published to channels matching the given patterns

支持的模式匹配规则：

  • h?llo subscribes to hello, hallo and hxllo

  • h*llo subscribes to hllo and heeeello

  • h[ae]llo subscribes to hello and hallo, but not hillo

    '?' ：匹配单个字符 '*' ：匹配多个字符 '[]'：匹配自定义[]内部字符

    127.0.0.1:6379> PSUBSCRIBE chan*
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "chan*"
3) (integer) 1
1) "pmessage"
2) "chan*"   --返回匹配的规则
3) "channel1"--返回匹配规则的通道name
4) "k1=v1"   --返回消息体

优点：

  • 采用发布订阅模型，支持多生产、多消费
  • 阻塞读取消息（但无法设置阻塞时间）

缺点：

  • 不支持数据持久化
  • 无法保证数据被消费（无法避免消息丢失）
  • 消息堆积有上限，超出限制将丢失旧的数据

基于Stream数据结构实现消息队列

stream单消费者模式

xlen：查询消息长度

XLEN key
summary: Return the number of entries in a stream

xlen 队列名称

xadd ：添加消息

XADD key [NOMKSTREAM] [MAXLEN|MINID [=|~] threshold [LIMIT count]] *|ID field value [field value …]

  • key（队列名称）；

  • [NOMKSTREAM]（若指定，当队列不存在则不创建。默认创建）；

  • [MAXLEN|MINID [=|~] threshold [LIMIT count]] 设置消息队列的最大消息数量，若超过数量，但未被消费，则会抛弃旧的数据；

  • *|ID 表示自动生成唯一key，是unix毫秒时间戳-同一毫秒的序列号。也可以自定义自增id。

  • field value [field value …] 消息key1 消息value1 消息key2 消息value2 …消息体键值对
    在这里插入图片描述

    DEMO:

    127.0.0.1:6379> xadd stream1 * k1 v1 k2 v2
"1692755653814-0" -- *，代表redis自增ID，由时间戳-递增数字
xread：读取消息

XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key …] ID [ID …]]

  • count n 可选，读取n条数据

  • block 0 可选，阻塞等待毫秒数。block设置为0时表示没有消息就一直阻塞，不设置block就是非阻塞模式，拿不拿到都返回，拿不到返回nil

  • streams key [key …] 必填，指定一个或多个队列名称
    在这里插入图片描述

    • 设置ID [ID …]为指定消息ID，将**(阻塞)** 获取该消息ID之后的消息
    • 设置ID [ID …] 为$，将**(阻塞)** 获取队列最新消息
    • 设置ID [ID …] 为0，将**(阻塞)** 获取队列第一个消息及之后的消息

    DEMO:

    127.0.0.1:6379> xread count 1 block 1000 streams stream1 $
(nil) 	 --阻塞时间达到，若channel没有消息则返回nil
(1.02s)  --返回阻塞等待的时间

127.0.0.1:6379> xread count 1 block 10000 streams stream1 $
1) 1) "stream1"                 --队列名称
   2) 1) 1) "1692755905302-0"   --消息ID
         2) 1) "k1"             --消息体
            2) "v1"
            3) "k2"
            4) "v2"
(3.20s)

优点：

  • 采用stream机数据结构，支持多生产、多消费
  • 支持数据持久化（消息可回溯）
  • 消息可阻塞读取（可设置阻塞时间）

缺点：

  • 无法保证数据被消费（无法避免消息丢失）——未标记消息已处理，也没有ack确认机制，无法保证消息最少被消费一次。

stream消费者组模式

消费者组 (Consumer Group): 将多个消费者划分到一个组中，监听同一个队列。

具体以下特点：

  • 消息分流
    • 队列中的消息会分流给组内的不同消费者，而不是重复消费，从而加快消息处理的速度
  • 消息标识
    • 消费者组会维护一个标识，记录最后一个被处理的消息，哪怕消费者宕机重启，还会从标示之后读取消息。确保每一个消息都会被消费
  • 消息确认
    • 消费者获取消息后，消息处于pending状态，并存入一个pending-list。当消息处理完成后==需要通过XACK来确认消息==，标记消息为已处理，才会从pendingList移除。
xgroup create：创建消费者组

XGROUP CREATE key groupname ID|$ [MKSTREAM]]

xgroup create 队列名称 消费组名 起始消费id（0-0 或0表示从头开始消费，$表示从尾即最新消息开始消费）

  • key: 队列名称
  • groupName: 消费者组名称
  • ID: 起始ID标示，$代表队列中最后一个消息，0则代表队列中第一个消息
  • MKSTREAM: 队列不存在时自动创建队列

还存在其他命令，如下：
在这里插入图片描述

DEMO:

127.0.0.1:6379> XGROUP create stream2 group1 $ mkstream
OK
分组读取消息：xreadgroup

XREADGROUP GROUP group consumer [COUNT count] [BLOCK milliseconds] [NOACK] STREAMS key [key …] ID [ID …]

xreadgroup group 消费组名 消费者 （count n 可选参数，读取n条数据）（block 0 可选参数，阻塞等待毫秒数） streams 队列名称 消息id

  • group: 消费组名称

  • consumer: 消费者名称，如果消费者不存在，会自动创建一个消费者

  • count: 本次查询的最大数量

  • BLOCK milliseconds: 当没有消息时最长等待时间

  • NOACK: 无需手动ACK，获取到消息后自动确认**（不建议使用）**

  • STREAMS key: 指定队列名称

  • ID: 获取消息的起始ID: ——读取过的不再重复读，

    • 设置具体消息id：读取大于指定id的消息（不包含指定id的消息）
    • '>' ：=从下一个未消费的消息开始（读取最新消息的意思）=
    • 其它：根据指定id从pending-list中获取已消费但未确认的消息，例如0，是从pending-list中的第一个消息开始（因为每次消费pending-list中的消息+确认ACK后，就会将该条消息从pending-list移除，所以0每次都是队列中刷新后的第一天消息）

  • xreadgroup是写命令，只能在主服务器进行（它修改了游标等信息）。

DEMO:
在这里插入图片描述
可以看出，在消费者组内接收消息，不会重复消费，每次都是获取的下一条未处理的消息。

若设置ID 为其他时，如，设置ID=0。
在这里插入图片描述
两次获取pending-list中的同一条数据，因为未确认该消息，该消息一直在pending-list的第一条。我们将这条消息确认后可得到：
在这里插入图片描述
确认该条消息，再次执行XREADGROUP group group1 c1 count 1 block 10000 streams stream2 0 ，可见已经获取的是第二条数据k2=v2了：
在这里插入图片描述

未确认消息：XPENDING

XPENDING key group [[IDLE min-idle-time] start end count [consumer]]
summary: Return information and entries from a stream consumer group pending entries list, that are messages fetched but never acknowledged.

  • key: 队列名称
  • group: 消费组名称
  • [IDLE min-idle-time] : 消息被消费开始，到确认XACK之前的时间
  • start : 需要获取未确认消息的起始下标，-：代表负无穷
  • end : 需要获取未确认消息的末尾下标，+：代表正无穷
  • count: 获取未确认消息的数量
  • consumer: 指定消费者名称**（因为每个消费者消费过的消息，都存在自己的pending-list中）**

DEMO:

127.0.0.1:6379> XPENDING stream2 group1 - + 100
1) 1) "1692758490032-0"           --消费ID
   2) "c1"                        --消费者名称
   3) (integer) 815246
   4) (integer) 1
2) 1) "1692758493333-0"
   2) "c1"
   3) (integer) 811406
   4) (integer) 1
3) 1) "1692758496586-0"
   2) "c2"
   3) (integer) 784393
   4) (integer) 1
4) 1) "1692758499886-0"
   2) "c2"
   3) (integer) 782980
   4) (integer) 1
5) 1) "1692758503581-0"
   2) "c1"
   3) (integer) 779702
   4) (integer) 1
6) 1) "1692758508874-0"
   2) "c2"
   3) (integer) 776924
   4) (integer) 1

可看出上述C1、C2消费者各自存在3条待确认的消息。

确认消息：xack

XACK key group ID [ID …]

xack 队列名称 消费组名 消息id…

已经读取但是未确认的消息会写入pending_list，确认XACK后会从pending_list删除，是为了确保消息至少被消费一次。
在这里插入图片描述

优点：

  • 采用stream机数据结构，支持多生产、多消费
  • 支持数据持久化（消息可回溯）
  • 消息可阻塞读取（可设置阻塞时间）
  • 没有消息漏读的风险
  • 支持消息确认机制，保证消息最少被消费一次

Redis队列总结：

笔者在此仅以List、PubSub、Stream三种类型的消息队列进行对比，数据如下：
在这里插入图片描述

Musclewl
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【消息队列系列4】原理初探之RocketMQ
飞楼踏梦
08-10 226
​RocketMQ是一个纯Java、分布式、队列模型的开源消息中间件，前身是MetaQ，是阿里参考Kafka特点研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点。 先提前祝大家五一快乐！！！ 因为个人学习重点调整，消息队列目前只先发这4篇文章，后面会选择一种消息队列，重点介绍环境搭建和使用姿势上，也就是消息队列的第5篇文章，预计3个月之内会补上去，期待后续... 4.1 基本概念 先对常用的词汇有个基本认识，相...
Redis实现简易消息队列的三种方式
Go_ahead_forever的博客
10-12 2402
消息队列是一种用于在计算机系统中传递和处理数据的重要工具。如果你完全不了解消息队列，不用担心，我将尽力以简单明了的方式来解释它。首先，想象一下你正在玩一个游戏，而游戏中有很多任务需要完成，但你不需要立刻完成它们。相反，你可以将这些任务列在一个清单上，然后按照你的时间表逐个完成。消息队列就像这个任务清单一样，只不过它用于计算机程序之间传递任务和数据。消息队列的基本原理是，一个程序可以将一条消息（或任务）发送到队列中，然后另一个程序可以从队列中取出并处理这条消息。
PHP Yii操作redis streams/XREADGROUP
sinat_35162715的博客
08-27 976
应用场景 Redis Stream 是 Redis 5.0 版本新增加的数据结构。 Redis Stream 主要用于消息队列（MQ，Message Queue），Redis 本身是有一个 Redis 发布订阅 (pub/sub) 来实现消息队列的功能，但它有个缺点就是消息无法持久化，如果出现网络断开、Redis 宕机等，消息就会被丢弃。 简单来说发布订阅 (pub/sub) 可以分发消息，但无法记录历史消息。 而 Redis Stream 提供了消息的持久化和主备复制功能，可以让任何客户端访问任何
在redis创建stream消息队列时报错：ERR unknown command ‘XREADGROUP‘
weixin_45618869的博客
07-08 1187
由于Redis版本过低导致，stream流是5.0版本的新特性，我这里用的是3.2.100的版本会出现这个错误；
SpringBoot 整合 Redis 实现消息队列
北
08-12 817
写这篇文章的原因还是得归咎于???? 上一篇博客写了????Docker搭建Redis Cluster 集群环境 我自己是认为对于每个知识点，光看了不操作是没有用的（遗忘太快…），多少得在手上用上几回才可以，才能对它加深印象。 昨天搭建了Redis Cluster 集群环境，今天就来拿它玩一玩Redis 消息队列吧 于是便有了这个Redis 实现消息队列的Demo, 很喜欢一句话：”八小时内谋生活，八小时外谋发展“。 共勉.???? SpringBoot 整合 Redis 实现消息队列一、前言概念作用：
linux消息队列收到乱码,sping+redis实现消息队列的乱码问题
weixin_29081703的博客
05-10 242
使用spring支持redis实现消息队列，参考官方样例：https://spring.io/guides/gs/messaging-redis/实现后在运行过程中发现消费者在接收消息时会出现乱码的情况。经排查是由于序列化工具不同导致的。生产者的配置template默认是使用stringSerializer的，这里配置了JdkSerializationRedisSerializer来做一些对象的存...
php 队列处理 demo,php+redis 实现消息队列的推送【demo】。
weixin_30460749的博客
04-15 473
用redis做队列，为了缓解瞬间请求服务器的压力。实际开发当中可通过定时任务去做。当然缺点是不够实时。1.添加一个php文件，PushQueue.php$redis=new redis();$redis->connect('127.0.0.1','6379');$arr=array(1,2,3,4,5,6,7);foreach($arr $key=>$value){$redis-&gt...
Redis配置文件初探
weixin_50602111的博客
04-22 620
Redis配置文件出探
利用redis制作消息队列
weixin_30716725的博客
09-08 116
redis在游戏服务器中的使用初探(一) 环境搭建redis在游戏服务器中的使用初探(二) 客户端开源库选择redis在游戏服务器中的使用初探(三) 信息存储redis在游戏服务器中的使用初探(四) redis应用 在学习分布式对象存储的期间，有这么一个需求 "多个接口服务(本文当作客户端Clinet)需要以固定间隔向所有的多个服务器发送心跳，保证服务器确认客户端状态。 服务器在接收到...
基于python实现操作redis及消息队列
09-08
主要介绍了基于python操作redis及消息队列,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
go实现redis消息队列
07-30
使用go实现的redis的消息队列，支持并发队列；支持Topic，Group注册队列监听消息；支持队列消息异常监听重启恢复；
SpringBoot利用redis集成消息队列的方法
08-29
主要介绍了SpringBoot利用redis集成消息队列的方法,需要的朋友可以参考下
Java利用Redis实现消息队列的示例代码
08-29
本篇文章主要介绍了Java利用Redis实现消息队列的示例代码，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
redis消息队列
09-05
redis 消息队列源码示例 redis 消息队列源码示例 redis 消息队列源码示例
Redis教程(二十一)：Redis怎么保证缓存一致性
十三月的博客
05-29 992
Redis 的缓存一致性是指在使用 Redis 作为缓存层时，保证缓存中的数据与数据库中的数据保持一致的状态。在分布式系统中，数据一致性是一个重要的问题，因为可能存在多个客户端同时读写同一数据，或者数据在不同节点间需要同步更新。：当数据库中的数据被修改后，相关联的缓存数据需要被相应地更新或失效，以避免返回陈旧的数据。：当缓存的数据被认定为过时（可以是时间过期，或者因为底层数据有变更）时，必须从缓存中移除，以确保下次读取会从后端数据库加载最新数据。：在分布式缓存环境中，相同的数据可能会存储在多个缓存节点上。
redis笔记1
kekexiaomayi的博客
05-28 329
set添加、get获取、mset批量添加、mget批量获取，incr整型的key自增，incrby设置自增的值，setnx添加key并且设置值,setex添加值，指定有效期eg:setex name 5 “xiaoxiao”，为名字加“xiaoxiao”,5秒后过期;HSET添加、修改，HGET查，Hmset批量加、HMGET批量查、HGETALL获取所有等。LPUSH左加、LPOP左取，RPUSH右加、RPOP右取等（左是首，右是尾）无序、不可重复、支持交、并、差集等功能。可排序、不重复，排行榜。
Redis实践记录与总结
最新发布
qq_44031124的博客
05-29 513
紧接着上第二个方案，使用redis数据备份工具redis-dump将缓存数据备份成json文件，再将该json文件中的数据迁移到低版本redis数据库中，对低版本进行rdb文件备份，使用redis rdb tools工具进行分析。Redis缓存数据库设计建议：缓存中的数据不要设置永久性数据，可以定时往数据库中同步数据。上述报错的原因是：当前缓存使用的7版本，而7版本目前redis rdb tools对高版本的rdb文件分析的功能还没有上线，也就是说当前功能不兼容。最近生产环境缓存数据库数据过大（
Redis教程(十八)：Redis的Redisson的看门狗机制
十三月的博客
05-27 464
Redisson的看门狗机制主要是指客户端在获取到锁之后，通过后台线程或定时任务自动续期的功能，以避免在锁持有期间因为处理时间过长而导致锁自动释放，进而确保操作的安全性与原子性。需要注意的是，虽然看门狗机制提升了Redis分布式锁的易用性和安全性，但也增加了系统的复杂性，例如需要考虑看门狗的执行频率、续期阈值和锁的最大生存时间等。另外，实现这一机制通常依赖于客户端库的支持（如Redisson），直接在应用代码中实现可能比较复杂。
redis 消息队列
08-29
Redis消息队列是一种基于Redis的轻量级消息队列系统，它提供了一种简单而高效的方式来处理异步任务和消息传递。在Redis中，消息队列使用列表（List）数据结构来存储消息，并通过发布（publish）和订阅（subscribe）机制来实现消息的传递。 使用Redis消息队列有以下几个关键概念： 1. 生产者（Producer）：负责产生并发送消息到队列中。 2. 消费者（Consumer）：从队列中获取并处理消息。 3. 队列（Queue）：存储消息的列表。生产者向队列中添加消息，消费者从队列中获取消息进行处理。 4. 发布（Publish）：生产者将消息发布到指定的频道中。 5. 订阅（Subscribe）：消费者订阅指定的频道，以接收发布到该频道的消息。 使用Redis消息队列的步骤如下： 1. 创建一个Redis连接。 2. 生产者将消息通过rpush命令添加到列表中。 3. 消费者通过blpop或brpop命令从列表中获取消息，这些命令会阻塞直到有新的消息到达。 4. 消费者处理消息。 5. 重复步骤3和4，直到没有更多的消息。 Redis消息队列的优点包括高性能、简单易用、支持多种编程语言和可靠性。但需要注意的是，Redis消息队列并没有提供消息持久化的机制，即当Redis服务器重启或崩溃时，未处理的消息会丢失。因此，在使用Redis消息队列时，需要根据具体场景考虑消息的持久化需求。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值