RocketMQ MQTT 概览

传统的消息队列MQ主要应用于服务（端）之间的消息通信，比如电商领域的交易消息、支付消息、物流消息等等。然而在消息这个大类下，还有一个非常重要且常见的消息领域，即IoT类终端设备消息。近些年，我们看到随着智能家居、工业互联而兴起的面向IoT设备类的消息正在呈爆炸式增长，而且已经发展十余年的移动互联网的手机APP端消息仍然是数量级庞大。面向终端设备的消息数量级比传统服务端的消息要大很多量级并仍然在快速增长。

如果可以有一个统一的消息系统（产品）来提供多场景计算（如stream、event）、多场景（IoT、APP）接入，其实是非常有价值的，因为消息也是一种重要数据，数据如果只存在一个系统内，可以最大地降低存储成本，同时可以有效地避免数据因在不同系统间同步带来的一致性难题和挑战。

基于此，我们引入了RocketMQ-MQTT这个扩展项目来实现RocketMQ统一接入IoT设备和服务端的消息，提供一体化消息存储和互通能力。

MQTT协议

在IoT终端场景，目前业界广泛使用的是MQTT协议，是起源于物联网IoT场景，OASIS联盟定义的标准的开放式协议。因为IoT设备种类繁多，运行环境各异，一个标准的接入协议尤为关键。

MQTT协议定义的是一个Pub/Sub的通信模型，这个与RocketMQ是类似的，不过其在订阅方式上比较灵活，可以支持多级Topic订阅（如 “/t/t1/t2”），甚至可以支持通配符订阅（如 “/t/t1/+”）。

模型介绍

队列存储模型

我们设计了一种多维度分发的Topic队列模型，如上图所示，消息可以来自各个接入场景（如服务端的MQ/AMQP、客户端的MQTT），但只会写一份存到commitlog里面，然后分发出多个需求场景的队列索引（ConsumerQueue），如服务端场景（MQ/AMQP）可以按照一级Topic队列进行传统的服务端消费，客户端MQTT场景可以按照MQTT多级Topic以及通配符订阅进行消费消息。

这样的一个队列模型就可以同时支持服务端和终端场景的接入和消息收发，达到一体化的目标。

推拉模型

上图展示的是一个推拉模型，图中的P节点是一个协议网关或broker插件，终端设备通过MQTT协议连到这个网关节点。消息可以来自多种场景（MQ/AMQP/MQTT）发送过来，存到Topic队列后会有一个notify逻辑模块来实时感知这个新消息到达，然后会生成消息事件（就是消息的Topic名称），将该事件推送至网关节点，网关节点根据其连上的终端设备订阅情况进行内部匹配，找到哪些终端设备能匹配上，然后会触发pull请求去存储层读取消息再推送至终端设备。

架构概览

我们的目标是期望基于RocketMQ实现一体化且自闭环，但不希望Broker被侵入更多场景逻辑，我们抽象了一个协议计算层，这个计算层可以是一个网关，也可以是一个broker插件。Broker专注解决Queue的事情以及为了满足上面的计算需求做一些Queue存储的适配或改造。协议计算层负责协议接入，并且要可插拔部署。