关于物联网:MQTT-客户端出现连接订阅等问题时如何排查

4次阅读

共计 1951 个字符，预计需要花费 5 分钟才能阅读完成。

大家好，这是一期社区专题 FAQ。咱们整顿了近期社区中关注度较高的问题，在这里进行对立汇总解答。

今后本系列内容将不定期推送，敬请关注。

同时，如果大家在应用 EMQX 的过程中遇到问题，欢送通过以下形式进行解决：

查阅 EMQX 产品文档与博客文章。
如果在现有材料中未能查问到问题的解决办法，能够在问答社区中留言发问，咱们会尽快解答您的问题。

MQTT Broker 肯定会保障来自同一客户端的雷同主题的音讯依照达到程序被转发，这与音讯的 QoS 等级无关，QoS 等级不会影响转发程序，不论是音讯失落，还是音讯反复，也都不会导致音讯失序。

对于不同主题的音讯，MQTT Broker 不会提供转发程序保障，咱们能够将他们视为进入了不同的通道，比方主题 A 的音讯先于主题 B 的音讯达到 MQTT Broker，但最终可能主题 B 的音讯会更早下发。

A：其实 EMQX 的 Debug 日志根本曾经记录了所有的行为和景象，通过浏览 Debug 日志咱们可能晓得客户端何时发动了连贯，连贯时指定了哪些字段，连贯是否通过，被回绝连贯的起因是什么等等。然而因为 Debug 日志记录的信息过多，会带来额定的资源耗费，并且不利于咱们针对单个客户端或主题进行剖析。

所以 EMQX 提供了日志追踪性能，咱们能够指定想要追踪的客户端或主题，EMQX 会将所有与该客户端或主题相干的 Debug 日志都输入到指定日志文件中。这样不论是本人剖析调试，还是寻求社区帮忙，都会不便许多。

A：CENSYS 是一款互联网探测扫描工具，它会周期性扫描 IPv4 地址空间，探测 HTTP、SSH、MQTT 等协定的默认端口。所以如果你发现有 Client ID 为 CENSYS 的或者其余未知的客户端接入了你的 MQTT Broker，这象征你目前处于绝对较低的安全性保障下。以下措施能够无效帮忙你防止这个问题：

不要应用默认配置，例如 EMQX 用于验证 HTTP API 拜访权限的 AppID 与 AppSecret 等
启用认证，能够是用户名明码认证，也能够是 JWT 认证，防止只须要晓得 IP 地址就能够登录的难堪状况
启用 TLS 双向认证，只有持有无效证书的客户端能力接入零碎
启用受权，防止非法设施登录后能够获取敏感数据
配置你的防火墙，尽量敞开一些不须要的端口

A：不是。EMQX 中的每个客户端过程都会有一个音讯队列，这个音讯队列会存储所有因航行窗口满或连贯断开而临时无奈下发给客户端的音讯。音讯队列有最大长度限度，以防止音讯无限度沉积，达到最大长度后，为了使新音讯持续入队，EMQX 会陆续抛弃队列中最老的音讯。音讯队列最大长度由 max_mqueue_len 这个配置项指定。

A：这个日志示意报文解析失败，可能因为这不是一个 MQTT 报文，咱们遇到过很多向 MQTT 端口发送 HTTP 申请的状况，也可能因为报文中蕴含了非 UTF-8 字符等等。咱们能够在这条 “Parse failed…” 日志中检索 Frame data 关键字以查看残缺的报文，帮忙咱们剖析解析失败的可能起因。

A：呈现这个日志通常示意相应的客户端过程曾经达到了最大堆栈内存占用限度，之后这个过程就会被 EMQX 强制 Kill。这一机制存在的起因是为了保障 EMQX 的可用性，防止客户端过程的内存占用无限度增长最终导致 EMQX OOM。客户端过程的堆栈占用次要来源于航行窗口和音讯队列中未实现确认或未投递的音讯，而这两处音讯沉积的次要起因通常是客户端生产能力有余，无奈及时处理响应音讯。

与此相关的配置项是 force_shutdown_policy，它的配置格局为 <Maximum Message Queue Length>|<Maximum Heap Size>，例如 10000|64MB。其中 <Maximum Heap Size> 就是限度每个客户端过程可能占用的最大堆栈内存。

咱们见过一些用户为了不想客户端过程被强制敞开，不去晋升客户端的生产能力，而是一味增大 <Maximum Heap Size>，这除了给 EMQX 带来 OOM 危险，也会使得音讯的时延减少，往往得失相当。