分类： 架构设计与优化
2017-01-06 16:54:41
MQTT 是一种基于发布订阅模型的即时通讯协议，由于轻巧，开源，易用，耗能少，支持 QOS/遗言（WILL）等特性，正被广泛应用于物联网和移动互联网。
消息队列 MQ 提供了对 MQTT 协议的支持，完全兼容 MQTT 标准协议，但是在使用 MQ MQTT 时，对比标准协议，需要注意两点：
1. 父级 Topic 需要提前创建
根据标准 MQTT 协议，Topic 存在多级，且拥有动态的特性（不需要用户提前定义和创建），但是使用过消息队列 MQ 的用户都知道，MQ Topic是需要通过 MQ 控制台提前创建的，这是因为 MQ MQTT是队列（消息持久化），且 MQ 不仅支持 MQTT 协议，还支持 TCP, HTTP 协议的接入，为了能将不同方式接入的消息互通，比如：用 MQTT 方式发送的消息，用 TCP 方式可以收到；用 HTTP 方式发送的消息，用 MQTT 方式也能收到，故 MQ MQTT 做了以下变通：
定义第一级 Topic 为父 Topic，使用前，需要在 MQ 控制台创建父 Topic，子级 Topic 无需创建，直接在代码中使用。
2. MQ MQTT 支持 p2p，且不需要显示订阅
这一点弥补了标准 MQTT 协议不支持 p2p 的遗憾。而且通过 TCP/HTTP 接入的客户端都可以收发 p2p 消息。
MQTT Topic的动态特性给设计者们带来了很多发挥空间，但是有些地方需要注意：
1）名称不能带/和空格
2）短小精干，简洁明了
3）使用 UTF-8，避免不可见字符
4）在一些特殊场景里，考虑将唯一设备号嵌入到 Topic 名称，便于辨识消息发送者
比如，只有 client1 可以发布消息到client1/status, 且不能发布到client2/status，那么当你收到client1/status时，可以肯定就是client1发送的消息。
5）谨慎使用通配符#
比如，订阅 news/sport/#, 那么你就会收到下面所有这些 Topic 的消息
news/sport
news/sport/player1
news/sport/player2
news/sport/player1/score
不可预计的消息数量，会对接收端（移动端，嵌入式设备）造成负担。
6）业务可延伸
订阅关系需要事先建立，所以发送端和接收端都需要提前意识到 Topic 的存在，这就要求我们合理设计 Topic 的结构，在增加新业务需求时，适当增加子级 Topic 即可，而不用修改，甚至推翻 Topic 原先的结构。
比如，订阅李娜的新闻，可以设计成订阅 news/lina, 但是文体娱乐圈里有很多和李娜重名的，后续业务需要，用户想订阅网球李娜的新闻时，整个 Topic 结构将被迫改变，所以，在业务设计之初，尽可能在延伸性上多考虑一些。
这样设计较之前就更稳妥些：
news/sport/tennis/lina
news/sport/tennis/lina/ranking
news/sport/tennis/lina/score/australianopen
下面结合 MQ MQTT 特点，提供一个社交 IM 场景下的实现雏形，欢迎大家讨论。
准备工作：在 MQ 控制台创建父级 Topic 和 GroupID
每个设备接入 MQ MQTT 服务时，都要提供 Client ID，这是每个客户端的唯一标识，要求全局唯一。
Client ID 由两部分组成，组织形式为 GroupID@@@DeviceID。
GroupID: 需要在 MQ 控制台申请创建，用于指定一组逻辑功能完全一致的节点共用组名，代表一类相同功能的设备。
DeviceID: 每个设备独一无二的标识，由业务方自己指定，无需在 MQ 控制台创建。
