MQTT入门篇

物联网（Internet of Things，IoT）最近曝光率愈来愈高。虽然HTTP是网页的事实标准，不过机器之间（Machine-to-Machine，M2M）的大规模沟通须要不一样的模式：以前的请求/回答（Request/Response）模式再也不合适，取而代之的是发布/订阅（Publish/Subscribe）模式。这就是轻量级、可扩展的MQTT（Message Queuing Telemetry Transport）能够施展拳脚的舞台。

MQTT简介

MQTT是基于二进制消息的发布/订阅编程模式的消息协议，最先由IBM提出的，现在已经成为OASIS规范。因为规范很简单，很是适合须要低功耗和网络带宽有限的IoT场景，好比：

• 遥感数据
• 汽车
• 智能家居
• 智慧城市
• 医疗医护

因为物联网的环境是很是特别的，因此MQTT遵循如下设计原则：

1. 精简，不添加无关紧要的功能。
2. 发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递。
3. 容许用户动态建立主题，零运维成本。
4. 把传输量降到最低以提升传输效率。
5. 把低带宽、高延迟、不稳定的网络等因素考虑在内。
6. 支持连续的会话控制。
7. 理解客户端计算能力可能很低。
8. 提供服务质量管理。
9. 假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

运用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代理