MQTT 協議在物聯網，小型設備場景，移動應用等方面已經有了廣泛的應用，並逐漸成為了物聯網通訊的標准。本文重點介紹了組建 MQTT Broker 集群的挑戰及負載均衡在 MQTT 集群中所起的作用。
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 負載均衡
為了應對上述問題，負載均衡需要能夠根據配置的均衡策略來幫助客戶端決定連接到哪個節點。 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 提問，我們將會及時回復支持。