微消息队列

云消息队列 MQTT 版_mqtt协议_直播互动_容器与中间件-阿里云 https://www.aliyun.com/product/mq4iot

MQTT 物联网标准协议设计开放,协议简单,平台支持丰富,可连接所有移动互联网以及物联网设备

发布/订阅(Pub/Sub)支持Pub/Sub消息模型,提供一对多的消息分发方式
点对点(P2P)独家支持P2P消息模型,点对点传递模式,高效低成本
低消耗小型传输,开销小,协议交换最小化,以降低网络流量

 

三种级别 QoS 支持根据业务场景,提供三种级别的消息传递服务质量进行选择

至多一次At-Most-Once 允许消息少量丢失,最多传输一次
至少一次At-Least-Once 确保消息一定到达,可少量重复
有且仅有一次Exactly-Once 避免消息重复或丢失会导致不正确的结果
 
完善的运维配套提供一整套完善、便捷、易用的产品运维工具,帮助用户快速发现并处理问题
资源报表设备查询、分组在线设备管理、消息收发统计等
监控告警实时监控在线连接、消息堆积、投递延迟,及时发现问题
Open API(RESTful)提供自助资源管理和运维功能,RESTful 标准,灵活便捷

 

 

物联网消息
随着移动互联网以及物联网应用的蓬勃发展,阿里云推出云消息队列 MQTT 版,从而实现端(浏览器、Android、iOS、智能设备、直播互动、车联网)与云的双向通信,通过消息实现万物互联。
能够提供
大容量
移动、物联网定制,千万级设备同时在线以及毫秒级的消息推送能力,平滑的线性扩展能力,对业务完全透明。
多协议
支持 MQTT 标准协议,WebSocket 协议。

 

智能餐饮
随着物联网行业的快速发展,智能点餐服务已成为餐饮行业中的标配,消费者可通过手机 Apps(如 Android/iOS)在餐桌上扫码,并可以连接商家的智能系统,从而实现自助下单与自助支付。
能够提供
全智能交互
消费者、商家、后厨,全自助的智能设备端+云服务的双向通信能力,快速形成高效的智能点餐系统。
MQTT 标准协议
MQTT 标准协议,完全兼容社区生态,无技术绑定。
天然互通
云消息队列 MQTT 版 & 云消息队列 RocketMQ 版天然互通,从而实现设备端之间、设备端与云服务之间、云端微服务之间互联互通,完美配合。

核心概念

  • Topic:消息主题,一级消息类型,生产者向其发送消息。
  • 生产者:也称为消息发布者,负责生产并发送消息至Topic。
  • 消费者:也称为消息订阅者,负责从Topic接收并消费消息。
  • 消息:生产者向Topic发送并最终传送给消费者的数据。
  • 规则:云消息队列 MQTT 版与其他阿里云产品实现数据互通的资源。

 

 

消息收发模型

云消息队列 MQTT 版主要包含以下两种消息收发模型:

  • 终端与云端服务交互模型

    该模型中,云消息队列 MQTT 版将终端与云端连接起来,实现设备端和云端的双向通信。设备端通过云消息队列 MQTT 版可直接和云端的业务应用进行通信,也可和其他阿里云产品实现消息数据的跨产品互通。

    该模型的典型应用场景为智能设备的状态数据上报或云端控制应用的指令下发。

 

终端与终端交互模型

该模型适用于移动端App或者设备之间的数据通信,典型场景是IM通信场景中两个用户直接聊天消息,以及智能设备场景中App端控制智能设备。在该模型中消息的生产者和消费者都是分布在终端设备,通过MQTT协议连接到云消息队列 MQTT 版产品。

 根据以上两种消息收发模型,可以将使用云消息队列 MQTT 版的开发人员分为终端和云端两大类。两类开发人员所需的二次开发内容请分别参见终端开发指南云端开发指南

什么是微消息队列MQTT版_云消息队列 MQTT 版-阿里云帮助中心 https://help.aliyun.com/document_detail/42419.html

 

产品优势

 

无缝迁移

兼容任何支持MQTT 3.1.1协议的SDK,支持WebSocket协议,覆盖绝大多数移动端开发平台及语言。

 

