1、集羣的必要性
MQTT 是專門爲物聯網設備設計的一套標準的通信協議。這套協議在消息模型和功能上與普通的消息隊列協議是差不多的，最大的區別在於應用場景不同。在物聯網應用場景中，IoT 設備性能差，網絡連接不穩定。服務端面臨的挑戰主要是，需要支撐海量的客戶端和主題。
已有的開源的 MQTT 產品，對於協議的支持都不錯，在客戶端數量小於十萬級別的情況下，可以選擇。對於海量客戶端的場景，服務端必須使用集羣來支撐，可以選擇收費的雲服務和企業版產品。也可以選擇自行來構建 MQTT 集羣。
自行構建集羣，最關鍵的技術點就是，通過前置的 Proxy 集羣來解決海量連接、會話管理和海量主題這三個問題。前置 Proxy 負責在 Broker 和客戶端之間轉發消息，通過這種方式，將海量客戶端連接收斂爲少量的 Proxy 與 Broker 之間的連接，解決了海量客戶端連接數的問題。維護會話的實現原理，和 Tomcat 維護 HTTP 會話是一樣的。對於海量主題，可以在後端部署多組 Broker 小集羣，每個小集羣分擔一部分主題這樣的方式來解決。
2、集羣的網絡架構圖
這個圖從左向右看，首先接入的地址最好是一個域名，這樣域名的後面可以配置多個 IP 地址做負載均衡，當然這個域名不是必需的。也可以直接連接負載均衡器。負載均衡可以選擇像 F5 這種專用的負載均衡硬件，
也可以使用 Nginx 這樣的軟件，只要是四層或者支持 MQTT 協議的七層負載均衡設備，都可以選擇。
負載均衡器的後面，需要部署一個 Proxy 集羣，這個 Proxy 集羣承擔了三個重要的作用：第一個作用是來承接海量 IoT 設備的連接，第二個作用是來維護與客戶端的會話，第三個作用是作爲代理，在客戶端和 Broker 之間進行消息轉發。
在 Proxy 集羣的後面是 Broker 集羣，負責保存和收發消息。
3、Mosquitto的分佈式集羣部署
如果需要做併發量很大的時候就需要考慮做集羣處理，但是我在查找資料的時候發現並不多，所以整理了一下，搭建簡單的Mosquitto集羣模式。
首先集羣需要2臺以上的Mosquitto服務器。安裝方式同上。
先了解下Mosquitto集羣模式的邏輯圖，如下：
可以看出，無論在那臺服務器中訂閱了信息，無論在那臺服務器上發佈信息，訂閱者都可以收到發佈的信息。那麼下一步我們着手搭建集羣服務器，爲了方便只演示2臺服務器之間的集羣搭建。
集羣部署有一個專有名詞叫做“橋接”，實現橋接的方式需要修改config.mk與mosquitto.conf文件。值得說明的是如果有10臺服務器做Mosquitto集羣，每臺服務器上將橋連接打開，然後只需要更改一臺服務器上的Mosquitto.conf文件即可，其他服務器的Mosquitto.conf文件不需要做任何改動。大大方便了集羣的維護。如果有新的服務器加入或刪除只需要修改主服務器的Mosquitto.conf即可。
3.1、開啓服務器橋連接
進入安裝目錄
cd mosquitto-1.4.9/
打開config.mk文件
vi config.mk
找到WITH_BRIDGE:=yes 將簽名的“#”號去掉開啓橋連接模式。（默認是開啓的，爲了無誤查看一下）
3.2、配置Mosquitto.conf的橋連接屬性
進入etc目錄，並且打開Mosquitto.conf文件
cd /etc/mosquitto/
vi mosquitto.conf
找到Bridges節點，在下面加入如下代碼：
connection mytest
address 10.19.22.53:1883
topic room1/# both 2 sensor/ myhouse/
bridge_protocol_version mqttv311
notifications true
cleansession true
try_private true
start_type automatic
---------------------------------------------------------------------------------
connection 連接名稱，可以隨便取
address 連接的另外服務器地址和端口號，如果有多臺服務器，可以寫多個address
topic 主題名稱，“#”爲通配符，表示發佈端可以在room1/後面接任何文字
both 服務質量，2代表只有一次
sensor/ 本地前綴標識，可以隨便命名
myhouse/ 遠程前綴標識，可以隨便命名
bridge_protocol_version mqttv311 橋連接協議版本MQTT3.11
notifications 是否發佈橋接的狀態信息
cleansession 橋接斷開時，是否清除遠程服務器中的消息
start_type 橋接模式，目前有三種：automatic、lazy、once
設置好之後保存退出。
3.3、開啓服務器
第一步先確保從服務器先開啓，第二步重新啓動主服務器的Mosquitto服務。如果配置無誤主服務器在開啓的時候，會自動連接所有從服務器，顯示如下:
Mytest實在Mosquitto.conf配置中設定的我的連接名稱，後面是從服務器的地址與端口號
如上圖所示，主服務器與從服務器已經橋接完成。
3.4、驗證發佈/訂閱
集羣的特點在任何服務器上都可以訂閱與發佈，並且訂閱者可以收到在任何服務器中發送去信息。
測試場景：在從服務器中訂閱一條信息，在主服務器中發佈一條信息，從服務器的訂閱者可以收到從主服務器中發佈的消息。
(1)在從服務器中鍵入一下命令：
mosquitto_sub -t myhouse/room1/#
注意：myhouse/ 是編寫Mosquitto.conf中topic的遠程前綴。
room1/#是topic中的訂閱主題
(2)在主服務器中鍵入一下命令：
mosquitto_pub -t sensor/room1/temperature -m '26.3'
注意：sensor/ 是編寫Mosquitto.conf中topic的本地前綴。
room1/ 是topic中的訂閱主題
temperature 相當與“#”通配符
如果Mosquitto.conf配置無誤，並且本地前綴與遠程前綴拼寫正確，那麼會顯示如下圖信息，表示集羣配置成功
在從服務器訂閱，在主服務器發送，從服務器訂閱者收到信息：
4、多集羣部署
配置3臺服務集羣與3+n臺理論一樣，所以這裏配置3臺服務集羣作爲演示。
4.1、安裝服務器
首先在上述2臺服務器基礎上，再增加一臺服務器，配置步驟請參考第二篇博文。 https://www.cnblogs.com/yinyi521/p/6084029.html
4.2、配置服務器
假設有3臺服務器分別是
192.168.0.53
192.168.0.88
192.168.0.89
其中53爲主服務器，88與89爲從服務器。
所以在88與89上只需要正常安裝Mosquitto服務即可，其他不需要做任何配置。
重點還是在53的mosquitto.conf中配置。
依然打開mosquitto.conf，找到Bridge節點，重新複習一下節點中每個配置項的含義
#connection <name>
#address <host>[:<port>] [<host>[:<port>]]
#topic <topic> [[[out | in | both] qos-level] local-prefix remote-prefix]
筆者一開始錯誤的認爲紅色字體部分是配置第二臺服務器使用的，但是筆者錯了。每一個connection只能有一個IP地址，address紅色的部分是留有多個ip的保存。（貌似是對前地址的一個備份，如果前地址服務器掛了可以立馬接手備用服務器，筆者尚未證實）
如果想增加一臺服務器只需要重新添加connection、address、topic節點即可。因此Bridge節點變成下面形式：
connection mytest
address 192.168.0.88:1883
topic room1/# both 2 sensor/ myhouse/
connection mytest2
address 192.168.0.89:1883
topic room1/# both 2 sensor/ myhouse/
bridge_protocol_version mqttv311
notifications true
cleansession true
try_private true
start_type automatic
紅色部分爲新增加的服務器。重啓Mosquitto服務器即可。
4.3、測試訂閱、發佈
測試理論與第一節類似：
分別在88與89服務器中輸入mosquitto_sub -t myhouse/room1/# 訂閱信息
在53服務器中輸入mosquitto_pub -t sensor/room1/temperature -m '26.3' 發佈消息
同事88與89都會收到“26.3”這條信息。如果只有一臺服務器收到說明配置有問題。
以上配置完成了對Mosquitto服務器的基礎配置
