前言
发布订阅在设计模式中也可以说是观察者模式,针对这个模式是处理对象间一对多的依赖关系的,当一个对象发生变化,其它依赖他的对象都要得到通知并更新。
然而它也有自己的缺点,就是当主题发生一系列的变化时,观察者都要做批量的更新,如果这样的更新成本很高,那么解决方法就是根据种类需求通知,而不能盲目的通知所有的观察者。
那针对这个缺点,一般的情况下,你没有需求谁订阅一个跟自己无关的消息推送呢?这也正好说明推送的消息需要整理而不能一窝蜂的什么消息都往一个通道里面抛,要分而治之,合理的设计发布通道的用途,也合理的订阅通道。
那么如此一来,升级到系统项目级别,他别给我们又带来啦,莫大的好处,便是:剥离系统耦合,减少单线功能的依赖关系,又正迎合啦高内聚,松耦合的系统架构设计。
Redis中的发布/订阅功能
这一节参考官方文档:https://redis.io/topics/pubsub
首先我准备啦1个redis服务,3个客户端,如下图所示:
然后打开官方文档,首先可以看到以下6个命令,对,就只有这6个命令,只要你能掌握理解,发散思维灵活运用。吐纳,吐纳,那么道于此,生一,生二、生三,生万物,根本不在话下!!C,C,C,WC, 小伙,以后拯救世界就看你啦。
下面我们使用这几个命令,做一个演示,便于你理解。
1、2个客户端订阅order.create通道消息,如下:
2、最后一个客户端发布往order.create通道发布消息。如下:
3、你会立马发现订阅此通道的另外2个客户端有信息输出出来,如下:
简单不,一个发布订阅的基础功能以及完事啦。
那如果你对其他一些发布订阅管理系统比较了解的话,你立马会想到一个功能,类似rabbitmq中的topic类型的匹配功能。那redis中有吗,就这6个命令,答案是有的。使用的命令为psubscribe。
127.0.0.1:6379> psubscribe * ---订阅所有通道 127.0.0.1:6379> psubscribe order.* ---订阅通道名称以order.开头的所有通道消息
那又如何取消订阅过的通道呢?
127.0.0.1:6379> unsubscribe order.create ---取消订阅 127.0.0.1:6379> punsubscribe order.* ---取消订阅通道名称以order.开头的所有通道消息
如何查看订阅信息呢?
127.0.0.1:6379> pubsub channels ---查看当前服务器订阅的所有通道 127.0.0.1:6379> pubsub channels order.* ---查看订阅通道名称以order.开头的所有通道 127.0.0.1:6379> pubsub numsub order.create user ---查看订阅order.create 和user 通道的订阅者数量,支持查询多个通道
呀,到此为止,6个命令已经用完啦。就是这么任性,对,你潜心修炼10多分钟已经学会啦redis中最上层的发布订阅技能。你可以出关,打败天下无敌手啦。
StackExchange.Redis实现redis中的发布订阅功能
那这一节呢,我也实在说不出怎么讲更合理点,我就上一个示例,你自己把代码拷贝去,玩玩吧。上代码。
static void Main(string[] args) { Console.WriteLine("请输入发布订阅类型?"); var type = Console.ReadLine(); if (type == "publish") { html" target="_blank">while (true) { Console.WriteLine("请输入要发布向哪个通道?"); var channel = Console.ReadLine(); Console.WriteLine("请输入要发布的消息内容."); var message = Console.ReadLine(); sub.Publish(channel, message); } } else { Console.WriteLine("请输入您要订阅哪个通道的信息?"); var channelKey = Console.ReadLine(); sub.Subscribe(channelKey, (channel, message) => { Console.WriteLine("接受到发布的内容为:" + message); }); Console.WriteLine("您订阅的通道为:<< "+ channelKey + " >> ! 一切就绪,等待发布消息!勿动,一动就没啦!!"); Console.ReadKey(); } }
运行起来几个实例,来玩一玩。如下,5个,1个发布信息,4个订阅信息,其中2个订阅zhanglonghao通道,2个订阅bokeyuan通道。
第一次我发布消息到zhanglonghao通道,发布的消息为:hello shuaige !!如下:
可以看出只有订阅zhanglonghao通道的才接受到啦消息。
那再往bokeyuan通道里面发送,hello bokeyuan !
到此为止,自己玩去吧。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流,谢谢大家对小牛知识库的支持。
我是MQTT的新手,我有一些问题希望你们能帮助我。我正在做一个学校项目,需要我使用MQTT协议,程序需要用C语言编写。(只是一些背景信息) > MQTT客户端可以同时是发布服务器和订阅服务器吗?也就是说,在不断等待从代理接收消息并执行结果操作的同时,它还能够在需要时将消息发布到代理。 我对MQTT的理解是:MQTT发布者-->MQTT代理-->MQTT订阅者 用白痴的话来说,MQTT的异步模式到底
主要内容:发布/订阅流程,常用命令汇总,基本命令应用Redis PubSub 模块又称发布订阅者模式,是一种消息传递系统,实现了消息多播功能。发布者(即发送方)发送消息,订阅者(即接收方)接收消息,而用来传递消息的链路则被称为 channel。在 Redis 中,一个客户端可以订阅任意数量的 channel(可译为频道)。 消息多播:生产者生产一次消息,中间件负责将消息复制到多个消息队列中,每个消息队列由相应的消费组进行消费,这是分布式系统常用的
本文向大家介绍Redis 订阅发布_Jedis实现方法,包括了Redis 订阅发布_Jedis实现方法的使用技巧和注意事项,需要的朋友参考一下 我想到使用Redis的订阅发布模式是用来解决推送问题的~。 对于概念性的叙述,多多少少还是要提一下的: 什么是Redis发布订阅?Redis发布订阅是一种消息通信模式,发送者通过通道A发送消息message,订阅过通道A的客户端就可以接收到消息messag
Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。 Redis 客户端可以订阅任意数量的频道。 下图展示了频道 channel1 , 以及订阅这个频道的三个客户端 —— client2、client5 和 client1 之间的关系: 当有新消息通过 PUBLISH 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个
问题内容: 我正在尝试使用nodejs和node_redis构建一个通用的发布/订阅服务器,该服务器接收带有通道名称的浏览器的请求,并以该通道也已发布的任何数据作为响应。为此,我使用了来自浏览器的长轮询请求,并通过在通道上收到消息时发送响应来处理这些请求。 对于每个新请求,都会创建一个对象来订阅该频道(如果且仅当该频道不存在时)。 这是处理订阅渠道的最佳方法,还是还有其他更直观的方法? 问题答案:
目前,我正在开发一个分布式测试执行和报告系统。我计划将Redis PUB/SUB用作消息队列和消息分发系统。 我是Redis的新手,所以我试着阅读尽可能多的文档,并尝试着使用它。最重要的主题之一是高可用性。正如我所说,我不是专家,但我知道可能的选择——使用Sentinel、复制、集群等。 我不清楚的是Pub/Sub功能和HA选项是如何相互关联的。使用Redis构建可靠消息传递系统的最佳实践是什么?