首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

不同的通知不会出现在订阅同一主题的同一设备上

是因为在云计算领域中,通知服务通常采用发布-订阅模式。在该模式下,设备可以订阅特定的主题,当有新的通知发布到该主题时,订阅该主题的设备会收到相应的通知。

为了确保通知的可靠性和可扩展性,通常会使用消息队列服务来实现发布-订阅模式。消息队列服务可以将发布的通知消息存储在队列中,并按照订阅者的订阅关系将消息发送给相应的设备。

在这种情况下,不同的通知会根据其发布的主题进行分类,并且只会发送给订阅了该主题的设备。这样可以确保不同的通知不会出现在订阅同一主题的同一设备上,从而避免混淆和冲突。

举例来说,假设有一个名为"订单状态"的主题,设备A订阅了该主题,设备B订阅了另一个名为"库存变更"的主题。当有新的订单状态更新时,只会发送给设备A;而当库存发生变更时,只会发送给设备B。这样可以确保每个设备只接收到与其相关的通知,提高了通知的精确性和效率。

对于腾讯云的相关产品,可以使用腾讯云的消息队列服务CMQ(消息队列)来实现发布-订阅模式。CMQ提供了高可靠、高可用的消息传递服务,支持多种通信协议和编程语言。您可以通过腾讯云官网了解更多关于CMQ的信息:腾讯云消息队列 CMQ

总结:不同的通知不会出现在订阅同一主题的同一设备上,这是通过发布-订阅模式和消息队列服务来实现的。腾讯云的消息队列服务CMQ是一种可靠的解决方案,可以满足这一需求。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

云端协议MQTT介绍

一、简述 MQTT(Message Queuing Telemetry Transport,消息队列遥测传输协议),是一种基于发布/订阅(publish/subscribe)模式的"轻量级"通讯协议,该协议构建于TCP/IP协议上,由IBM在1999年发布。MQTT最大优点在于,可以以极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议,使其在物联网、小型设备、移动应用等方面有较广泛的应用。 MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。MQTT协议是轻量、简单、开放和易于实现的,这些特点使它适用范围非常广泛。在很多情况下,包括受限的环境中,如:机器与机器(M2M)通信和物联网(IoT)。其在,通过卫星链路通信传感器、偶尔拨号的医疗设备、智能家居、及一些小型化设备中已广泛使用。

03

[物联网]2.2接收数据

数据接收服务器的作用 数据接收服务器就跟它的字面意思一样,负责接收从设备发送来的数据。它在设备和系统之间起着桥梁作用。有很多种方法可以从设备把数据发送给服务器,其中具有代表性的包括以下两种方法。 ● 准备一个使用了 HTTP 协议的 Web API 来访问设备(如通常的 Web 系统) ● 执行语音和视频的实时通信(如 WebSocket 和 WebRTC) 除此之外,还出现了一种名为 MQTT 的、专门针对物联网的新型通信协议。 本章将为大家介绍 HTTP 协议、 WebSocket、 MQTT 这几个典型协议。 HTTP 协议 HTTP 协议提供的是最大众化且最简易的方法。使用一般的 Web 框架就可以制作数据接收服务器。设备用 HTTP 的 GET 方法和 POST 方法访问服务器,把数据存入请求参数和 BODY 并发送(图 2.6)。 HTTP 协议是 Web 的标准协议,这一点自不用说。因此 HTTP 协议和 Web 的兼容性非常强。此外,因为 HTTP 协议有非常多的技术诀窍,所以我们必须在制作实际系统时审视服务器的结构,应用程序的架构以及安全性等。关于这点,有很多事例值得参考。另外, HTTP 协议还准备了 OSS 的框架,方便人们使用。

03

MQTT协议通俗讲解

基本概念 Basic Conception Session 会话 定义 定义:某个客户端(由ClientID作为标识)和某个服务器之间的逻辑层面的通信 生命周期(存在时间):会话 >= 网络连接 ClientID 客户端唯一标识,服务端用于关联一个Session 只能包含这些 大写字母,小写字母 和 数字(0-9a-zA-Z),23个字符以内 如果 ClientID 在多次 TCP连接中保持一致,客户端和服务器端会保留会话信息(Session) 同一时间内 Server 和同一个 ClientID 只能保持一个 TCP 连接,再次连接会踢掉前一个 CleanSession 标记 在Connect时,由客户端设置 0 —— 开启会话重用机制。网络断开重连后,恢复之前的Session信息。需要客户端和服务器有相关Session持久化机制。 1 —— 关闭会话重用机制。每次Connect都是一个新Session,会话仅持续和网络连接同样长的时间。 客户端 Session 已经发送给服务端,但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息 已从服务端接收,但是还没有完成确认的 QoS 2 级别的消息 服务器端 Session 会话是否存在,即使会话状态的其它部分都是空 (SessionFlag) 客户端的订阅信息 (ClientSubcription) 已经发送给客户端,但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息 即将传输给客户端的 QoS 1 和 QoS 2 级别的消息 已从客户端接收,但是还没有完成确认的 QoS 2 级别的消息 (可选)准备发送给客户端的 QoS 0 级别的消息 长连接维护与管理 Keep Alive 心跳 目的是保持长连接的可靠性,以及双方对彼此是否在线的确认。 客户端在Connect的时候设置 Keep Alive 时长。如果服务端在 1.5 * KeepAlive 时间内没有收到客户端的报文,它必须断开客户端的网络连接 Keep Alive 的值由具体应用指定,一般是几分钟。允许的最大值是 18 小时 12 分 15 秒 Will 遗嘱 遗嘱消息(Will Message)存储在服务端,当网络连接关闭时,服务端必须发布这个遗嘱消息,所以被形象地称之为遗嘱,可用于通知异常断线。 客户端发送 DISCONNECT 关闭链接,遗嘱失效并删除 遗嘱消息发布的条件,包括: 服务端检测到了一个 I/O 错误或者网络故障 客户端在保持连接(Keep Alive)的时间内未能通讯 客户端没有先发送 DISCONNECT 报文直接关闭了网络连接 由于协议错误服务端关闭了网络连接 相关设置项,需要在Connect时,由客户端指定 Will Flag —— 遗嘱的总开关 0 -- 关闭遗嘱功能,Will QoS 和 Will Retain 必须为 0 1 -- 开启遗嘱功能,需要设置 Will Retain 和 Will QoS Will QoS —— 遗嘱消息 QoS 可取值 0、1、2,含义与消息QoS相同 Will Retain —— 遗嘱是否保留 0 -- 遗嘱消息不保留,后面再订阅不会收到消息 1 -- 遗嘱消息保留,持久存储 Will Topic —— 遗嘱话题 Will Payload —— 遗嘱消息内容 消息基本概念 报文标识 Packet Identifier 存在报文的可变报头部分,非零两个字节整数 (0-65535] 一个流程中重复:这些报文包含 PacketID,而且在一次通信流程内保持一致: PUBLISH(QoS>0 时),PUBACK,PUBREC,PUBREL,PUBCOMP SUBSCRIBE, SUBACK UNSUBSCIBE,UNSUBACK 新的不重复:客户端每次发送一个新的这些类型的报文时都必须分配一个当前 未使用的PacketID 当客户端处理完这个报文对应的确认后,这个报文标识符就释放可重用。 独立维护:客户端和服务端彼此独立地分配报文标识符。因此,客户端服务端组合使用相同的报文标识符可以实

01
领券