这是一个很经典的一对多消息发布模式了，像Redis就具有发布订阅功能。举一个具体的例子，我们有一个漫画家、有很多想看漫画的肥宅，先约定一个共同的主题叫做"连载漫画专栏"，肥宅们非常想看下一期漫画，于是“订阅”了这个专栏，并一直"监听"着是否有新漫画到达。每当漫画家“发布”一期新漫画到这个专栏，所有的肥宅都能“消费”相同的下一期“漫画”，漫画家只需要往这个主题“连载漫画专栏”里面发布漫画，无需关心是哪些肥宅在看；肥宅们只需要订阅和监听“连载漫画专栏”，就能够第一时间得到最新漫画内容。

回到物联网，有非常多这种一对多消息发布的需求。例如一台温度传感器上传了温度数据，监控日志面板服务希望得到数据好去绘图、温度异常服务希望感知温度异常好做相应操作、手机推送服务希望能够及时地获取最新温度好呈现给手机端展示，这就是一对多的典型需求。

相比于一个一个地主动投递消息，发布订阅这种被动获取减少了生产者的负担，解除了耦合，提高了消息传输效率。

3、MQTT的工作层

MQTT工作于应用层，是基于TCP/IP之上的可靠连接，当然也有UDP版本叫做“MQTT-SN”，通常使用的都是TCP版。

4、MQTT轻量级的体现

MQTT的报文头部只有2字节，它一开始就假设了客户端是计算能力低需要节省资源的设备，用约定好的二进制位来传递控制消息，省电省流量。

5、MQTT的三种消息发布服务质量

【QoS0】最多一次，不管成功与否

这是最省电但最不可靠的方式，完全依赖底层TCP/IP网络，可能会发生消息丢失和重复。通常应用于物联网设备上报最新数据，例如温度传感器不断地上传最新温度，这次的数据丢了马上又会有下一次，所以丢失无所谓；由于只是修改状态，具有幂等性，无论重复传输多少次，结果都是一样的，所以重复也无所谓。

【QoS1】至少一次，保证消息到达，可能重复

在QoS0之上保证了消息一定会送到，重复无所谓（通常重复的概率很低），但必须要让消费者看见这条消息，这是最常用的服务质量，应用于手机推送消息等各项服务的数据生产消费。假设你的温度传感器监控到温度异常可能着火了，手机APP收到多条着火消息和一条着火消息都收不到，当然是收到多条着火消息更好了。

【QoS2】只有一次，保证消息只到达一次

这种当然是最好的情况，但这也是最费电、流程最复杂的情况，大部分物联网大厂都不支持QoS2，因为根本没有这种需求。通常QoS2用于支付，如果支付的数据丢失、或者多次重复支付，都是很难容忍的。或者用于手机聊天消息，手机APP只能接收到一条聊天消息推送，消息的丢失和重复都是不可以的，这种场景直接用HTTP服务器就好了啊，大家都是强大的手机又不是低功耗嵌入式设备。

6、MQTT的心跳和连接

MQTT维护了双工长连接，通过心跳机制来判断是否掉线。不要担心心跳机制给嵌入式设备带来的负担，通常这个心跳间隔都设置得很长，例如60秒。

7、MQTT的主题

MQTT的主题长这个样子：“/mydevice/abc”、"/mydevice/+/confs"、"mydevice/qwer/#"。

第一个是最普通的精确主题，用斜杠分隔主题层级。

第二个是通配符主题，“+”只能匹配一层的主题，例如“/mydevice/123/confs”是可以匹配的，"/mydevice/123/aaa/confs"是无法匹配的。

第三个是通配符主题，"#"可以匹配多层，但只能在末尾，例如"mydevice/qwer/aaa/123"是可以匹配的。

8、MQTT的保留消息

MQTT设置了一个保留消息（Retain Message），这是基于主题的，每个主题可以有一条保留消息，如果有新的订阅者订阅了该主题，就需要将这条保留消息推送给它，通常用于新订阅主题的设备初始化。

9、MQTT的遗嘱

MQTT设置了一个遗嘱消息（Will Message），这是基于客户端的，每个客户端在连接的时候可以保留一条遗嘱消息，当连接异常断开（例如网络中断、客户端崩溃、心跳信息没有发送）没有发送正常的DISCONNECT报文的时候，会将这条消息分发给订阅了这个遗嘱消息的客户端，其他客户端就知道它发生问题了，从而做相应的处理，通常用于设备的异常通知，例如当设备正常退出，手机APP需要显示设备正常退出，当设备异常退出，手机APP需要报警，那么手机APP只需要订阅设备的遗嘱消息，就能够知道它断开时是正常的还是异常的了。