MQTT定义：
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和制动器的通信协议。
MQTT简介：
MQTT是基于客户端/服务器的二进制的发布、订阅编程模式的消息协议，由于规范简单，非常适用于带宽低，低功耗的iot场景，比如：遥感、M2M、智慧城市、智能家居、医疗医护等。由于物联网的环境非常的特别，所以MQTT有他的设计规范：
- 精简，不添加可有可无的功能
- 发布、订阅模式，方便消息在传感器之间传递
- 允许用户动态创建主题，零运维成本
- 把传输量降到最低提高传输效率
- 考虑地带宽、高延迟、不稳定的网络因素
- 充分理解客户端羸弱的计算能力
- 支持连续会话
- 提供服务质量管理。（Qos：至少一次、至多一次、只有一次）
- 假设数据不可知，不强求数据的类型和格式，保持灵活性
mqtt发布订阅模式：
和传统的http的请求/应答模式不一样（request/response），发布订阅模式解耦了发布者和订阅者之间的关系，这意味着发布者和订阅者不需要直接联系，由代理进行转发，什么意思呢？打个比方你打电话给你的女朋友翟小树，需要等翟小树接听电话之后你们才可以交流，这个就是http的请求响应模式，试想你是一个大明星，胡大橙和翟小树都关注了你的微博，当你发布一条微博的时候，微博服务器就是转发给他们两个的好友动态，此时你就是发布者（publisher），他们就是订阅者（subscribe），就这事典型的异步发布订阅模式。发布订阅模式带来了一些好处：
- 发布者和订阅者不必彼此了解，多个订阅者之间也不需要彼此了解，只需要认识同一个消息代理
- 发布者和订阅者不需要同时在线
- 发布者和订阅者不需要进行任何的交互
为了满足不同的场景，mqtt支持三种不同的服务质量（Qos）
- 最多一次 （基于tcp/ip,发布者会想尽办法发布，但是遇到意外不会重试，使用场景比如传感器上报数据某次丢失但是过几秒就会另一次上报，对数据的要求不是那么的精确就可以设置这种）
- 至少一次 (如果订阅者没有收到，发布者会重复的发送，确保消息达到，但是这种会存在一种问题就是重复的接收消息)
- 只有一次（缺点是减少了并发或者增加了延时，但是如果消息重复或者丢失都不可接收的时候，这种最合适）。
MQTT协议原理：
实现mqtt协议需要客户端和服务端，这个流程有三个角色，发布者（publish）、订阅者（subscribe）、代理，其中发布者可以是某个topic的发布者，也可以是另一个topic的订阅者。
mqtt的消息分为两个部分：主题（topic）、负载（payload）。
- topic：消息的类型，订阅者订阅了该消息之后就会收到代理转发的消息。
- payload：消息的内容。
MQTT客户端：
- 发布订阅者可能订阅的消息
- 订阅其他客户端可能发布的消息
- 退订或删除应用程序的消息
- 断开与服务器的连接
MQTT服务端：
- 接收来自客户端的连接
- 接收客户端发布的消息
- 转发订阅对应topic的消息给订阅者
- 处理来自客户端的订阅和退订请求
MQTT协议中的一些方法：
- connect：与服务端进行连接
- disconnect 等客户端完成所有工作后断开与服务器的tcp/ip连接
- publish 客户端发布消息
- subscribe 客户端订阅主题（异步过程）
- unsubscribe 等待服务器取消客户端的一个或多个订阅的topic(异步过程)
MQTT在IoT中的实践
这是一张典型的MQTT在IoT中的应用，其中app作为客户端，智能网关也作为客户端（实际上在我们公司的V6云平台也是作为客户端），物联网云服务作为统一的服务端负责收发，app和V6云订阅同一个主题，app和网关订阅另一个主题，当每次需要发送mqtt命令时首先判断是账号登录（V6云）还是网关登录，于此publish对应的topic和payload，物联网云服务收到mqtt消息后转发给订阅同一个topic主题的客户端(V6云或者网关)，然后通过再由网关发送对应的指令去控制低功耗设备（比如门锁的开关，灯泡的开关）。这个时候可以看出topic的重要性，合理的定义topic可以实现不同业务功能。先说一下我们公司的topic的定义，由于初期没有考虑周到，只是针对V6云和网关定义了两个不同的topic,导致后面有一项业务功能是给分享的账号发一些mqtt消息时导致V6云需要做大量的过滤，完全没有体现出topic的优势，接下来先讲一下topic主题设计。
Topic主题设计
主题层级分隔符：“/” 主题层级分隔符是的主题十分结构化
-
china/jiangsu/nanjing - shanghuang/xiadayu
- shanghuang/huxiangli/81hao
多层通配符："#’ 是用于匹配主题中任意层级的通配符。多层通配符表示它的父级和任意数量的子层级。多层通配符必须位于它自己的层级或者跟在主题层级分隔符后面。不管哪种情况，它都必须是主题过滤器的最后一个字符 .比如你订阅了一个jiangsu/nanjing/*,你会收到如下的主题的消息
- jiangsu/nanjing
- jiangsu/nanjing/jiangning
- jiangsu/nanjing/qixia/nanjingdaxue
定阅主题示例
- jiangsu/# //也单独匹配“江苏”，因为#包括他的父级。
- # //有效，会收到所有的topic的消息
- jiangsu/nanjing/* //有效
- jiangsu/nanjing* //无效
- jiangsu/#/nanjing //无效，必须是主题过滤器的最后一个字符
单层通配符 “+” 只能用于单个层级匹配的通配符，在主题过滤器的任意层级都可以使用单层通配符，包括第一个和最后一个层级。然而它必须占据过滤器的整个层级 。可以在主题过滤器中的多个层级中使用它，也可以和多层通配符起使用。举个栗子:
- china/+ 只能匹配china/jiangsu
- china/+/+/zhaixiaoshu 可以匹配 china/xianlin/nanda/zhaixiaoshu 或者china/shanghuang/xiadayu/zhaixiaoshu
总结一下
- 所有的主题名和主题过滤器必须至少包含一个字符
- 主题名或主题过滤器以前置或后置斜杠 “/” 区分
- 只包含斜杠 “/” 的主题名或主题过滤器是合法的
- 主题名和主题过滤器是 UTF-8 编码字符串， 它们不能超过 65535 字节
- 主题名和主题过滤器是区分大小写的
从上可以看出合理的topic订阅能够实现花样的功能，就比如当初设计分享的用户的时候完全可以用通配符去设计，可以大大的减小计算和筛选量。