扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这期内容当中小编将会给大家带来有关redis中怎么实现发布订阅模式,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。
为亳州等地区用户提供了全套网页设计制作服务,及亳州网站建设行业解决方案。主营业务为成都做网站、网站设计、亳州网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!
发布订阅(pub/sub)是一种消息通信模式:发送者(pub)在某一频道发送消息,订阅者(sub)接收消息。发布订阅模式类似与微博关注,比如说博主mango被张三、李四、王五关注,那么mango发一篇微博的时候张李王三人都会从关注里看到这条微博。
那么发布订阅和生产消费有何异同之处呢?生产消费主要是生成一个消息只能被一个客户端消费,而发布订阅可以理解为发布一条消息,在该频道中的所有客户端都会收到,所以有时候我们这个发布订阅类似广播。
注意pubsub是一个数据结构。
前面提到客户端能接受到消息首先要订阅频道,那么redis中的订阅命令subscribe channel [channel ...] 这里可以订阅多个频道。订阅后我们需要发布消息到这个频道中publish channel message。
####订阅test频道> subscribe testReading messages... (press Ctrl-C to quit)1) "subscribe"2) "test"3) (integer) 1
####发布信息> publish test 'hello'(integer) 1
不是可以广播嘛,那么我们再起一个客户端
当然redis还提供退订unsubscribe 跟subscribe 的使用方式一样。
PUBSUB是一个查看订阅与发布系统状态的内省命令,它由数个不同格式的子命令组成。
PUBSUB CHANNELS [pattern]列出当前的活跃频道。活跃频道指的是那些至少有一个订阅者的频道, 订阅模式的客户端不计算在内。
pattern 参数是可选的:
如果不给出 pattern 参数,那么列出订阅与发布系统中的所有活跃频道。
如果给出 pattern 参数,那么只列出和给定模式 pattern 相匹配的那些活跃频道。
> pubsub channels1) "test"
PUBSUB NUMSUB [channel-1 ... channel-N]列出当前的活跃频道和返回连接数
> pubsub numsub test1) "test" #频道2) (integer) 2 #连接数> pubsub numsub test11) "test1"2) (integer) 0
注意,这个命令返回的不是订阅模式的客户端的数量,而是客户端订阅的所有模式的数量总和,可以理解为模式匹配,例如订阅一个test*,客户端能接收test、test1、test2等等这样的,看下面例子。
####客户端> psubscribe test*Reading messages... (press Ctrl-C to quit)1) "psubscribe"2) "test*"3) (integer) 1
> pubsub numpat(integer) 1
模式匹配订阅
介绍完发布订阅的一般模式,此时我们小伙伴就问,长得跟mango一样的我能不能订阅呢?当然redis是支持这种模糊订阅的,其命令为psubscribe,跟subscribe使用方式一致。
> psubscribe test*Reading messages... (press Ctrl-C to quit)1) "psubscribe"2) "test*"3) (integer) 1
我们直到redis是key-value键值对的字典,PubSub前面讲过是一个数据结构,那么它是如何存储在内存中的呢?看老夫画图来解答。
我们从图中可以看到每个频道放入字典数组中,对应频道的订阅者则放入链表中,当我们发送一个publish命令时,首先字典数组遍历找到对应的频道,然后找到对应的订阅链,依次发送消息。
所以我们可以看出每次发送消息时我们的都需要遍历这个字典,也就是说它的执行时间效率为O(n),但是我们redis的宗旨是快,减少执行O(n)的命令,这违背了我们当初的初衷
PubSub的发布者传递过来一个消息,Redis会直接找到相应的订阅者传递过去。如果一个订阅者都没有,那么消息会被直接丢弃。如果开始有三个订阅者,第三个订阅者突然挂掉了,发布者会继续发送消息,另外两个订阅者可以持续收到消息,但是当挂掉的订阅者重新连上的时候,在断连期间发布者发送的消息,对于这个发布者来说就是彻底丢失了。
如果Redis停机重启,PubSub的消息是不会持久化的,毕竟Redis开机就相当于一个订阅者都没有,所有的消息会被直接丢弃。正是因为PubSub有这些缺点,在消息队列的领域它几乎找不到合适的应用场景。
所以Redis的作者单独开启了一个项目Disque专门用来做多播消息队列,不过该项目目前没有成熟,直处于Beta版本。
1.难以保证消息队列的ACK,消息发送出去后没有一个回馈过程,消息无法做持久化
2.如果保证消息持久化,那么必定损失性能,首先我们需要把消息存入磁盘,然后从磁盘中读取数据到内存去操作,这个过程是非常耗时的
3.PubSub执行效率低,执行效率是O(n),违背了redis设计初衷
4.难以实现复杂的消息模式
上述就是小编为大家分享的Redis中怎么实现发布订阅模式了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注创新互联行业资讯频道。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流