MQTT 協議在物聯網，小型設備場景，移動應用等方面已經有了廣泛的應用，并逐漸成為了物聯網通訊的標準。本文重點介紹了組建 MQTT Broker 集群的挑戰(zhàn)及負載均衡在 MQTT 集群中所起的作用。

與大家熟悉的 HTTP 協議類似，MQTT 協議同樣基于 TCP/TLS 之上，屬于應用層協議（它也可以基于 HTTP 協議之上工作，本文暫不涉及這部分內容）。

MQTT 標準委員會對 MQTT 協議的釋義如下：

MQTT 是用于物聯網 (IoT) 的 OASIS 標準消息傳遞協議。它是一種非常輕量級的消息傳輸協議，采用了發(fā)布/訂閱的機制，非常適合連接遠程設備，無論是代碼占用空間還是網絡帶寬的占用都很小。如今，MQTT 已被廣泛用于汽車、工業(yè)制造、電信、石油和天然氣等各個行業(yè)。

MQTT 客戶端和 HTTP 客戶端也很相似。它與服務器端建立一個 TCP 連接，通過該連接傳輸數據。不同的是，HTTP 采用的是請求/響應模型，而 MQTT 采用的是發(fā)布/訂閱模型。

舉個例子：客廳里安裝的溫度傳感器，會間斷性的把室內溫度數值上傳到 MQTT 服務器上。而另一個智能家居設備訂閱了這個溫度傳感器發(fā)布消息的頻道，就可以獲得室內的溫度數據，并根據實際室溫采取一些智能應對措施，比如當室內溫度超過 32°C 時就打開空調。

MQTT 協議聽起來似乎離我們很遙遠，其實它早已滲透到了我們的日常生活中。一般情況下，單個 MQTT 節(jié)點就可以滿足單個家庭的智能家居設備連接需求，用戶甚至可以在樹莓派上運行一個 EMQX Edge （運行在邊緣端的 MQTT 服務器）。而運行在云端的一個 EMQX 節(jié)點可以支撐高達 200 萬的連接數，輕松滿足普通智能家居場景需求。

但如果是全國的千百萬輛汽車要聯網，或者是上百萬盞路燈要傳遞數據之類的場景，那么巨大的設備數（MQTT 客戶端）和數據吞吐量，就遠遠超出了單個 MQTT 節(jié)點所能承受的壓力，需要組建 MQTT 服務器集群。

在組建集群的同時，也面臨著一系列的技術挑戰(zhàn)：

1. 提供服務地址：如何讓客戶端知道該連接哪個地址？

2. 不同節(jié)點如何接管 MQTT 訂閱者的會話，比如當一個客戶端從一臺服務器斷連后，要如何在另一臺服務器恢復連接？

3. 集群中各個節(jié)點上的路由表如何保持一致性？

通過在 MQTT 集群前面引入一個負載均衡，可以幫助我們輕松解決問題 1 和 2。

MQTT 負載均衡

為了應對上述問題，負載均衡需要能夠根據配置的均衡策略來幫助客戶端決定連接到哪個節(jié)點。 MQTT 集群負載均衡的主要功能有：

• 對外提供集群服務地址

  客戶端只需要關心負載均衡的地址，而且不需要知道集群內各個節(jié)點的地址。這大大提升了服務器遷移和伸縮的靈活性。

• TLS 終結

  許多 MQTT 的用戶選擇在負載均衡這一層來終結 TLS，這樣可以使 MQTT 服務器的資源被充分用于消息的處理。

• 平衡集群中各個節(jié)點的負載

  負載均衡服務通常可以配置不同的均衡策略，如：隨機分配、輪詢（有些輪詢策略可以調節(jié)節(jié)點權重），還有比較有意思的粘性分配。

由于 MQTT 是基于 TCP/IP 之上的協議，因此可以在傳輸層進行負載均衡。而在傳輸層負載均衡之外，MQTT 能使用的負載均衡產品 HAProxy 2.4 和 Nginx Plus 還提供了應用層（MQTT 層）的負載均衡解決方案。

Nginx Plus 是在 Nginx（一個開源的 Web 服務器，適用于高流量網站的反向代理）基礎上構建的應用程序交付平臺。Nginx Plus 的這篇文章作了較為詳細的描述。

同樣優(yōu)秀的，還有 HAProxy。它提供高可用性負載均衡，以及基于 TCP、HTTP 和 MQTT 的應用程序代理。到目前為止（2021 年 8月），HAProxy 2.4 是唯一一款可以提供 MQTT 層負載均衡的免費產品。在他們的 release note 中，對 MQTT 負載均衡的功能作了簡單的介紹。

在 “MQTT Broker 集群詳解”系列的下一篇文章中，我們將對 HAProxy 2.4 + EMQX 4.3 的集成方案進行詳細展開，敬請期待。

• MQTT Broker 集群詳解（二）：粘性會話負載均衡
• MQTT Broker 集群詳解（三）：有關 EMQX 水平可擴展性的挑戰(zhàn)與對策
• 原創(chuàng)文章，作者：EMQ，如若轉載，請注明出處：https://www.emqx.com/zh/blog/mqtt-broker-clustering-part-1-load-balancing