关于mqtt:负载均衡-MQTT-Broker-集群详解一

MQTT 协定在物联网，小型设施场景，挪动利用等方面曾经有了宽泛的利用，并逐步成为了物联网通信的规范。本文重点介绍了组建 MQTT Broker 集群的挑战及负载平衡在 MQTT 集群中所起的作用。

与大家相熟的 HTTP 协定相似，MQTT 协定同样基于 TCP/TLS 之上，属于应用层协定（它也能够基于 HTTP 协定之上工作，本文暂不波及这部分内容）。

MQTT 规范委员会对 MQTT 协定的释义如下：

MQTT 是用于物联网 (IoT) 的 OASIS 规范消息传递协定。它是一种十分轻量级的音讯传输协定，采纳了公布 / 订阅的机制，非常适合连贯近程设施，无论是代码占用空间还是网络带宽的占用都很小。现在，MQTT 已被宽泛用于汽车、工业制作、电信、石油和天然气等各个行业。

MQTT 客户端和 HTTP 客户端也很类似。它与服务器端建设一个 TCP 连贯，通过该连贯传输数据。不同的是，HTTP 采纳的是申请 / 响应模型，而 MQTT 采纳的是公布 / 订阅模型。

举个例子：客厅里装置的温度传感器，会间断性的把室内温度数值上传到 MQTT 服务器上。而另一个智能家居设施订阅了这个温度传感器公布音讯的频道，就能够取得室内的温度数据，并依据理论室温采取一些智能应答措施，比方当室内温度超过 32°C 时就关上空调。

MQTT 协定听起来仿佛离咱们很边远，其实它早已渗透到了咱们的日常生活中。个别状况下，单个 MQTT 节点就能够满足单个家庭的智能家居设施连贯需要，用户甚至能够在树莓派上运行一个 EMQ X Edge（运行在边缘端的 MQTT 服务器）。而运行在云端的一个 EMQ X 节点能够撑持高达 200 万的连接数，轻松满足一般智能家居场景需要。

但如果是全国的千百万辆汽车要联网，或者是上百万盏路灯要传递数据之类的场景，那么微小的设施数（MQTT 客户端）和数据吞吐量，就远远超出了单个 MQTT 节点所能接受的压力，须要组建 MQTT 服务器集群。

在组建集群的同时，也面临着一系列的技术挑战：

提供服务地址：如何让客户端晓得该连贯哪个地址？
不同节点如何接管 MQTT 订阅者的会话，比方当一个客户端从一台服务器断连后，要如何在另一台服务器复原连贯？
集群中各个节点上的路由表如何放弃一致性？

通过在 MQTT 集群后面引入一个负载平衡，能够帮忙咱们轻松解决问题 1 和 2。

MQTT 负载平衡

为了应答上述问题，负载平衡须要可能依据配置的平衡策略来帮忙客户端决定连贯到哪个节点。MQTT 集群负载平衡的次要性能有：

对外提供集群服务地址

客户端只须要关怀负载平衡的地址，而且不须要晓得集群内各个节点的地址。这大大晋升了服务器迁徙和伸缩的灵活性。
TLS 终结

许多 MQTT 的用户抉择在负载平衡这一层来终结 TLS，这样能够使 MQTT 服务器的资源被充沛用于音讯的解决。
均衡集群中各个节点的负载

负载平衡服务通常能够配置不同的平衡策略，如：随机调配、轮询（有些轮询策略能够调节节点权重），还有比拟有意思的粘性调配。

因为 MQTT 是基于 TCP/IP 之上的协定，因而能够在传输层进行负载平衡。而在传输层负载平衡之外，MQTT 能应用的负载平衡产品 HAProxy 2.4 和 Nginx Plus 还提供了应用层（MQTT 层）的负载平衡解决方案。

Nginx Plus 是在 Nginx（一个开源的 Web 服务器，实用于高流量网站的反向代理）根底上构建的应用程序交付平台。Nginx Plus 的这篇文章作了较为具体的形容。

同样优良的，还有 HAProxy。它提供高可用性负载平衡，以及基于 TCP、HTTP 和 MQTT 的应用程序代理。到目前为止（2021 年 8 月），HAProxy 2.4 是惟一一款能够提供 MQTT 层负载平衡的收费产品。在他们的 release note 中，对 MQTT 负载平衡的性能作了简略的介绍。

在“MQTT Broker 集群详解”系列的下一篇文章中，咱们将对 HAProxy 2.4 + EMQ X 4.3 的集成计划进行具体开展，敬请期待。

版权申明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/mqtt-broker-clustering-part-1-load-balancing

技术支持：如对本文或 EMQ 相干产品有疑难，可拜访 EMQ 问答社区 https://askemq.com 发问，咱们将会及时回复反对。

MQTT 协定

可拓展性挑战

MQTT 负载平衡