MQTT协议

MQTT协议

前面介绍了AWS的IOT解决方案《AWS IOT解决方案分析》，IOT方案里面会用到一个重要的协议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做全文检索，这样的架构非常适合大型物联网项目，不但能够处理海量数据同时也具有很好的扩展性。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。