高性能

支撑千万级设备在线连接,消息百万级并发,万亿级流转,毫秒级推送;分布式架构设计,无单点瓶颈,各组件间均可无限水平扩展。

 

安全可靠

支持设备级权限控制,支持临时Token服务以及SSL/TLS传输加密通信,确保用户数据安全可靠。

 

天然互通

可以支持微消息队列MQTT版和消息队列RocketMQ版的消息互通,从而实现设备端和云端的双向打通,更高效、更可靠。

应用场景

云消息队列 MQTT 版拥有多协议、多语言和多平台的支持能力,且广泛应用于移动互联网以及物联网领域,覆盖移动直播、车联网、金融支付、智能餐饮、即时聊天等多种应用场景。

 

名词解释

更新时间:2023-06-30 18:16:16提交缺陷

在使用云消息队列 MQTT 版前,需理解该产品和MQTT协议所涉及的基本概念和术语。

基本概念

实例(Instance)

创建购买云消息队列 MQTT 版服务的实体单元,每个云消息队列 MQTT 版实例都对应一个全局唯一的服务接入点URL。使用云消息队列 MQTT 版前都需要在对应的地域( Region)创建一个实例,并使用对应的接入点来访问服务。创建云消息队列 MQTT 版实例的步骤,请参见MQTT快速入门

Message ID
消息的全局唯一标识,由云消息队列 MQTT 版系统自动生成,唯一标识某条消息。Message ID可用于回溯消息轨迹,排查问题。更多信息,请参见消息轨迹查询
MQTT服务器
云消息队列 MQTT 版提供的MQTT协议交互的服务端节点,用于完成与MQTT客户端和云消息队列 RocketMQ 版各自的消息收发。
MQTT客户端
用于和MQTT服务器交互的移动端节点,全称为云消息队列 MQTT 版客户端。
P2P消息
云消息队列 MQTT 版在标准的MQTT协议基础上提供的一种特殊消息,该类型消息无需普通的订阅关系匹配,便可直接发送给指定的单个目标MQTT客户端。更多信息,请参见P2P消息收发模式(MQTT)
父级Topic(Parent Topic)
MQTT协议基于Pub/Sub模型,因此任何消息都属于一个Topic。根据MQTT协议,Topic存在多级,定义第一级Topic为父级Topic,使用云消息队列 MQTT 版前,需先在控制台创建该父级Topic,可以在云消息队列 MQTT 版控制台创建,或者直接在云消息队列 RocketMQ 版的控制台创建。
子级Topic(Subtopic)
MQTT的二级Topic,甚至三级Topic都是父级Topic下的子类。使用时无需在控制台创建,直接在代码中设置即可。命名格式为:父级Topic和各子级Topic间均使用正斜线(/)隔开,<父级Topic名称>/<二级Topic名称>/<三级Topic名称>,例如,SendMessage/demo/producer。需要注意的是云消息队列 MQTT 版限制父级Topic和子级Topic的总长度为64个字符,如果超出长度限制将会导致客户端异常。您可以使用MQTT.fx客户端验证子级Topic发布和订阅消息。
Client ID

云消息队列 MQTT 版的Client ID是每个客户端的唯一标识,要求全局唯一,使用相同的Client ID连接云消息队列 MQTT 版服务会被拒绝。

Client ID由两部分组成,组织形式为<GroupID>@@@<DeviceID>。Client ID的长度限制为64个字符,不允许使用不可见字符,具体限制请参见使用限制

Group ID
用于指定一组逻辑功能完全一致的节点共用的组名,代表一类相同功能的设备。Group ID需要在云消息队列 MQTT 版的控制台创建。如何创建Group ID的具体步骤请参见MQTT快速入门
Device ID
每个设备独一无二的标识,由业务方自己指定。需要保证全局唯一,例如每个传感器设备的序列号。
规则
用于实现云消息队列 MQTT 版V3.x.x版本与其他阿里云产品的数据互通的资源。分为以下三类:
  • 数据流入规则:用于从您配置的阿里云产品中读取数据并将数据通过MQTT协议推送到MQTT客户端,从而实现直接调用阿里云产品的API发送数据到MQTT客户端。更多信息,请参见跨云产品数据流入
  • 数据流出规则:用于将MQTT客户端发送的消息导出到您配置的其他阿里云产品中,从而实现直接调用云产品的API读取MQTT客户端发送的消息。更多信息,请参见跨云产品的数据流出
  • 客户端上下线通知规则:用于将获取的MQTT客户端上下线事件数据导出至其他阿里云产品。更多信息,请参见MQTT客户端上下线事件数据流出

