【Redis】5.消息队列

我就是我 2024-04-01 13:03 96阅读 0赞

#### 文章目录 ####

*  1. 消息队列概述
 *  2. Redis基于List实现消息队列
 *  3. Redis基于PubSub实现消息队列
 *  4. Redis基于Stream的消息队列

## 1. 消息队列概述 ##

Redis不仅可以作为缓存中间件，还可以做为消息队列。

最简单的消息队列模型包含这3个基本的角色：

*  消息队列：存储和管理消息，也被称为消息代理（Message Broker）
 *  生产者：发送消息到消息队列
 *  消费者：从消息队列获取消息并处理消息

![在这里插入图片描述][1660599b4c3b40d7bad8434b139e4bb7.png_pic_center]

使用消息队列的好处方便就在于可以解耦。

消息队列使用得最普遍的场景莫过于秒杀业务。用户下单之后，利用redis进行校验下单条件，再通过消息队列将消息发送出去，随后启动一个线程去消费这个消息。这一过程中，不仅仅完成了解耦，而且在秒杀过程中，可以”省去“写订单进数据库的事件，提高了响应速度。

基于Redis实现的消息队列有以下几种：

1.  基于List实现消息队列
2.  基于PubSub的消息队列
3.  基于Stream的消息队列

使用Redis消息队列

--------------------

## 2. Redis基于List实现消息队列 ##

List是简单的字符串列表，可以添加一个元素到List的头部（左边）或者是尾部（右边）

所以List可以用作异步队列使用，将需要进行的任务转化为字符串然后存在Redis的List中，另外一个线程则根据顺序进行读取，处理异步任务。

![在这里插入图片描述][42840729cf71470aa4572d0dbb6135fc.png_pic_center]

不过要注意的是，**当队列中没有消息时RPOP或LPOP操作会返回null，并不像JVM的阻塞队列那样会阻塞并等待消息。因此这里应该使用BRPOP或者BLPOP来实现阻塞效果**。

基于List实现消息队列分别有以下优缺点  
优点：

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

缺点：

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

**List 常用命令**

<table> 
 <thead> 
  <tr> 
   <th align="left">命令</th> 
   <th align="left">用法</th> 
   <th align="left">描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left"><strong>LPUSH</strong></td> 
   <td align="left">LPUSH key value [value …]</td> 
   <td align="left">将一个或多个值 value 插入到列表 key 的表头如果有多个 value 值，那么各个 value 值按从左到右的顺序依次插入到表头</td> 
  </tr> 
  <tr> 
   <td align="left"><strong>RPUSH</strong></td> 
   <td align="left">RPUSH key value [value …]</td> 
   <td align="left">将一个或多个值 value 插入到列表 key 的表尾(最右边)</td> 
  </tr> 
  <tr> 
   <td align="left"><strong>LPOP</strong></td> 
   <td align="left">LPOP key</td> 
   <td align="left">移除并返回列表 key 的头元素。</td> 
  </tr> 
  <tr> 
   <td align="left"><strong>BLPOP</strong></td> 
   <td align="left">BLPOP key [key …] timeout</td> 
   <td align="left">移出并获取列表的第一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止</td> 
  </tr> 
  <tr> 
   <td align="left"><strong>RPOP</strong></td> 
   <td align="left">RPOP key</td> 
   <td align="left">移除并返回列表 key 的尾元素。</td> 
  </tr> 
  <tr> 
   <td align="left"><strong>BRPOP</strong></td> 
   <td align="left">BRPOP key [key …] timeout</td> 
   <td align="left">移出并获取列表的最后一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。</td> 
  </tr> 
  <tr> 
   <td align="left">BRPOPLPUSH</td> 
   <td align="left">BRPOPLPUSH source destination timeout</td> 
   <td align="left">从列表中弹出一个值，将弹出的元素插入到另外一个列表中并返回它；如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。</td> 
  </tr> 
  <tr> 
   <td align="left">RPOPLPUSH</td> 
   <td align="left">RPOPLPUSH source destinationb</td> 
   <td align="left">命令 RPOPLPUSH 在一个原子时间内，执行以下两个动作：将列表 source 中的最后一个元素(尾元素)弹出，并返回给客户端。将 source 弹出的元素插入到列表 destination ，作为 destination 列表的的头元素</td> 
  </tr> 
  <tr> 
   <td align="left"><strong>LLEN</strong></td> 
   <td align="left">LLEN key</td> 
   <td align="left">返回列表 key 的长度。如果 key 不存在，则 key 被解释为一个空列表，返回 0 .如果 key 不是列表类型，返回一个错误</td> 
  </tr> 
  <tr> 
   <td align="left"><strong>LRANGE</strong></td> 
   <td align="left">LRANGE key start stop</td> 
   <td align="left">返回列表 key 中指定区间内的元素，区间以偏移量 start 和 stop 指定</td> 
  </tr> 
 </tbody> 
