当前位置:网站首页>Redis之发布订阅

Redis之发布订阅

2022-07-06 08:59:00 ~庞贝

Redis之发布订阅

1.发布订阅介绍

Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。
Redis 客户端可以订阅任意数量的频道。
Redis 提供了基于「发布/订阅」模式的消息机制,在这种模式下,消息发布者与订阅者不需要进行直接通信。
下图展示了频道 channel1 , 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QYPwOc9W-1656468585459)(C:/Users/86158/AppData/Roaming/Typora/typora-user-images/image-20220629092442701.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GpVSVwBL-1656468585460)(C:/Users/86158/AppData/Roaming/Typora/typora-user-images/image-20220629092454345.png)]

当有新消息通过 PUBLISH 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个客户端:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BmRYSWOk-1656468585460)(C:/Users/86158/AppData/Roaming/Typora/typora-user-images/image-20220629092514496.png)]

2.发布订阅应用场景

假设我们有这么一个业务场景,在网站下单支付以后,需要通知库存服务进行发货处理。
上面业务实现不难,我们只要让库存服务提供给相关的给口,下单支付之后只要调用库存服务即可。

在这里插入图片描述

后面如果又有新的业务,比如说积分服务,他需要获取下单支付的结果,然后增加用户的积分。
这个实现也不难,让积分服务同样提供一个接口,下单支付之后只要调用库存服务即可。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B4RrhzqZ-1656468585461)(C:/Users/86158/AppData/Roaming/Typora/typora-user-images/image-20220629092747075.png)]

如果就两个业务需要获取下单支付的结果,那也还好,程序改造也快。可是随着业务不断的发展,越来越多的新业务说是要下单支付的结果。
这时我们会发现上面这样的系统架构存在很多问题:
第一,下单支付业务与其他业务重度耦合,每当有个新业务需要支付结果,就需要改动下单支付的业务。
第二,如果调用业务过多,会导致下单支付接口响应时间变长。另外,如果有任一下游接口响应变慢,就会同步导致下单支付接口响应也变长。
第三,如果任一下游接口失败,可能导致数据不一致的情况。比如说下图,先调用 A,成功之后再调用 B,最后再调用 C。
如果在调用 B 接口的发生异常,此时可能就导致下单支付接口返回失败,但是此时 A 接口其实已经调用成功,这就代表它内部已经处理下单支付成功的结果。
这样就会导致 A,B,C 三个下游接口,A 获取成功获取支付结果,但是 B,C 没有拿到,导致三者系统数据不一致的情况。
其实我们仔细想一下,对于下单支付业务来讲,它其实不需要关心下游调用结果,只要有某种机制通知能通知到他们就可以了。
讲到这里,这就需要引入今天需要介绍发布订阅机制。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WEWireSG-1656468585461)(C:/Users/86158/AppData/Roaming/Typora/typora-user-images/image-20220629095040384.png)]

使用 Redis 发布订阅这种机制,对于上面业务,下单支付业务只需要向支付结果这个频道发送消息,其他下游业务订阅支付结果这个频道,就能收相应消息,然后做出业务处理即可。
这样就可以解耦系统上下游之间调用关系。

3.实例

以下实例演示了发布订阅是如何工作的。在我们实例中我们创建了订阅频道名为 redisChat:

 SUBSCRIBE redisChat

在这里插入图片描述

现在,我们先重新开启个 redis 客户端,然后在同一个频道 redisChat 发布两次消息,订阅者就能接收到消息。
订阅者的客户端会显示如下消息

PUBLISH redisChat "Redis is a great caching technique"

在这里插入图片描述

PUBLISH redisChat "Learn redis by w3cschool.cc"

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-liCreDDl-1656468585462)(C:/Users/86158/AppData/Roaming/Typora/typora-user-images/image-20220629095644923.png)]

Pubsub 命令用于查看订阅与发布系统状态,可以看得到有一个
注意:不要写成 pubsub redisChat

 PUBSUB CHANNELS!

在这里插入图片描述

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OibXwJKi-1656468585462)(C:/Users/86158/AppData/Roaming/Typora/typora-user-images/image-20220629095811652.png)]

把左边客户端ctrl+c关闭后,右边再次查找的时候,发现已经空了

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MWIEDufB-1656468585462)(C:/Users/86158/AppData/Roaming/Typora/typora-user-images/image-20220629100055201.png)]

4.publish

Publish 命令用于将信息发送到指定的频道。
返回值:接收到信息的订阅者数量。

PUBLISH channel message

5.subscribe

Subscribe 命令用于订阅给定的一个或多个频道的信息。
我们子在使用订阅命令,需要主要几点:
第一,客户端执行订阅指令之后,就会进入订阅状态,之后就只能接收 subscribe、psubscribe、unsubscribe、punsubscribe 这四个命令。
第二,新订阅的客户端,是无法收到这个频道之前的消息,这是因为 Redis 并不会对发布的消息持久化的。
返回值:接收到的信息

相比于很多专业 MQ,比如 kafka、rocketmq 来说, redis 发布订阅功能就显得有点简陋了。不过 redis 发布订阅功能胜在简单,如果当前场景可以容忍这些缺点,还是可以选择使用的。

SUBSCRIBE channel [channel ...]

6.psubscribe

Psubscribe 命令订阅一个或多个符合给定模式的频道。
每个模式以 * 作为匹配符,比如 it* 匹配所有以 it 开头的频道( it.news 、 it.blog 、 it.tweets 等等)。 news.* 匹配所有以 news. 开头的频道( news.it 、 news.global.today 等等),诸如此类。
返回接收到的信息

PSUBSCRIBE pattern [pattern ...]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-a1EsdK2y-1656468585463)(C:/Users/86158/AppData/Roaming/Typora/typora-user-images/image-20220629100645723.png)]

7.pubsub

Pubsub 命令用于查看订阅与发布系统状态,它由数个不同格式的子命令组成。
返回值:由活跃频道组成的列表

PUBSUB <subcommand> [argument [argument ...]]

8.unsubscribe

命令用于退订给定的一个或多个频道的信息。
返回值:这个命令在不同的客户端中有不同的表现。

 UNSUBSCRIBE channel [channel ...]

9.punsubscribe

Punsubscribe 命令用于退订所有给定模式的频道。
返回值:这个命令在不同的客户端中有不同的表现

PUNSUBSCRIBE [pattern [pattern ...]]
原网站

版权声明
本文为[~庞贝]所创,转载请带上原文链接,感谢
https://blog.csdn.net/qq_53267860/article/details/125515148