【Redis 系列】redis 学习九,Redis 的发布和订阅是咋玩的
Redis 发布订阅
Redis 发布订阅(pub / sub)是一种消息通信模式
- 发送者发送消息 pub
- 接受者订阅消息 sub
例如微信,微博这样的关注系统
Redis 的客户端可以订阅任意数量的频道,不受限制
来看看图示
- 消息发布者
- 消息订阅者
- 频道
这里的消息发布者,和消息订阅者都是 redis 客户端, 订阅者订阅某个频道,发布者在该频道中发布相关信息,例如文章,例如沸点,等等,消息订阅者就能实时收到刚才发布者发送的内容了
如下图中,频道 channel1
以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系:
当有新消息通过 PUBLISH 命令发送给频道 channel1 时
这个消息就会被发送给订阅它的三个客户端:
常用命令
下表列出了 redis 发布订阅常用命令:
序号 | 命令及描述 |
---|
实际测试和验证
- subscribe channel [channel ...]
订阅一个或者多个通道
- PUBLISH channel message
向频道中发送消息
接收端:
接收端订阅 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 会广播所有的发布的消息到所有的节点,如果发布的消息较大,网络开销将会很大,因此需要避免发送大消息
Redis 发布/订阅应用场景
1、实时消息系统
2、即时通信,频道作为聊天室,将信息回显给订阅频道的所有人
3、订阅系统,关注系统都是 ok 的
对于复杂的场景,我们就不用考虑 redis 了,可以直接使用专业的 MQ 开源组件,例如 rabbitMQ 或者 kafka
使用 Redis 发布/订阅 需要注意的点
使用 Redis 发布/订阅是有缺陷的
1、对于消息处理可靠性要求不强
2、消费能力无需通过增加消费方进行增强
参考资料:redis_doc