网络类

ServerUrl

云消息队列 MQTT 版推荐移动终端使用公网接入点,也支持内网接入点。目前云消息队列 MQTT 版的接入除了支持标准协议的1883端口,同时还支持加密SSL、WebSocket等方式。接入点URL是在创建实例之后自动分配,请妥善保管。如何创建实例的步骤请参见MQTT快速入门

协议相关

MQTT
一种面向物联网和移动互联网领域的行业标准协议,适合移动终端之间的数据传输。云消息队列 MQTT 版默认支持该协议。
QoS
QoS(Quality of Service)指消息传输的服务质量。分别可在消息发送端和消息消费端设置。
  • 发送端的QoS设置:影响发送端发送消息到云消息队列 MQTT 版的传输质量。
  • 消费端的QoS设置:影响云消息队列 MQTT 版服务端投递消息到消费端的传输质量。
QoS包括以下级别:
  • QoS0:代表最多分发一次。
  • QoS1:代表至少达到一次。
  • QoS2:代表仅分发一次。
cleanSession
cleanSession标志是MQTT协议中对一个消费者客户端建立TCP连接后是否关心之前状态的定义,与消息发送端的设置无关。具体语义如下:
  • cleanSession=true:消费者客户端再次上线时,将不再关心之前所有的订阅关系以及离线消息。
  • cleanSession=false:消费者客户端再次上线时,还需要处理之前的离线消息,而之前的订阅关系也会持续生效。

QoS和cleanSession搭配使用时需注意以下几点:

  • MQTT要求每个客户端每次连接时的cleanSession标志必须固定,不允许动态变化,否则会导致离线消息的判断有误。
  • MQTT目前对外QoS2消息不支持非cleanSession,如果客户端以QoS2方式订阅消息,即使设置cleanSession=false也不会生效。
  • P2P消息的cleanSession判断以接收方客户端的配置为准。

消费端QoS和cleanSession的不同组合产生的结果如QoS和cleanSession的组合关系所示。

表 1. QoS和cleanSession的组合关系
QoS级别cleanSession=truecleanSession=false
QoS0 无离线消息,在线消息只尝试推一次。 无离线消息,在线消息只尝试推一次。
QoS1 无离线消息,在线消息保证可达。 有离线消息,所有消息保证可达。
QoS2 无离线消息,在线消息保证只推一次。 暂不支持。

 

 

 

 

终端和终端消息收发

 

该场景下消息的发送端和消费端都分布在移动终端环境,通过MQTT协议连接到云消息队列 MQTT 版。发送端和消费端的终端设备均通过开源的终端SDK接入云消息队列 MQTT 版实现消息收发。

典型场景示例

  • 即时通信:例如,两个安装有聊天App的移动手机直接通过云消息队列 MQTT 版服务端收发聊天信息。
  • 智能设备管理:例如,通过安装在手机上的App向接入到云消息队列 MQTT 版服务端的共享充电宝下发指令,充电宝收到指令消息后自动弹出。

 

终端和云端消息收发

 

该场景下消息的发送端和消费端分别为移动终端设备和部署在阿里云上的业务应用。通过云消息队列 MQTT 版实现终端和云端的消息交互。终端设备通过终端SDK接入云消息队列 MQTT 版服务端,云端应用通过云端SDK接入云消息队列 MQTT 版服务端。

典型场景示例

  • 设备状态上报:消息发送端为终端设备,消费端为云端业务应用。例如,部署在终端环境的海量电子价签定时上报自己的显示状态和节点电量等,部署在云端的管控应用根据上报的数据分析当前在线的电子价签状态,并根据业务需要进行进一步的调整。
  • 系统消息推送:消息发送端为云端业务应用,消费端为终端设备。例如,部署在云端的某游戏应用发送一条停服更新的通告,云消息队列 MQTT 版服务端将该通告推送至所有下载该游戏的手机终端上,通过手机消息提示给所有游戏用户。
  • 消息接收:云端SDK的订阅模式支持集群消费,即不同的消费端获取不同的消息。
 

