java实现mqtt服务端_MQTT服务接入超时案例：MQTT服务和Netty在异常场景下的保护机制...

仅以此文献给李林锋新生的爱女。

Netty 4.1提供了MQTT协议栈，基于此可以非常方便地创建MQTT服务，尽管开发简单，但是在实际环境中会面临各种挑战，甚至会面临一些不遵循MQTT规范的端侧设备接入。

如果服务端没有考虑到各种异常场景，很难稳定运行，本文以生产环境MQTT服务无法提供接入服务为例，详细介绍MQTT服务和Netty在异常场景下的保护机制。

• MQTT服务接入超时问题

1. 生产环境问题现象

生产环境的MQTT服务运行一段时间之后，发现新的端侧设备无法接入，连接超时。分析MQTT服务端日志，没有明显的异常，但是内存占用较高，查看连接数，发现有数十万个TCP连接处于ESTABLISHED状态，实际的MQTT连接数应该在1万个左右，显然这么多连接肯定存在问题。

由于MQTT服务端的内存是按照2万个左右连接数规模配置的，因此当连接数达到数十万个的规模之后，导致了服务端大量SocketChannel积压、内存暴涨、高频率GC和较长的STW时间，对端侧设备的接入造成了很大影响，部分设备MQTT握手超时，无法接入。

2. 连接数膨胀原因分析

通过抓包分析发现，一些端侧设备并没有按照MQTT协议规范进行处理，包括：

(1)客户端发起CONNECT连接，SSL握手成功之后没有按照协议规范继续处理，例如发送PING命令。

(2)客户端发起TCP连接，不做SSL握手，也不做后续处理，导致TCP连接被挂起。

由于服务端是严格按照MQTT规范实现的，上述端侧设备不按规范接入，实际上消息调度不到MQTT应用协议层。MQTT服务端依赖Keep Alive机制进行超时检测，当一段时间接收不到客户端的心跳和业务消息时，就会触发心跳超时，关闭连接。针对上述两种接入场景，由于MQTT的连接流程