江苏龙网

  1. 首页 > 资讯 > 科技 > >

大数据技术栈MQTT协议：如何支持海量的在线IoT设备？( 二 )


另外 ， MQTT 它是不支持点对点通信的 ， 一般的做法都是 ， 每个客户端都创建一个以自己 ID 为名字的主题 ， 然后客户端来订阅自己的专属主题 ， 用于接收专门发给这个客户端的消息 。 这就意味着 ， 在 MQTT 的集群中 ， 主题的数量是和客户端的数量基本是同一个量级的 。 如何选择 MQTT 产品？
如何能支持海量在线的 IoT 设备和海量的主题 ， 是每一个支持 MQTT 协议的消息队列面临的最大挑战 。 也是你在做 MQTT 服务端技术选型时 ， 需要重点考察的技术点 。
目前开源的 MQTT 产品中 ， 有些是传统的消息队列 ， 通过官方或者非官方的扩展 ， 实现了 MQTT 协议的支持 。 也有一些专门的 MQTT Server 产品 ， 这些 MQTT Server 在协议支持层面 ， 大多数是没有问题的 ， 性能和稳定性方面也都可以满足要求 。 但是 ， 我还没有发现能很好支撑海量客户端和主题的开源产品 。 为什么呢？
传统的消息队列 ， 虽然它可以通过扩展来支持 MQTT 协议 ， 但是它的整体架构在设计之初 ， 并没有考虑能支撑海量客户端和主题 。 比如 ， 之前我们讲过 ， RocketMQ 它的元数据是保存在 NameServer 的内存中 ， Kafka 是保存在 ZooKeeper 中 ， 这些存储都不擅长保存大量数据 ， 所以也支撑不了太多的客户端和主题 。
另外一些开源的 MQTT Server ， 很多根本就没有集群功能 ， 或者集群功能做的不太完善 。 集群功能做的好的产品 ， 它们的开发者大多都把集群功能放到企业版中拿去卖钱了 。
所以在做 MQTT Server 技术选型的时 ， 如果你接入 IoT 设备数量在十万以内 ， 是可以选择开源产品的 ， 选型的原则和选择普通消息队列是一样的 ， 我在《02 | 该如何选择消息队列？》这节课中讲过的选型原则都是适用的 ， 优先选择一个流行的、你熟悉的开源产品就可以了 。
如果说客户端的规模超过十万的量级 ， 需要支撑这么大规模的客户端数量 ， 服务端只有单个节点肯定是不够的 ， 必须用一个集群来支持 ， 并且这个集群是要能支持水平扩容的 ， 这些都是最基本的要求 。 这个时候就几乎没什么可供选择的开源产品了 。 这种情况建议选择一些云平台厂商提供的 MQTT 云服务 ， 价格相对比较低 ， 当然你可以选择价格更高的商业版 MQTT Server 。
另外一个选择就是 ， 基于已有的开源 MQTT Server ， 通过一些集成和开发 ， 来自行构建 MQTT 集群 。 接下来 ， 我跟你说一下 ， 构建一个支持海量客户端的 MQTT 集群 ， 应该如何来设计 。 MQTT 集群如何支持海量在线的 IoT 设备？
一般来说 ， 一个 MQTT 集群它的架构应该是这样的：

大数据技术栈MQTT协议：如何支持海量的在线IoT设备？
本文插图

这个图从左向右看 ， 首先接入的地址最好是一个域名 ， 这样域名的后面可以配置多个 IP 地址做负载均衡 ， 当然这个域名不是必需的 。 也可以直接连接负载均衡器 。 负载均衡可以选择像 F5 这种专用的负载均衡硬件 ， 也可以使用 Nginx 这样的软件 ， 只要是四层或者支持 MQTT 协议的七层负载均衡设备 ， 都可以选择 。
负载均衡器的后面 ， 需要部署一个 Proxy 集群 ， 这个 Proxy 集群承担了三个重要的作用：第一个作用是来承接海量 IoT 设备的连接 ， 第二个作用是来维护与客户端的会话 ， 第三个作用是作为代理 ， 在客户端和 Broker 之间进行消息转发 。
在 Proxy 集群的后面是 Broker 集群 ， 负责保存和收发消息 。
有的 MQTT Server 它的集群架构是这样的：

大数据技术栈MQTT协议：如何支持海量的在线IoT设备？
本文插图

它的架构中没有 Proxy 。 实际上 ， 它只是把 Proxy 和 Broker 的功能集成到了一个进程中 ， 这两种架构它本质上没有太大的区别 。 所以这两种架构我们可以认为是同一种架构 ， 一起来分析 。


推荐阅读


上一篇：「」航天知识丨航天器的概念与分类

下一篇：：不止 iPhone 12 三星看上京东方 90Hz OLED 屏：Galaxy S30 要用