Redis 发布订阅(pub / sub)是一种消息通信模式
例如微信,微博这样的关注系统
Redis 的客户端可以订阅任意数量的频道,不受限制
这里的消息发布者,和消息订阅者都是 redis 客户端, 订阅者订阅某个频道,发布者在该频道中发布相关信息,例如文章,例如沸点,等等,消息订阅者就能实时收到刚才发布者发送的内容了
如下图中,频道 channel1
以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系:
当有新消息通过 PUBLISH 命令发送给频道 channel1 时
这个消息就会被发送给订阅它的三个客户端:
下表列出了 redis 发布订阅常用命令:
序号 | 命令及描述 |
---|---|
1 | PSUBSCRIBE pattern [pattern ...]订阅一个或多个符合给定模式的频道。 |
2 | PUBSUB subcommand [argument [argument ...]查看订阅与发布系统状态。 |
3 | PUBLISH channel message将信息发送到指定的频道。 |
4 | [PUNSUBSCRIBE [pattern [pattern ...]退订所有给定模式的频道。 |
5 | SUBSCRIBE channel [channel ...] 订阅给定的一个或多个频道的信息。 |
6 | UNSUBSCRIBE [channel [channel ...] 指退订给定的频道。 |
订阅一个或者多个通道
向频道中发送消息
接收端:
接收端订阅 xiaomotong 频道,只要发送端有 publish 消息到频道中,接收端就能马上收到
127.0.0.1:6379> subscribe xiaomotong
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "xiaomotong"
3) (integer) 1
1) "message"
2) "xiaomotong"
3) "hellowrold"
1) "message"
2) "xiaomotong"
3) "hello_redis"
1) "message"
2) "xiaomotong"
3) "xiaozhupeiqi"
发送端:
发送端向 xiaomotong 频道依次发送 message ,hellowrold,hello_redis,xiaozhupeiqi
root@iZuf66y3tuzn4wp3h02t7pZ:~# redis-cli
127.0.0.1:6379> publish xiaomotong hellowrold
(integer) 1
127.0.0.1:6379> publish xiaomotong hello_redis
(integer) 1
127.0.0.1:6379> publish xiaomotong xiaozhupeiqi
(integer) 1
那么这个实现的原理是啥呢?
redis 是 C 语言实现的,单进程的开源组件
通过分析 redis 源码里面的 publish.c 文件,我们可以了解到 redis 发布订阅的底层实现,这能加深我们对 redis 的理解
redis 通过 publish ,subscribe 和 psubscribe 等命令来实现发布和订阅功能
例如我们每个人都会使用的微信:
subscribe
通过 subscribe 订阅某个频道后,redis-server 内部会维护一个字典,字典的键就是这个频道的名字,而字典的值是一个链表,这个链表里面保存了所有订阅这个频道的客户端
因此,我们就知道,subscribe 指令就是将客户端添加到频道的订阅链表里面
publish
redis 通过 publish 向频道中发送消息,redis-server 会使用给定的键作为频道的名字,在它自己维护的频道字典里面记录了订阅这个频道所有的客户端的链表,遍历这个链表,将消息发送给所有的订阅者
pub / sub
pub / sub 见名知意就是发布(publish)和订阅(subscribe)
在 redis 里面,我们可以设定对某一个 key 值,进行消息发布及消息订阅,当在一个 key 值上面进行了消息发布后,所有订阅他的客户端都会收到它刚才发布的消息,这一功能最明显的用法就是用作实时消息系统
例如我们平常都会使用到的聊天系统,即时通信系统等等
但是这里我们需要注意
Redis 集群为了实现所有订阅的客户端都可以接收到发布的消息,但是不同的客户端可能连接的是不同的主节点,为此 redis 会广播所有的发布的消息到所有的节点,如果发布的消息较大,网络开销将会很大,因此需要避免发送大消息
1、实时消息系统
2、即时通信,频道作为聊天室,将信息回显给订阅频道的所有人
3、订阅系统,关注系统都是 ok 的
对于复杂的场景,我们就不用考虑 redis 了,可以直接使用专业的 MQ 开源组件,例如 rabbitMQ 或者 kafka
使用 Redis 发布/订阅是有缺陷的
1、对于消息处理可靠性要求不强
2、消费能力无需通过增加消费方进行增强
参考资料:
redis_doc
朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力
好了,本次就到这里
技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。
我是小魔童哪吒,欢迎点赞关注收藏,下次见~