什么是 MQTT 协议
MQTT 协议的全称是 Message Queuing Telemetry Transport，翻译为消息队列传输探测，它是 ISO 标准下的一种基于发布 - 订阅模式的消息协议，它是基于 TCP/IP 协议簇的，它是为了改善网络设备硬件的性能和网络的性能来设计的。MQTT 一般多用于 IoT 即物联网上，广泛应用于工业级别的应用场景，比如汽车、制造、石油、天然气等。
在了解了 MQTT 的概念和应用场景后，我们下来就来走进 MQTT 的学习中了，先来看一下 MQTT 有哪些概念。
MQTT 基础
上面我们解释了 MQTT 协议的基本概念，MQTT 协议总结一点就是一种轻量级的二进制协议，MQTT 协议与 HTTP 相比具有一个明显的优势：数据包开销较小，数据包开销小就意味着更容易进行网络传输。还有一个优势就是 MQTT 在客户端容易实现，而且具有易用性，非常适合当今资源有限的设备。
你可能对这些概念有些讳莫如深，为什么具有 xxx 这种特性呢？这就需要从 MQTT 的设计说起了。
MQTT 协议由 Andy Stanford-Clark (IBM) 和 Arlen Nipper（Arcom，现为 Cirrus Link）于 1999 年发明。他们需要一种通过卫星连接石油管道的协议，以最大限度地减少电池损耗和带宽。所以他们为这个协议规定了几种要求：
- 这个协议必须易于实现；
- 这个协议中的数据必须易于传输，消耗成本小；
- 这个协议必须提供服务质量管理；
- 这个协议必须支持连续的会话控制
- 假设数据不可知，不强求传输数据的类型与格式，保持灵活性。
这些设计也是 MQTT 的精髓所在，MQTT 经过不断的发展，已经成为了物联网 IoT 所必备的一种消息探测协议，官方强烈推荐使用的版本是 MQTT 5。
发布 - 订阅模式
发布 - 订阅模式我相信接触消息中间件架构的同学都听过，这是一种传统的客户端 - 服务器架构的替代方案，因为一般传统的客户端-服务器是客户端能够直接和服务器进行通信。
但是发布 - 订阅模式 pub/sub就不一样了，发布订阅模式会将发送消息的发布者 publisher与接收消息的订阅者 subscribers进行分离，publisher 与 subscribers 并不会直接通信，他们甚至都不清楚对方是否存在，他们之间的交流由第三方组件 broker 代理。
pub/sub 最重要的方面是 publisher 与 subscriber 的解藕，这种耦合度有下面三个维度：
- 空间解耦：publisher 与 subscriber 并不知道对方的存在，例如不会有 IP 地址和端口的交互，也更不会有消息的交互。
- 时间解藕：publisher 与 subscriber 并不一定需要同时运行。
- 同步
Synchronization解藕：两个组件的操作比如 publish 和 subscribe 都不会在发布或者接收过程中产生中断。
总之，发布/订阅模式消除了传统客户-服务器之间的直接通信，把通信这个操作交给了 broker 进行代理，并在空间、时间、同步三个维度上进行了解藕。
可拓展性
pub/sub 比传统的客户端-服务器模式有了更好的拓展，这是由于 broker 的高度并行化，并且是基于事件驱动的模式。可拓展性还体现在消息的缓存和消息的智能路由，还可以通过集群代理来实现数百万的连接，使用负载均衡器将负载分配到更多的单个服务器上，这就是 MQTT 的深度应用了。
你可能不明白什么是事件驱动，我在这里解释下事件驱动的概念。
事件驱动是一种编程范式，编程范式是软件工程中的概念，它指的是一种编程方法或者说程序设计方式，比如说面向对象编程和面向过程编程就是一种编程范式，事件驱动中的程序流程会由诸如用户操作（点击鼠标、键盘）、传感器输出或者从其他程序或传递的消息事件决定。事件驱动编程是图形用户界面和其他应用程序比如 Web 中使用的主要范式，这些应用程序能够响应用户输入执行某些操作为中心，这同时也适用于驱动程序的编程。
消息过滤
在 pub/sub 的架构模式中，broker 扮演着至关重要的作用，其中非常重要的一点就是 broker 能够对消息进行过滤，使每个订阅者只接收自己感兴趣的消息。
broker 有几个可以过滤的选项
- 基于主题的过滤
MQTT 是基于 subject 的消息过滤的，每条消息都会有一个 topic ，接收客户端会向 borker 订阅感兴趣的 topic，订阅后，broker 就会确保客户端收到发布到 topic 中的消息。
- 基于内容的过滤
在基于内容的过滤中，broker 会根据特定的内容过滤消息，接受客户端会经过过滤他们感兴趣的内容。这种方法的一个显著的缺点就是必须事先知道消息的内容，不能加密或者轻易修改。
- 基于类型的过滤
在使用面向对象的语言时，基于消息（事件）的类型过滤是一种比较常见的过滤方式。
为了发布/订阅系统的挑战，MQTT 具有三个服务质量级别，你可以指定消息从客户端传到 broker 或者从 broker 传到客户端，在 topic 的订阅中，会存在 topic 没有 subscriber 订阅的情况，作为 broker 必须知道如何处理这种情况。
MQTT 与消息队列的区别
我们现在知道，MQTT 是一种消息队列传输探测协议，这种协议是看似是以消息队列为基础，但却与消息队列有所差别。
在传统的消息队列模式中，一条消息会存储在消息队列中等待被消费，每个传入的消息都存储在消息队列中，直到它被客户端（通常称之为消费者）所接收，如果没有客户端消费消息的话，这条消息就会存在消息队列中等待被消费。但是在消息队列中，不会存在消息没有客户端消费的情况，但是在 MQTT 中，确存在 topic 无 subscriber 订阅的情况。
在传统的消息队列模式中，一条消息只能被一个客户端所消费，负载会分布在队列的每个消费者之间；而在 MQTT 中，每个订阅者都会受到消息，每个订阅者有相同的负载。
在传统的消息队列模式中，必须使用单独的命令来显式创建队列，只有队列创建后，才可以生产或者消费消息；而在 MQTT 中，topic 比较灵活，可以即时创建。
HiveMQ 现在是开源的，HiveMQ 社区版实现了 MQTT broker 规范，并兼容了 MQTT 3.1、3.1.1 和 MQTT 5。HiveMQ MQTT Client 是一个基于 Java 的 MQTT 客户端实现，兼容 MQTT 3.1.1 和 MQTT 5。这两个项目都可以在 HiveMQ 的 github https://github.com/hivemq 上找到。
我们知道，broker 将 publisher 和 subscriber 进行分离，因此客户端的连接由 broker 代理，所以在我们深入理解 MQTT 之前，我们需要先知道客户端和代理的含义。
MQTT 重要概念
MQTT client
当我们讨论关于客户端的概念时，一般指的就是 MQTT Client，publisher 和 subscriber 都属于 MQTT Client。之所以有发布者和订阅者这个概念，其实是一种相对的概念，就是指当前客户端是在发布消息还是在接收消息，发布和订阅的功能也可以由同一个 MQTT Client 实现。
MQTT 客户端是指运行 MQTT 库并通过网络连接到 MQTT broker 的任何设备，这些设备可以从微控制器到成熟的服务器。基本上，任何使用 TCP/IP 协议使用 MQTT 设备的都可以称之为 MQTT Client。MQTT 协议的客户端实现非常简单直接。易于实施是 MQTT 非常适合小型设备的原因之一。MQTT 客户端库可用于多种编程语言。例如，Android、Arduino、C、C++、C#、Go、iOS、Java、JavaScript 和 .NET。
