[toc]

Redis消息队列的概述

在生活中，其实有很多的例子，都类似消息队列。

比如：工厂生产出来的面包，交给超市，商场来出售，客户通过超市，商场来买面包，客户不会针对某一个工厂去选择，只管从超市买出来，工厂也不会管是哪一个客户买了面包，只管生产出来之后，交给超市，商场来处理。

消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠传递，消息生产者只管把消息发布到消息队列中而不管谁来取，消息消费者只管从消息队列中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。

Redis 客户端可以订阅任意数量的频道。

为什么使用消息队列

首先，我们可以知道，消息队列是一种异步的工作机制，比如说日志收集系统，为了避免数据在传输过程中丢失，还有订单系统，下单后，会生成对应的单据，库存的扣减，消费信息的发送，一个下单，产生这么多的消息，都是通过一个操作的触发，然后将其他的消息放入消息队列中，依次产生。再就是很多网站的，秒杀活动之类的，前多少名用户会便宜，都是通过消息队列来实现的。

这些例子，都是通过消息队列，来实现，业务的解耦，最终数据的一致性，广播，错峰流控等等，从而完成业务的逻辑。

消息队列产品

  1. rabbit-MQ（最初起源于金融系统，用于分布式系统中存储转发消息。OpenStack）
  2. Zero-MQ（SaltStack）
  3. Kafka（JAVA）
  4. redis（key:value数据库，缓存，消息队列）

Redis发布消息-任务队列模式（queuing）

任务队列：顾名思义，就是“传递消息的队列”。与任务队列进行交互的实体有两类，一类是生产者
（producer），另一类则是消费者（consumer）。生产者将需要处理的任务放入任务队列中，而消费
者则不断地从任务独立中读入任务信息并执行。

任务队列的好处

  1. 松耦合。

    生产者和消费者只需按照约定的任务描述格式，进行编写代码。

  2. 易于扩展。

    多消费者模式下，消费者可以分布在多个不同的服务器中，由此降低单台服务器的负载。

Redis发布消息-发布-订阅模式(publish-subscribe)

其实从Pub/Sub的机制来看，它更像是一个广播系统，多个订阅者（Subscriber）可以订阅多个频道（Channel），多个发布者（Publisher）可以往多个频道（Channel）中发布消息。

简单的理解：

  1. Subscriber：收音机，可以收到多个频道，并以队列方式显示
  2. Publisher：电台，可以往不同的FM频道中发消息
  3. Channel：不同频率的FM频道

发布时订阅的分类

  • 一个发布者 多个订阅者
  • 多个发布者 一个订阅者
  • 多个发布者 多个订阅者

一个发布者 多个订阅者

image-20230529164058216

多个发布者一个订阅者模型

可以将PubSub做成独立的HTTP接口，各应用程序作为Publisher向Channel中发送消息，Subscriber端
收到消息后执行相应的业务逻辑，比如写数据库，显示等等。
主要应用：排行榜、投票、计数。

image-20230529164121759

多个发布者多个订阅者模型

故名思议，就是可以向不同的Channel中发送消息，由不同的Subscriber接收。
主要应用：群聊、聊天。

image-20230529164138021

发布订阅命令行实现

订阅单个频道

  • 发布者 10.0.0.51
  • 订阅者 10.0.0.51
1
2
3
4
5
6
7
8
9
# 订阅者订阅频道
reedis-cli --raw
127.0.0.1:6379> SUBSCRIBE fm9922

# 发布者发布消息
redis-cli --raw
127.0.0.1:6379> PUBLISH fm9922 "kiss kiss"

ps:发布的消息没有持久化，如果在订阅的客户端收不到hello，只能收到订阅后发布的消息

image-20230529164253509

订阅多个频道

  1. 发布者 10.0.0.51
  2. 订阅者 10.0.0.51
1
2
3
4
5
6
7
8
# 订阅者订阅多个频道
reedis-cli --raw
127.0.0.1:6379> SUBSCRIBE fm9922 fm9933

# 发布者发布消息
redis-cli --raw
127.0.0.1:6379> PUBLISH fm9922 "kiss kiss"
127.0.0.1:6379> PUBLISH fm9933 "kiss kiss"

image-20230529164321280

多个订阅者订阅一个频道

1
2
3
4
5
6
7
8
9
10
# 发布者 10.0.0.51
# 订阅者 10.0.0.51
# 订阅者订阅多个频道
reedis-cli --raw
127.0.0.1:6379> SUBSCRIBE fm6688
reedis-cli --raw
127.0.0.1:6379> SUBSCRIBE fm6688
# 发布者发布消息
redis-cli --raw
127.0.0.1:6379> PUBLISH fm6688 "day day up"

image-20230529164338362

客户端在执行订阅命令之后进入了订阅状态，只能接收 SUBSCRIBE 、PSUBSCRIBE、 UNSUBSCRIBE
、PUNSUBSCRIBE 四个命令。 开启的订阅客户端，无法收到该频道之前的消息，因为 Redis 不会对发
布的消息进行持久化。 和很多专业的消息队列系统（例如Kafka、RocketMQ、RabbitMQ）相比，
Redis的发布订阅略显粗糙。

**例如:**无法实现消息堆积和回溯。但胜在足够简单，如果当前场景可以容忍的这些缺点，也不失为一个不
错的选择。

取消订阅

1
2
3
4
5
# 取消订阅频道(取消订阅单个)
UNSUBSCRIBE  channel1  [channel2]

# 取消订阅模式(取消订阅多个)
PUNSUBSCRIBE  [pattern [pattern …]]

查看已有的频道

1
2
3
4
5
6
7
8
9
10
11
12
13
# 命令：
PUBSUB  subcommand [argument [argument ...]]

subcommand子命令：

# 列出当前的活跃频道,如果给定pattern参数，则会返回服务器当前被订阅的频道中与pattern模式相匹配的频道
PUBSUB CHANNELS  [pattern]

# 返回给定频道的订阅者数量，订阅模式的客户端不计算在内
PUBSUB NUMSUB [channel-1 … channel-N]

# 返回订阅模式的数量
PUBSUB NUMPAT