MQTT协议

MQTT协议简介

MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)是IBM开发的一个即时通讯协议,该协议支持所有平台,几乎可以把所有联网物品和外部连接起来,被用来当做传感器和致动器(比如通过Twitter让房屋联网)的通信协议。

虽然HTTP是网页的事实标准,不过机器之间(Machine-to-Machine,M2M)的大规模沟通需要不同的模式:之前的请求/回答(Request/Response)模式不再合适,取而代之的是发布/订阅(Publish/Subscribe)模式。这就是轻量级、可扩展的MQTT(Message Queuing Telemetry Transport)可以施展拳脚的舞台。

MQTT是基于二进制消息的发布/订阅编程模式的消息协议,最早由IBM提出的,如今已经成为OASIS规范。由于规范很简单,非常适合需要低功耗和网络带宽有限的IoT场景,比如:

· 遥感数据

· 汽车

· 智能家居

· 智慧城市

· 医疗医护

MQTT设计特点

由于物联网的环境是非常特别的,所以MQTT遵循以下设计原则:

1 精简,不添加可有可无的功能。

2 发布/订阅(Pub/Sub)模式,方便消息在传感器之间传递。

3 允许用户动态创建主题,零运维成本。

4 把传输量降到最低以提高传输效率。

5 把低带宽、高延迟、不稳定的网络等因素考虑在内。

6 支持连续的会话控制。

7 理解客户端计算能力可能很低。

8 提供服务质量管理。

9 假设数据不可知,不强求传输数据的类型与格式,保持灵活性。

MQTT协议入门

运用MQTT协议,设备可以很方便地连接到物联网云服务,管理设备并处理数据,最后应用到各种业务场景,如下图所示:

发布/订阅模式

与请求/回答这种同步模式不同,发布/订阅模式解耦了发布消息的客户(发布者)与订阅消息的客户(订阅者)之间的关系,这意味着发布者和订阅者之间并不需要直接建立联系。打个比方,你打电话给朋友,一直要等到朋友接电话了才能够开始交流,是一个典型的同步请求/回答的场景;而给一个好友邮件列表发电子邮件就不一样,你发好电子邮件该干嘛干嘛,好友们到有空了去查看邮件就是了,是一个典型的异步发布/订阅的场景。

熟悉编程的同学一定非常熟悉这种设计模式了,因为它带来了这些好处:

· 发布者与订阅者不必了解彼此,只要认识同一个消息代理即可。

· 发布者和订阅者不需要交互,发布者无需等待订阅者确认而导致锁定。

· 发布者和订阅者不需要同时在线,可以自由选择时间来消费消息。

主题

MQTT是通过主题对消息进行分类的,本质上就是一个UTF-8的字符串,不过可以通过反斜杠表示多个层级关系。主题并不需要创建,直接使用就是了。

主题还可以通过通配符进行过滤。其中,+可以过滤一个层级,而#只能出现在主题最后表示过滤任意级别的层级。

举个例子:

· building-b/floor-5:代表B楼5层的设备。

· +/floor-5:代表任何一个楼的5层的设备。

· building-b/#:代表B楼所有的设备。

注意,MQTT允许使用通配符订阅主题,但是并不允许使用通配符广播。

服务质量

为了满足不同的场景,MQTT支持三种不同级别的服务质量(Quality of Service,QoS)为不同场景提供消息可靠性:

· 级别0:尽力而为。消息发送者会想尽办法发送消息,但是遇到意外并不会重试。

· 级别1:至少一次。消息接收者如果没有知会或者知会本身丢失,消息发送者会再次发送以保证消息接收者至少会收到一次,当然可能造成重复消息。

· 级别2:恰好一次。保证这种语义肯定会减少并发或者增加延时,不过丢失或者重复消息是不可接受的时候,级别2是最合适的。

服务质量是个老话题了。级别2所提供的不重不丢很多情况下是最理想的,不过往返多次的确认一定对并发和延迟带来影响。级别1提供的至少一次语义在日志处理这种场景下是完全OK的,所以像Kafka这类的系统利用这一特点减少确认从而大大提高了并发。级别0适合鸡肋数据场景,食之无味弃之可惜,就这么着吧。

消息类型

MQTT拥有14种不同的消息类型:

1 CONNECT:客户端连接到MQTT代理

2 CONNACK:连接确认

3 PUBLISH:新发布消息

