1、Redis 发布订阅理论概述
Redis 发布/订阅是一种消息传模式,其中发送者(发布者)发送消息,而接收者(订阅者)接收消息,可以实现进程间的消息传递。传递消息的通道称为channel
在Redis中,客户端可以订阅任意数量的频道。类似我们的微信关注多个公众号
下图展示了频道 channel1 , 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系:
当有新消息通过 PUBLISH 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个客户端:
发布/订阅其实是一个轻量的队列,只不过数据不会被持久化, 一般用来处理实时性较高的异步消息
2、常用命令
命令 | 描述 |
---|---|
PSUBSCRIBE pattern [pattern …] | 订阅一个或多个符合给定模式(支持*号?号之类的)的频道 |
PUBSUB subcommand [argument [argument …]] | 查看订阅与发布系统状态 |
PUBLISH channel message | 将信息发送到指定的频道 |
PUNSUBSCRIBE [pattern [pattern …]] | 退订所有给定模式的频道 |
SUBSCRIBE channel [channel …] | 订阅给定的一个或多个频道的信息 |
UNSUBSCRIBE [channel [channel …]] | 指退订给定的频道 |
SUBSCRIBE channel [channel …]
推荐先执行订阅后再发布,因为订阅成功之前发布的消息是收不到的,消息不能被别被人接受,那么该消息是毫无意义的
订阅的客户端每次可以收到一个3个参数的消息
消息的种类
始发频道的名称
实际的消息内容
PUBSUB subcommand [argument [argument …]]
PUBSUB CHANNELS
由具体名字的活跃频道组成的列表
PUBSUB NUMSUB [channel [channel …]]
某个频道有几个订阅者
PUBSUB NUMPAT
只统计使用PSUBSCRIBE命令执行的,返回客户端订阅的唯一模式的数量
3、发布订阅实操
如果没有任何人订阅某个频道,此时发布信息是无意义的,例如:
开启3个客户端,演示客户端1、2订阅消息,客户端3发布消息
第一个 redis-cli 客户端订阅c1:
第二个 redis-cli 客户端订阅c1和c2:
第三个 redis-cli 客户端向c1频道发布消息:
两个客户端收到了,分别是客户端1和客户端2:
演示批量订阅和发布
在客户端3中,使用 PUBSUB NUMPAT 统计使用 PSUBSCRIBE 命令执行的:
此时并没有
在客户端4中使用 PSUBSCRIBE 订阅 c*,a?
再在客户端3中执行 PUBSUB NUMPAT 命令和 PUBSUB CHANNELS
PUBSUB NUMPAT不会计算模式批量订阅
在客户端3中向c1发布消息
三个客户端收到了消息,因为客户端1和2订阅了频道c1,而客户端4订阅了模糊频道c*
在客户端3向c11发布消息
只有一个客户端收到了消息,毫无疑问是客户端4,因为它订阅了c*
取消订阅
客户端2取消订阅c1和c2
按ctrl+c,然后使用命令 UNSUBSCRIBE
4、总结
Redis可以实现消息中间件MQ的功能,通过发布订阅实现消息的引导和分流。仅代表我个人,不推荐使用该功能,专业的事情交给专业的中间件处理,redis就做好分布式缓存功能即可
缺点:
- 发布的消息在Redis系统中不能持久化,因此,必须先执行订阅,再等待消息发布。如果先发布了消息,那么该消息由于没有订阅者,消息将被直接丢失
- 消息只管发送对于发布者而言消息是即发即失的,不管接收,也没有ACK机制,无法保证消息的消费成功
- 由于Redis的发布订阅模式缺点严重,在生产环境中几乎无用武之地,因此Redis5.0版本新增了Stream数据结构,不但支持多播,还支持数据持久化,相比Pub/Sub更加的强大