获取离线MQTT消息

 

为了简化离线消息获取机制,云消息队列 MQTT 版系统在客户端成功建立连接并通过权限校验后,会自动加载离线消息并下发到客户端。

注意事项

  • 客户端建立连接后,需要通过权限校验才能自动加载离线消息。例如,若您使用的是Token验证的方式,则需要完成Token上传并通过校验后才会收到离线消息。
  • 离线消息生成需要一定的时间,因为推送的消息需要等待客户端的ack超时才会被判成离线消息。所以,如果客户端闪断重连,不一定马上可以获取到刚刚的离线消息。延迟时间一般在5秒~10秒左右。
  • 如果您的离线消息过多,即大于30条,云消息队列 MQTT 版系统会分批(5秒一次,每次30条)下发离线消息。

获取MQTT客户端在线状态

 

基本原理

云消息队列 MQTT 版服务端(下文简称为MQTT服务端)提供以下方式获取客户端在线状态:
  • 同步查询

    该方式相对简单,即通过开放的接入点地址调用HTTP/HTTPS方式的OpenAPI查询某个特定客户端的当前实时状态,适用于对单个或多个客户端的状态判断。

  • 异步上下线事件通知

    该方式使用消息通知,在客户端上线和下线事件触发时,MQTT服务端支持将上下线消息直接推送到部署在阿里云服务器上的云端应用。

    该方式属于异步感知客户端的状态,且感知到的是上下线事件,而非在线状态,云端应用需要根据事件发生的时间序列分析出客户端的状态。

应用场景

两种获取MQTT客户端在线状态的方式分别应用于以下场景:

  • 同步查询
    • 主业务流程中需要根据客户端是否在线来决定后续运行逻辑。
    • 运维过程需要判断特定客户端当前是否在线。
  • 异步上下线事件通知
    • 服务端需要在客户端上线或者下线时触发一些预定义的动作。
    • 服务端需要对客户端的上下线数据进行统计分析,并根据客户端的在线状态推送消息。

同步查询与异步事件通知的差异

两种查询方式的区别如下:
  • 同步查询是查询当前客户端的实时状态,理论上比异步通知的方式更精确。
  • 异步上下线通知因为采用消息解耦,状态判断更加复杂,且误判可能性更大,但该方法可以基于事件分析多个客户端的运行状态轨迹。异步通知虽然存在一定复杂度和误判,但更加适合大规模的客户端的状态统计。

什么是P2P模式

P2P,顾名思义,是一对一的消息收发模式,即只有一个消息发送者和一个消息接收者。而Pub/Sub模式通常用于一对多或多对多的消息群发场景,即拥有一个或多个消息发送者和多个消息接收者的场景。

在P2P模式中,发送者发送消息时已经明确该消息预期的接收者信息,并明确该消息只需要被特定的单个客户端消费。发送者发送消息时通过Topic信息直接指定接收者,接收者无需提前订阅即可获取该消息。

P2P模式不仅可以为接收者节省注册订阅关系的成本,此外,由于收发消息的链路有单独的优化,还可以降低推送延迟。

P2P模式和Pub/Sub模式的区别

云消息队列 MQTT 版中使用P2P模式收发消息与使用Pub/Sub的普通模式收发消息的区别如下所述:

  • 发送消息时,Pub/Sub模式下,发送者需要按照和接收者约定好的Topic发送消息;而P2P模式下,发送者无需事先约定传输消息的Topic,发送者可以直接按照规范发送消息到目标的接收者。
  • 接收消息时,Pub/Sub模式下,接收者需要按照和发送者约定好的Topic提前订阅才能收到消息;而P2P模式下接收者无需事先订阅即可接收消息,从而简化接收者的程序逻辑,节省订阅成本。
 
 
 
 
 
 
 
 
posted @ 2023-08-22 16:32  papering  阅读(55)  评论(0编辑  收藏  举报