4 PUBACK:新发布消息确认,是QoS 1给PUBLISH消息的回复

5 PUBREC:QoS 2消息流的第一部分,表示消息发布已记录

6 PUBREL:QoS 2消息流的第二部分,表示消息发布已释放

7 PUBCOMP:QoS 2消息流的第三部分,表示消息发布完成

8 SUBSCRIBE:客户端订阅某个主题

9 SUBACK:对于SUBSCRIBE消息的确认

10 UNSUBSCRIBE:客户端终止订阅的消息

11 UNSUBACK:对于UNSUBSCRIBE消息的确认

12 PINGREQ:心跳

13 PINGRESP:确认心跳

14 DISCONNECT:客户端终止连接前优雅地通知MQTT代理

MQTT和Kafka的异同

两者虽然都是从传统的Pub/Sub消息系统演化出来的,但是进化的方向不一样,以下是几个比较突出的点:

1)Kafka是为了数据集成的场景,与以往Pub/Sub消息总线不一样,通过分布式架构提供了海量消息处理、高容错的方式存储海量数据流、保证数据流的顺序等特性。

2)MQTT是为了物联网场景而优化,不但提供多个QoS选项(exact once、at least once、at most once),而且还有层级主题、遗嘱等等特性。

说白了都是传统消息系统与不同的场景结合的产物。不过,两者却可以结合起来使用。比如可以用MQTT接受物联网设备上传的数据,然后接入Kafka,最后可以同时分发到HDFS归档、数据仓库做OLAP分析、Elasticsearch做全文检索,这样的架构非常适合大型物联网项目,不但能够处理海量数据同时也具有很好的扩展性。

参考文献

1)MQTT 入门:http://dataguild.org/?p=6817

原文发布于微信公众号 - 大数据和云计算技术(jiezhu2007)

原文发表时间:2017-04-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏PHP技术

高并发量网站解决方案

一个小型的网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构、性 能的要求都很简单。随...

3578
来自专栏CSDN技术头条

用最少的钱,实现工程效率实践

研发团队的工程效率实践,现在越来越多的人开始谈论这个话题,但是真真能实操的还本场 Chat 侧重于实践,不会有抽象的概念和理论知识。

1053
来自专栏大数据和云计算技术

阿里HBase的数据管道设施实践与演进

摘要:第九届中国数据库技术大会,阿里巴巴技术专家孟庆义对阿里HBase的数据管道设施实践与演进进行了讲解。主要从数据导入场景、 HBase Bulkload功能...

962
来自专栏Golang语言社区

Golang语言社区--游戏服务器端开发的一些建议(转载)

大家好,我是Golang语言社区(www.golang.ltd)主编彬哥,本篇给大家转载一篇关于游戏服务器开发的文章。

4557
来自专栏张戈的专栏

替换WordPress默认搜索为百度站内搜索(知更鸟主题可照搬)

今天,中国博客联盟 QQ 群里的【58 说】博友提到百度站长平台推出绿色收录通道了。连忙登陆站长平台看了下,意外的发现张戈博客已开通了站内搜索功能。之前确实给管...

3684
来自专栏开源项目

走过微软20年,埋头并发编程15年,如何减少代码的认知负荷?| 码云周刊

每周为您推送最有价值的开源技术内参! 技术干货 从Visual Studio看微软20年技术变迁 spring cloud netflix 微服务使用实例 20...

42313
来自专栏xingoo, 一个梦想做发明家的程序员

大数据学习之路(持续更新中...)

在16年8月份至今,一直在努力学习大数据大数据相关的技术,很想了解众多老司机的学习历程。因为大数据涉及的技术很广需要了解的东西也很多,会让很多新手望而却步。所...

1898
来自专栏性能与架构

认识日志分析平台ELK

为什么要使用日志分析平台 对于日志的重要性,都会很认同,不管是一个小网站,还是一个大系统,都会用到日志 网站初期,一般就是查看web服务器访问日志,例如,平时...

3628
来自专栏Golang语言社区

高并发解决方案——提升高并发量服务器性能解决思路

一个小型的网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构、性能的要求都很简单。随着...

35610
来自专栏Golang语言社区

Hulu大规模容器调度系统Capos

Hulu是美国领先的互联网专业视频服务平台,目前在美国拥有超过2000万付费用户。Hulu总部位于美国洛杉矶,北京办公室是仅次于总部的第二大研发中心,也是从Hu...

923

扫码关注云+社区