</table>

--------------------

## 3. Redis基于PubSub实现消息队列 ##

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

相对于List而言，PubSub是一种发布订阅模式，而List是一种点对点的模式。

![在这里插入图片描述][4cabc7a0eced4dd58a59956367e949a1.png_pic_center]

基于PubSub的消息队列以下优缺点  
优点：

*  采用发布订阅模型，支持多生产、多消费

缺点：

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

Pub/Sub 常用命令：

<table> 
 <thead> 
  <tr> 
   <th align="left">命令</th> 
   <th align="left">用法</th> 
   <th align="left">描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">PSUBSCRIBE</td> 
   <td align="left">PSUBSCRIBE pattern [pattern …]</td> 
   <td align="left">订阅一个或多个符合给定模式的频道</td> 
  </tr> 
  <tr> 
   <td align="left">PUBSUB</td> 
   <td align="left">PUBSUB subcommand [argument [argument …]]</td> 
   <td align="left">查看订阅与发布系统状态</td> 
  </tr> 
  <tr> 
   <td align="left">PUBLISH</td> 
   <td align="left">PUBLISH channel message</td> 
   <td align="left">将信息发送到指定的频道</td> 
  </tr> 
  <tr> 
   <td align="left">PUNSUBSCRIBE</td> 
   <td align="left">PUNSUBSCRIBE [pattern [pattern …]]</td> 
   <td align="left">退订所有给定模式的频道</td> 
  </tr> 
  <tr> 
   <td align="left">SUBSCRIBE</td> 
   <td align="left">SUBSCRIBE channel [channel …]</td> 
   <td align="left">订阅给定的一个或多个频道的信息</td> 
  </tr> 
  <tr> 
   <td align="left">UNSUBSCRIBE</td> 
   <td align="left">UNSUBSCRIBE [channel [channel …]]</td> 
   <td align="left">指退订给定的频道</td> 
  </tr> 
 </tbody> 
</table>

--------------------

## 4. Redis基于Stream的消息队列 ##

Stream 是 Redis 5.0 引入的一种新数据类型，可以实现一个功能非常完善的消息队列。也是Redis中最常用来作为消息队列的一种实现方法。

发送消息的命令：

![在这里插入图片描述][63032ea207b94f05a05c74e1a4c80896.png_pic_center]

举个栗子：

![在这里插入图片描述][71e9f96726984bb3b031baf0f91dfdde.png_pic_center]

读取消息的方式之一：XREAD

![在这里插入图片描述][47db8f2f9e52421d9aa9cc73c7fdfdde.png_pic_center]

举个栗子：

![在这里插入图片描述][e5f6d31d5fc14d2785c1929db8711cd6.png_pic_center]

在业务开发中，我们可以循环的调用XREAD阻塞方式来查询最新消息，从而实现持续监听队列的效果，伪代码如下

![在这里插入图片描述][c83462c89b454a589617150a833bd857.png_pic_center]

注意：当我们指定起始ID为$时，代表读取最新的消息，如果我们处理一条消息的过程中，又有超过1条以上的消息到达队列，则下次获取时也只能获取到最新的一条，**会出现漏读消息的问题**

STREAM类型消息队列的XREAD命令特点：

