一、什么是mqtt
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（publish/subscribe）模式的“轻量级”通讯协议，该协议构建于 TCP/IP 协议上，由 IBM 于 1999 年发明。MQTT 协议的主要特征是开放、简单、轻量级和易于实现，这些特征使得它适用于受约束的应用环境，如：
网络受限：网络带宽较低且传输不可靠
终端受限：协议运行在嵌入式设备上，嵌入式终端的处理器、内存等是受限的
通过 MQTT 协议，目前已经扩展出了数十种 MQTT 服务器端程序，可以通过 PHP、Java、Python、C、C# 等语言向 MQTT 发送消息。由于开放源代码、耗电量小等特点，MQTT 非常适用于物联网领域，如传感器与服务器的通信、传感器信息采集等。
二、主要思想
发布/订阅模式
订阅发布模式定义了一种一对多的依赖关系，让多个订阅者对象同时监听某一个主题对象。这个主题对象在自身状态变化时，会通知所有订阅者对象，使它们能够自动更新自己的状态。
将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相应对象间的一致性，这样会给维护、扩展和重用都带来不便。当一个对象的改变需要同时改变其他对象，而且它不知道具体有多少对象需要改变时，就可以使用订阅发布模式了。
一个抽象模型有两个方面，其中一方面依赖于另一方面，这时订阅发布模式可以将这两者封装在独立的对象中，使它们各自独立地改变和复用。订阅发布模式所做的工作其实就是在解耦合。让耦合的双方都依赖于抽象，而不是依赖于具体，从而使得各自的变化都不会影响另一边的变化。
发布/订阅模式并不是 MQTT 协议特有的模式，像我们很多消息中间件都有使用发布/订阅模式，这里你是不是想说，这不就是我们所说的观察者模式嘛，还真不是，这两个模式很容易混淆。观察者模式只有观察者 + 被观察者两个角色，而发布/订阅模式还有一个经纪人 Broker；往更深层次的讲观察者和被观察者，是松耦合的关系，而发布者和订阅者，则完全不存在耦合。
在我们日常写程序时，经常遇到下面这种情况：
public void 前端业务/硬件业务（）
{
刷新界面（）;
更新数据库（）;
对界面更新数据（）;
……
}
当有前端和硬件业务产生时，需要依次要去执行：刷新界面（）、更新数据库（）、对界面更新数据（）等操作。表面上看代码写得很工整，其实这里面有很多的问题：
首先，这完全是面向过程开发，根本不适合大型项目。
第二，代码维护量太大。设想一下，如果产生业务后要执行10多个操作，那这将是个多么大，多少复杂的类呀，时间一长，可能连开发者自己都不知道如何去维护了。
第三，扩展性差。如果产生业务后，要增加一个声音提示（）功能，怎么办呢？没错，只能加在前端业务/硬件业务（）这个函数中，这样一来，就违反了“开放-关闭原则”。而且修改了原有的函数，那么在测试时，除了要测新增功能外，还要做原功能的回归测试；在一个大型项目中，做一次回归测试可能要花费大约两周左右的时间，而且前提是新增功能没有影响原来功能及产生新的bug。
那么如何把前端业务/硬件业务（）函数同其他函数进行解耦合呢？别着急，下面就介绍今天的主角----订阅发布模式。见下图：
上面的流程就是对有告警信息产生（）这个函数的描述。我们要做的，就是把产生告警和它需要通知的事件进行解耦，让它们之间没有相互依赖的关系，解耦合图如下：
事件触发者被抽象出来，称为消息发布者，即图中的P。事件接受都被抽象出来，称为消息订阅者，即图中的S。P与S之间通过Broker（即订阅器）连接。这样就实现了P与S的解耦。首先，P就把消息发送到指定的订阅器上，从始至终，它并不知道也不关心要把消息发向哪个S。S如果想接收消息，就要向订阅器进行订阅，订阅成功后，S就可以接收来自Broker的消息了，从始至终，S并不知道也不关心消息来源于哪个具体的P。同理，S还可以向Broker进行退订操作，成功退订后，S就无法接收到来自指定Broker的消息了。这样就完美的解决了P与S之间的解耦。
三、MQTT重要概念
3.1 MQTT Client
publisher 和 subscriber 都属于 MQTT Client，之所以有发布者和订阅者这个概念，其实是一种相对的概念，就是指当前客户端是在发布消息还是在接收消息，发布和订阅的功能也可以由同一个 MQTT Client 实现。
MQTT 客户端是运行 MQTT 库并通过网络连接到 MQTT 代理的任何设备（从微控制器到成熟的服务器）。例如，MQTT 客户端可以是一个非常小的、资源受限的设备，它通过无线网络进行连接并具有一个最低限度的库。基本上，任何使用 TCP/IP 协议使用 MQTT 设备的都可以称之为 MQTT Client。MQTT 协议的客户端实现非常简单直接，易于实施是 MQTT 非常适合小型设备的原因之一。MQTT 客户端库可用于多种编程语言。例如，Android、Arduino、C、C++、C#、Go、iOS、Java、JavaScript 和 .NET。
3.2 MQTT Broker
与 MQTT Client 对应的就是 MQTT Broker，Broker 是任何发布/订阅协议的核心，根据实现的不同，代理可以处理多达数百万连接的 MQTT Client。
Broker 负责接收所有消息，过滤消息，确定是哪个Client 订阅了每条消息，并将消息发送给对应的 Client，Broker 还负责保存会话数据，这些数据包括订阅的和错过的消息。Broker 还负责客户端的身份验证和授权。
3.3 MQTT Connection
MQTT 协议基于 TCP/IP。客户端和代理都需要有一个 TCP/IP 协议支持。
MQTT 连接始终位于一个客户端和代理之间。客户端从不直接相互连接。要发起连接，客户端向代理发送 CONNECT 消息。代理使用 CONNACK 消息和状态代码进行响应。建立连接后，代理将保持打开状态，直到客户端发送断开连接命令或连接中断。
3.4 MQTT主要参数
ClientId：ClientId 的长度可以是 1-23 个字符，在一个服务器上 ClientId 不能重复。如果超过 23 个字符，则服务器返回 CONNACK 消息中的返回码为 Identifier Rejected。在 MQTT 3.1.1 中，如果您不需要代理持有状态，您可以发送一个空的 ClientId。空的 ClientId 导致连接没有任何状态。在这种情况下，clean session 标志必须设置为 true，否则代理将拒绝连接。
Clean Session：Clean Session 标志告诉代理客户端是否要建立持久会话。在持久会话 （CleanSession = false） 中，代理存储客户端的所有订阅以及以服务质量（QoS）级别 1 或 2 订阅的客户端的所有丢失消息。 如果会话不是持久的 （CleanSession = true ），代理不为客户端存储任何内容，并清除任何先前持久会话中的所有信息。
Username/Password：MQTT 可以发送用户名和密码进行客户端认证和授权。但是，如果此信息未加密或散列，则密码将以纯文本形式发送。我们强烈建议将用户名和密码与安全传输一起使用。像 HiveMQ 这样的代理可以使用 SSL 证书对客户端进行身份验证，因此不需要用户名和密码。
Will Message：LastWillxxx 表示的是遗愿，client 在连接 broker 的时候将会设立一个遗愿，这个遗愿会保存在 broker 中，当 client 因为非正常原因断开与 broker 的连接时，broker 会将遗愿发送给订阅了这个 topic（订阅遗愿的 topic）的 client。
KeepAlive：keepAlive 是 client 在连接建立时与 broker 通信的时间间隔，通常以秒为单位。这个时间指的是 client 与 broker 在不发送消息下所能承受的最大时长。
QOS：此数字表示消息的服务质量 （QoS）。有三个级别：0、1 和 2。服务级别决定了消息到达预期接收者（客户端或代理）的保证类型。
Payload：这个是每条消息的实际内容。MQTT 是数据无关性的。可以发送任何文本、图像、加密数据以及二进制数据。
timeout：MQTT会尝试接收数据，直到timeout时间到后才会退出。
|
