近一年半在做物联网相关的项目，MQTT 是物联网技术中非常常见且协议。EMQ 是对 MQTT 协议实现的很不错的 Broker。当前的稳定版本是 V3.2.7；
下面我罗列一下使用中的一些实践和想法；
如何正确获得设备端连接断开事件
有三种做法：
- 订阅EMQ 的系统主题 $SYS/brokers/${node}/clients/{clientId}/disconnected；
- 使用 web hook 插件；
- 客户端使用遗愿；
第 1 种做法
可使用通配符方式只订阅一个主题，缺点就是所有客户端的离线都收到消息，需要在消费的时候再做判断，是否要关心，再触发具体的关心的设备类型的离线。
但是如果不使用通配符方式订阅的话，就得设备挨个订阅主题，这样就增加了很多订阅主题，给消息路由带来压力，是极不划算的做法；
第 2 种做法
缺点和第 1 种做法一样，收到的是所有设备的离线回调，需要在 controller 收到离线请求的时候再判断，是否要关心。
第 3 种做法
按设备不同的分类指定不同的遗愿主题，这样服务器端按不同的分类主题进行订阅，比较好的区分设备类型，还不会收到不关心的设备的离线消息，推荐这种做法！
如何正确的统计在线数量
有两种做法：
- 订阅系统主题 $SYS/brokers/${node}/stats/connection/count；
- 通过 HTTP API 定时调用 /api/v3/connections 获取；
第 1 种做法
是每当有设备上线或者离线都会发这个系统消息呢还是定时发呢？不太知道实现机制是什么，没有仔细研究还；但是在 V3.2.7 测试不起作用，不知道什么原因；
第 2 种做法
通过一个监控定时任务去调用然后写入打点数据库，通过监控平台展示，可行，而且方法很舒服，推荐！！
如何安全控制
建议做到如下两点：
- 至少做到一型一密（用户名和密码）
- ACL 联动控制
如何正确的使用订阅
虽然订阅主题的时候允许使用通配符，但仍建议订阅主题时主题过滤器尽量减少通配符使用，尽量做到精准匹配；
因为：
- 通配符可能遇到『意想不到』的问题，比如程序升级对主题做了新的扩充，使用 # 通配符方式订阅地方收到了一些非预想的消息；
- 使用通配符的的，消费的时候有可能还需要截取 topic 上内容做判断来路由至不同的逻辑，降低了程序的『可读性』和『可维护性』；
- 有可能收到不需要收到的消息，需要额外判断，带来不必要的消费时的资源浪费；