本文简要介绍了 MQTT 消息服务器、组建集群的挑战及负载均衡在 MQTT 集群中所起的作用。
MQTT 协议
如果你还没听说过 MQTT 协议，那我猜你至少听说过 HTTP 协议吧。与 HTTP 类似，MQTT 协议同样基于 TCP/TLS 的之上，属于应用层协议（当然，它也可以基于 HTTP 协议之上工作，但我们今天先不讨论这部分内容）。
这是 MQTT 标准委员会对 MQTT 协议的定义，引用自 http://mqtt.org/。
MQTT 是用于物联网 (IoT) 的 OASIS 标准消息传递协议。它是一种非常轻量级的消息传输协议，采用了发布/订阅的机制，非常适合连接远程设备，无论是代码占用空间还是网络带宽的占用都很小。如今，MQTT 已被广泛用于各个行业，例如汽车、工业制造、电信、石油和天然气等。
MQTT 客户端和 HTTP 客户端也很类似。它与服务器端建立一个 TCP 连接，通过该连接传输数据。不同的是，HTTP 采用的是请求/响应模型，而 MQTT 采用的是发布/订阅模型。
举个现实生活中的例子：客厅里有个温度传感器，它间断性地把室内温度数值上传到 MQTT 服务器上。而另一个智能家居设备则可以通过订阅该传感器发布消息的频道获得温度数据，并根据此数据采取一些措施，比如当温度超过摄氏 32° 时就把空调打开。
可扩展性的挑战
前面举的温度传感器的例子比较贴近大家的生活，很容易理解。通常单个 MQTT 节点就可以满足单个家庭的智能家居设备连接需求，你甚至可以在树莓派上运行一个 EMQ X Edge （一个运行在边缘端的 MQTT 服务器）。而运行在云端的一个 EMQ X 节点可以支撑高达 200 万的连接数，应付这样的场景简直绰绰有余。
但是另一些场景就不一样了，比如：全世界千百万的汽车要联网，或者是全国上百万盏路灯要传递数据，等等。类似这样的场景，无论是设备数（MQTT 客户端）还是数据吞吐量都是巨大的，远远超出了单个 MQTT 节点所能承受的压力。
提供服务地址：如何让客户端知道该连接哪个地址？
不同节点如何接管 MQTT 订阅者的会话，比如当一个客户端从一台服务器断连了，如何在另一台服务器恢复连接？
集群中各个节点上的路由表如何保持一致性？
前两个问题我们可以通过在 MQTT 集群前面引入一个负载均衡来很好地解决。
MQTT 负载均衡
MQTT 负载均衡
为了应对上述问题，负载均衡需要能够根据配置的均衡策略来帮助客户端决定连接到哪个节点。MQTT 集群负载均衡的主要功能有：
对外提供集群服务地址。客户端只需要关心负载均衡的地址，而且不需要知道集群内各个节点的地址。这也为服务器的迁移和伸缩带来了灵活性。
TLS 终结。许多 MQTT 的用户选择在负载均衡这一层来终结 TLS，这样可以使 MQTT 服务器的资源被充分用于消息的处理。
平衡集群中各个节点的负载。负载均衡服务通常可以配置不同的均衡策略，如：随机分配、轮询（有些轮询策略可以调节节点权重），还有比较有意思的粘性分配。
由于 MQTT 是基于 TCP/IP 之上的协议，因此可以在传输层进行负载均衡。事实上，不像我们使用 HTTP 时有很多选择，截至笔者写下本文，MQTT 能使用的大多数负载平衡产品仍限于在传输层工作。例如，AWS NLB、Nginx 和 HAProxy。
在传输层负载均衡之外，HAProxy 2.4 和 Nginx Plus 还提供了应用层（MQTT 层）的负载均衡解决方案。
Nginx Plus 是在 Nginx（是一个开源的 Web 服务器，适用于高流量网站的反向代理）基础上构建的应用程序交付平台。Nginx Plus 的这篇文章（https://www.nginx.com/blog/nginx-plus-iot-load-balancing-mqtt/）作了较为详细的描述。
同样优秀的，还有 HAProxy。它提供高可用性负载均衡，以及基于 TCP、HTTP 和 MQTT 的应用程序代理。到目前为止，HAProxy 2.4 是唯一一款可以提供 MQTT 层负载均衡的免费产品。在他们的 release note（https://www.haproxy.com/blog/announcing-haproxy-2-4/）中，对MQTT 负载均衡的功能作了简单的介绍。
在 「MQTT broker 集群」这个系列的下一篇文章中，我们将对 HAProxy 2.4 + EMQ X 4.3 的集成方案作更为详细的解说。
本文作者：Stone，EMQ messaging platform CTO
We are hiring! Join us and Code the Future together.
简历投递邮箱：hr@emqx.io
EMQ HR
点击"阅读原文" ，了解更多。
↓↓↓