*  消息可回溯
 *  一个消息可以被多个消费者读取
 *  可以阻塞读取
 *  **有消息漏读的风险**

**于是就出现了消费组**

消费者组（Consumer Group）：**将多个消费者划分到一个组中，监听同一个队列。具备下列特点：**

![在这里插入图片描述][2c31f64e2fa8470794e6edfdadc17d2d.png_pic_center]

创建消费者组：

![在这里插入图片描述][882881f0e2e24df1a4b243897e5ae618.png_pic_center]

groupName：消费者组名称

ID：起始ID标示，$代表队列中最后一个消息，0则代表队列中第一个消息  
MKSTREAM：队列不存在时自动创建队列  
其它常见命令：

**删除指定的消费者组**

XGROUP DESTORY key groupName

**给指定的消费者组添加消费者**

XGROUP CREATECONSUMER key groupname consumername

**删除消费者组中的指定消费者**

XGROUP DELCONSUMER key groupname consumername

从消费者组读取消息：

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

*  group：消费组名称
 *  consumer：消费者名称，如果消费者不存在，会自动创建一个消费者
 *  count：本次查询的最大数量
 *  BLOCK milliseconds：当没有消息时最长等待时间
 *  NOACK：无需手动ACK，获取到消息后自动确认
 *  STREAMS key：指定队列名称
 *  ID：获取消息的起始ID：

“>”：从下一个未消费的消息开始  
其它：**根据指定id从pending-list中获取已消费但未确认的消息，例如0，是从pending-list中的第一个消息开始**

![在这里插入图片描述][2e76f8ab961c4e8dad4e9b307b1f063c.png_pic_center]

**STREAM类型消息队列的XREADGROUP命令特点**：

*  消息可回溯
 *  可以多消费者争抢消息，加快消费速度
 *  可以阻塞读取
 *  没有消息漏读的风险
 *  有消息确认机制，保证消息至少被消费一次

这三种结构的对比：

![在这里插入图片描述][74972c943dce42a79f693d83fc5c39d7.png_pic_center]

--------------------

> 参考:  
> [【互联网全栈架构】Redis 消息队列的三种方案（List、Streams、Pub/Sub）][Redis _List_Streams_Pub_Sub]  
> [黑马程序员Redis入门到实战教程，深度透析redis底层原理+redis分布式锁+企业解决方案+黑马点评实战项目][Redis_redis_redis]

--------------------

[1660599b4c3b40d7bad8434b139e4bb7.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/edf696d98c1a4fada286fe52dce64ded.png
[42840729cf71470aa4572d0dbb6135fc.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/0418de66d186413c9572a0235a429bfa.png
[4cabc7a0eced4dd58a59956367e949a1.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/31786ea2a1e84d8abe9376230beb022b.png
[63032ea207b94f05a05c74e1a4c80896.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/851dc4ed1df44e5b982eb7fc993d0f16.png
[71e9f96726984bb3b031baf0f91dfdde.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/d1a701c1a3924a87a692e176f947fdce.png
[47db8f2f9e52421d9aa9cc73c7fdfdde.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/856119179ec042c589d83f8f46d711c6.png
[e5f6d31d5fc14d2785c1929db8711cd6.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/fb32a01c863b47a58c5aac3acc15830f.png
[c83462c89b454a589617150a833bd857.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/3698fb612d894b128bc36a37e7d8af1f.png
[2c31f64e2fa8470794e6edfdadc17d2d.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6bae066cd52646e3bae986febb04bde0.png
[882881f0e2e24df1a4b243897e5ae618.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/f4b9936e7d554f96983f34325d2551fa.png
[2e76f8ab961c4e8dad4e9b307b1f063c.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/57be6f708b3744768e6d543fe1eb61c3.png
[74972c943dce42a79f693d83fc5c39d7.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/9a156d4ed98d480aac4d056181236ad4.png
[Redis _List_Streams_Pub_Sub]: https://blog.csdn.net/weixin_44742132/article/details/112551192
[Redis_redis_redis]: https://www.bilibili.com/video/BV1cr4y1671t/