broker的主要職責是接受發(fā)布者發(fā)布的所有消息辟躏，并將其過濾后分發(fā)給不同的消息訂閱者。
如今有很多的broker濒析，下面就是一張關(guān)于各種broker對比的圖片：
目前我用過的有mosquitto和emqttd（2.0版本后改叫EMQ）领舰，因為目前的需求是希望做每秒10萬以上的數(shù)據(jù)接入，所以需要考慮建立集群泛源。但是在使用mosquitto的過程中發(fā)現(xiàn)他不支持集群，所以就放棄了忿危，轉(zhuǎn)投emqttd达箍。
在使用mosquitto過程中發(fā)現(xiàn)了一些問題：
在使用mosquitto時，如果想使用集群的話癌蚁，可能會需要進行二次開發(fā)幻梯。目前只支持橋接。并且他在遍歷時的效率非常低努释，使得他無法支持大量的客戶端或者操作過于頻繁的操作（比如十萬或百萬級別的客戶端同時發(fā)送數(shù)據(jù)）
emqttd有以下優(yōu)點：
- 可靠傳輸碘梢。MQTT可以保證消息可靠安全的傳輸，并可以與企業(yè)應(yīng)用簡易集成伐蒂。
- 消息推送煞躬。支持消息實時通知、豐富的推送內(nèi)容逸邦、靈活的Pub-Sub以及消息存儲和過濾恩沛。
- 低帶寬、低耗能缕减、低成本雷客。占用移動應(yīng)用程序帶寬小，并且?guī)捓寐矢咔沤疲碾娏枯^少搅裙。
- 是中國人寫的一個開源的項目，所以使用起來學(xué)習(xí)成本比較低裹芝，容易上手部逮。
EMQ 2.0 (Erlang/Enterprise/Elastic MQTT Broker) 是基于 Erlang/OTP 語言平臺開發(fā)，支持大規(guī)模連接和分布式集群嫂易，發(fā)布訂閱模式的開源 MQTT 消息服務(wù)器兄朋。(抄自 EMQ官方文檔)
一、MQTT Broker的需求
1怜械、基本需求
1）支持 mqtt3.1 / mqtt3.1.1協(xié)議（可選 mqtt5.0）
3.1和3.1.1是最常見的協(xié)議版本颅和，幾乎目前生產(chǎn)的IoT設(shè)備都支持，所以Broker也必須支持缕允。至于5.0版本融虽，目前各大Broker都在努力支持，不過還需要一些時間才會普及灼芭。
2）支持QoS0往衷、QoS1（可選QoS2）
各大廠商都至少支持了QoS1，保證消息到達适秩。一般的場景下不會用到QoS2斋配，所以可以選擇性地考慮支持QoS2
3）支持遺囑消息
這是必須支持的功能，通常設(shè)備斷開都不是主動斷開的寄悯，而是沒有電了才斷開萤衰，屬于異常斷開，需要設(shè)置遺囑消息來通知后端服務(wù)或者其他設(shè)備進行后續(xù)處理猜旬。
4）支持持久化
一些數(shù)據(jù)如QoS1消息脆栋、持久Session倦卖，需要支持持久化，這是MQTT協(xié)議規(guī)定的椿争。
5）支持多種連接方式
MQTT over TCP：最基礎(chǔ)的連接方式
MQTT over Websocket：在Websocket之上做MQTT封裝怕膛，對APP這種客戶端來說很友好
MQTT over TCP/SSL：基礎(chǔ)連接方式做通信加密，通常SSL采用TLS
MQTT over Websocket/SSL：Websocket做通信加密秦踪，通常SSL采用TLS
6）（可選 保留消息）
保留消息的利用場景幾乎可以忽略褐捻，而帶來的查詢成本會很高（每次訂閱主題都要查一遍有沒有保留消息，再加上通配符匹配椅邓，時延很高）柠逞，所以不一定需要支持，具體應(yīng)用具體分析景馁。
7）支持集群
Broker要支持保持海量MQTT連接板壮，需要做集群。集群的難點在于Session的持久化和集群通信合住。我們既要持久化Session的各項數(shù)據(jù)个束，例如正在發(fā)送但未收到ACK的QoS1消息，又要保證提取速度聊疲，這就是矛盾的事情茬底。而根據(jù)訂閱信息在內(nèi)存中構(gòu)建的訂閱樹，需要整個集群同步获洲，如何做集群同步也是一個難點阱表。任何一個簡單的功能，像發(fā)現(xiàn)相同ClientID則踢掉舊會話贡珊，一旦做到集群里最爬，就是不容易處理的事情。
8）支持自定義驗證方式
驗證客戶端的合法性有三點：CONNECT階段驗證是否允許連接门岔、PUBLISH階段驗證是否允許發(fā)布爱致、SUBSCRIBE階段驗證是否允許訂閱。
CONNECT階段需要驗證ClientID寒随、Username糠悯、Password、IP四項妻往，不過大部分開源Broker都只支持Username和Password的驗證互艾。
PUBLISH、SUBSCRIBE的驗證的目的是防止非法客戶端訂閱別人的主題讯泣，向別人的主題發(fā)布消息纫普。但每臺設(shè)備每次訂閱、發(fā)布都要驗證一次頻率巨高好渠，所以需要設(shè)計Cache和高效查詢機制昨稼。
2节视、高級功能：支持共享訂閱
共享訂閱的具體含義是，多個客戶端訂閱同一個主題假栓，消息只會被分發(fā)給其中的一個客戶端寻行。
共享訂閱主要針對的是需要客戶端負載均衡的場景，比如后端服務(wù)多個Worker但指，需要共享訂閱來只讓一個Worker得到數(shù)據(jù)。但仔細地想一想抗楔，后端服務(wù)一定有大量消息扇入棋凳，在Broker端用共享訂閱可能會導(dǎo)致內(nèi)存爆炸，還不如直接發(fā)到Kafka连躏，利用Kafka的負載均衡來做剩岳。不過現(xiàn)在的Broker都在逐漸支持共享訂閱，所以也是一個趨勢吧入热。
二拍棕、MQTT Broker官方資料
官方相關(guān)鏈接：
三、體驗過的MQTT Broker及其對比
我以為物聯(lián)網(wǎng)已經(jīng)很成熟了勺良，事實上最近才有大量產(chǎn)品上線绰播，網(wǎng)上可以參考的內(nèi)容不多。體驗了很多開源Broker尚困，開源的Broker根本不能直接上生產(chǎn)環(huán)境蠢箩，只有商業(yè)版的HiveMQ和商業(yè)版的EMQ才滿足了所有的需求。先列個表事甜，這些已經(jīng)算是比較優(yōu)秀的Broker了谬泌，分析主要特性：
? - 支持
? - 不支持
？ - 不了解
§ - 支持但做得不好（有限制）
1逻谦、mosquitto
【簡介】
mosquitto是ecplise出的開源Broker掌实，由C/C++語言編寫，目前最新版v1.5.8邦马，是一個開源MQTT Broker贱鼻。
【官方文檔宣稱的特性】
協(xié)議：支持mqtt 3.1 / mqtt 3.1.1
【實際的使用限制分析】
“趁著年輕”大佬早在2013年就開始研究了，當時的版本是1.2.2滋将，那時候還有一些基礎(chǔ)的性能問題忱嘹，比如用的poll而沒有用epoll，內(nèi)存方面沒有優(yōu)化耕渴，多線程主要靠加鎖等等拘悦，預(yù)計可支持10W左右鏈接。于是大佬自己修改了一個版本kulv2012/mosquitto橱脸，優(yōu)化了那些性能础米，這已經(jīng)是五年前了……
同樣的分苇，“逍遙子”2015年在CSDN上分析了mosquitto1.2的源碼，指出epoll需要優(yōu)化屁桑、訂閱樹需要優(yōu)化医寿。將訂閱樹改為了HASH表，直接查找蘑斧，限制了通配符訂閱功能但速度提升明顯靖秩。
mosquitto可以通過橋接的方式進行集群，橋接就是靠一個mosquitto實例去做轉(zhuǎn)發(fā)竖瘾，其他的broker可以轉(zhuǎn)發(fā)給它而已沟突，如果客戶端切換節(jié)點，session就會消失捕传，并且一旦中轉(zhuǎn)Broker掛掉惠拭，整個集群就掛了，這是一種偽集群庸论≈案ǎ“hui6075”在mosquitto上做了真集群hui6075/mosquitto-cluster，也就是自定義一些消息聂示，session可以通過這些消息進行轉(zhuǎn)移域携。
最新版本早就沒有了那些性能問題，也早就從poll改為epoll了（忘了在哪兒看到的）鱼喉，目前正在努力支持mqtt5涵亏，出了一個MQTT5測試版，暫時還不支持共享訂閱蒲凶。
無論如何气筋，總結(jié)一句話，mosquitto是為了嵌入式設(shè)備而生旋圆，正如官方的介紹宠默，mosquitto足夠輕量，可以運行在任何低功率單片機上灵巧，包括嵌入式傳感器搀矫、手機設(shè)備、嵌入式微處理器刻肄，mosquitto用C語言編寫瓤球、集群做的如此簡單就是證明，它不適合用來做云服務(wù)的MQTT Broker敏弃。
【推薦延伸閱讀】
趁著年輕：《Mosquitto pub/sub服務(wù)實現(xiàn)代碼淺析-主體框架》
逍遙子《mosquitto源碼分析（二）》數(shù)據(jù)結(jié)構(gòu)
逍遙子《mosquitto源碼分析（五）》Poll和消息收發(fā)
逍遙子《Mosquito的優(yōu)化——epoll優(yōu)化（七）》
逍遙子《Mosquito的優(yōu)化——訂閱樹優(yōu)化（八）》
逍遙子《Mosquito的優(yōu)化——其他優(yōu)化（九）》
2卦羡、EMQ （emqttd）
【簡介】
EMQ是國人出產(chǎn)的一個開源Broker，已經(jīng)用于很多企業(yè)生產(chǎn)了，幾乎是目前的全能Broker了绿饵，文檔和資料也非常齊全欠肾，但它是用Erlang語言編寫的，這是一個不常見的語言拟赊。有兩個版本2.0和3.0刺桃，最大的區(qū)別是3.0的集群化更好，支持集群共享訂閱功能吸祟，2.0只支持本地共享訂閱功能瑟慈。同時3.0支持mqtt5.0，其他的都是一些性能優(yōu)化屋匕。
【官方文檔宣稱的特性】
MQTT 3.1 / 3.1.1 / 5.0（EMQ3.0）
完整QoS支持
單節(jié)點100萬連接
分布式集群或橋接（還支持mosquitto橋接葛碧、rsmb橋接）、腦裂自動愈合
LDAP, MySQL, PostgreSQL, Redis, MongoDB等驗證插件
完整連接方式支持
API炒瘟、Web監(jiān)控界面
本地共享訂閱（EMQ2.0）吹埠、集群共享訂閱（EMQ3.0）
$SYS統(tǒng)計信息主題
自定義插件開發(fā)
【實際的使用限制分析】
幾乎是完美的第步，只有一點限制疮装，那就是開源版本不支持消息持久化：
EMQ 1.0 版本不支持服務(wù)器內(nèi)部消息持久化，這是一個架構(gòu)設(shè)計選擇粘都。首先廓推，EMQ 解決的核心問題是連接與路由；其次翩隧，我們認為內(nèi)置持久化是個錯誤設(shè)計樊展。
傳統(tǒng)內(nèi)置消息持久化的 MQ 服務(wù)器，比如廣泛使用的 JMS 服務(wù)器 ActiveMQ堆生，幾乎每個大版本都在重新設(shè)計持久化部分专缠。內(nèi)置消息持久化在設(shè)計上有兩個問題:
1）如何平衡內(nèi)存與磁盤使用？消息路由基于內(nèi)存淑仆，消息存儲是基于磁盤涝婉。
2）多服務(wù)器分布集群架構(gòu)下，如何放置 Queue 如何復(fù)制 Queue 的消息蔗怠？
Kafka 在上述問題上墩弯，做出了正確的設(shè)計：一個完全基于磁盤分布式 Commit Log 的消息服務(wù)器。
EMQ 2.0 版本將發(fā)布 EMQ X 平臺產(chǎn)品寞射，支持消息持久化到 Redis渔工、Kafka、Cassandra桥温、PostgreSQL 等數(shù)據(jù)庫引矩。
設(shè)計上分離消息路由與消息存儲職責后，數(shù)據(jù)復(fù)制容災(zāi)備份甚至應(yīng)用集成，可以在數(shù)據(jù)層面靈活實現(xiàn)脓魏。
這是MQTT的標準協(xié)議規(guī)定的啊兰吟，看完源碼后發(fā)現(xiàn)它的普通Publish消息是持久化到分布式數(shù)據(jù)庫Mnesia了（但是如果節(jié)點崩得多也會丟失），而離線消息隊列是基于內(nèi)存的茂翔，也就是Broker一崩消息就丟失了混蔼，很多人都在尋求解決方法，都沒有好的方法珊燎。還有個問題是后端服務(wù)怎么接上去惭嚣，EMQ的設(shè)計根本沒提到后端服務(wù)的問題。大部分的解決方法都是編寫一個插件悔政，把MQTT消息丟到Kafka晚吞，后端服務(wù)處理Kafka的數(shù)據(jù)，但是后端服務(wù)除了收還要發(fā)呀谋国，如果直接作為客戶端連上去槽地，Broker會內(nèi)存爆炸因為后端服務(wù)要發(fā)送的消息太多了。如果你有好的想法芦瘾，請一定要教教我捌蚊。
【推薦延伸閱讀】
知乎：分布式開源物聯(lián)網(wǎng)MQTT消息服務(wù)器EMQ怎么做數(shù)據(jù)的存儲？
Dr_C《EMQ集成Kafka插件編寫過程 emq_plugin_kafka》
響亮響亮《EMQ擴展插件-emq_plugin_kafka》
無腦仔的小明《物聯(lián)網(wǎng)架構(gòu)成長之路(3)-EMQ消息服務(wù)器了解》
無腦仔的小明《物聯(lián)網(wǎng)架構(gòu)成長之路(4)-EMQ插件創(chuàng)建》
無腦仔的小明《物聯(lián)網(wǎng)架構(gòu)成長之路(5)-EMQ插件配置》
無腦仔的小明《物聯(lián)網(wǎng)架構(gòu)成長之路(6)-EMQ權(quán)限控制》
無腦仔的小明《物聯(lián)網(wǎng)架構(gòu)成長之路(7)-EMQ權(quán)限驗證小結(jié)》
無腦仔的小明《物聯(lián)網(wǎng)架構(gòu)成長之路(8)-EMQ-Hook了解近弟、連接Kafka發(fā)送消息》
無腦仔的小明《物聯(lián)網(wǎng)架構(gòu)成長之路(12)-物聯(lián)網(wǎng)架構(gòu)小結(jié)1》
3缅糟、HiveMQ
【簡介】
HiveMQ是企業(yè)級的Broker，用Java編寫祷愉，代碼真的賞心悅目窗宦。由于是收費的，沒有公開的源碼可以看二鳄，我只從一個反編譯的大佬那里看到幾張截圖而已赴涵，只是一些截圖就能夠看到編寫者的Java水平真的很高……
【官方文檔宣稱的特性】
MQTT 3.1 / 3.1.1 / 5.0
完整QoS支持
分布式集群支持
持久化支持
流量控制支持
完整連接方式支持
IPv6支持
集群共享訂閱
$SYS統(tǒng)計信息主題
JMX性能監(jiān)控
日志打印
Docker部署
……
【實際的使用限制分析】
功能上齊全得讓人想哭，唯一的限制就是收費订讼，沒有任何源碼可以參考髓窜。它的集群是基于Jgroups的，持久化的數(shù)據(jù)都是本地+Jgroups同步躯嫉，自己編寫了一套一致性Hash和VectorClock解決沖突……訂閱樹也是完整的訂閱樹纱烘，優(yōu)秀的緩存和并發(fā)訪問控制，集群進行數(shù)據(jù)同步祈餐。多線程和并發(fā)等用的google的guava進行防御性編程擂啥，實在是太厲害了。如果你有源碼帆阳，請多發(fā)給我一份哺壶，我只是用來學(xué)習(xí)屋吨，謝謝！
【推薦延伸閱讀】
西安PP《MQTT---HiveMQ源碼詳解(二)結(jié)構(gòu)與啟動》
西安PP《MQTT---HiveMQ源碼詳解(三)配置加載》
西安PP《MQTT---HiveMQ源碼詳解(四)插件加載》
西安PP《MQTT---HiveMQ源碼詳解(五)Netty-啟動與Listeners加載》
西安PP《MQTT---HiveMQ源碼詳解(六)Netty-Handlers總覽》
西安PP《MQTT---HiveMQ源碼詳解(七)Netty-SSL/NoSSL》
西安PP《MQTT---HiveMQ源碼詳解(八)Netty-WebSocket》
西安PP《MQTT---HiveMQ源碼詳解(九)Netty-Codec》
西安PP《MQTT---HiveMQ源碼詳解(十)Netty-Statistics》
西安PP《MQTT---HiveMQ源碼詳解(十一)Netty-Throttling》
西安PP《MQTT---HiveMQ源碼詳解(十二)Netty-MQTT消息山宾、事件處理(流程)》
西安PP《MQTT---HiveMQ源碼詳解(十三)Netty-MQTT消息至扰、事件處理(源碼舉例解讀)》
西安PP《MQTT---HiveMQ源碼詳解(十四)Persistence-LocalPersistence》
西安PP《MQTT---HiveMQ源碼詳解(十五)Persistence-Cluster/Single》
西安PP《MQTT---HiveMQ源碼詳解(十六)TopicTree》
西安PP《MQTT---HiveMQ源碼詳解(十七)Cluster-Consistent Hashing Ring & Node Lifecycle》
西安PP《MQTT---HiveMQ源碼詳解(十八)Cluster-kryo與Serializer》
西安PP《MQTT---HiveMQ源碼詳解(十九)Cluster-Request/Response》
西安PP《MQTT---HiveMQ源碼詳解(二十)Cluster-Replicate/VectorClock》
西安PP《MQTT---HiveMQ源碼詳解(二十一)完結(jié)篇》
西安PP《MQTT---HiveMQ源碼詳解(外傳)為什么使用Xodus》
4、MqttWk
【簡介】
一個阿里大佬編寫的基于 nutzboot + netty + redis + kafka 實現(xiàn)的MQTT服務(wù)開源broker资锰，代碼非常簡潔干凈敢课，一看就懂。nutzboot是國人編寫的類似于springboot的開源架構(gòu)绷杜，它有一系列的產(chǎn)品直秆，功能和代碼外觀都和spring全家桶很像，但比spring全家桶輕量鞭盟。
【官方文檔宣稱的特性】
MQTT 3.1.1
完整的QoS服務(wù)
完整的連接方式
Kafka消息轉(zhuǎn)發(fā)
集群功能
分發(fā)重試
【實際的使用限制分析】
1）MessageQueue沒有排序：是直接插入Redis的key-value圾结，并不是一個隊列
2）消息分發(fā)重試很差：對于未確認的QoS1消息，只會在重新連接的時候下發(fā)齿诉，如果一直在線就會一直淤積
3）集群功能很差：用Redis的訂閱發(fā)布當作消息總線來構(gòu)建集群筝野，而且我剛熟悉的時候還有問題（1.0.7版本），提交了issue后更新到1.0.8粤剧，不過集群這塊還是不太好歇竟。
4）Kafka消息轉(zhuǎn)發(fā)：只是單純地轉(zhuǎn)發(fā)而已，沒有從后端服務(wù)接收消息的代碼俊扳。而且用原始的代碼去編寫的轉(zhuǎn)發(fā)（為了使用沒有Kafka功能的nutzboot途蒋，沒有用spring的Kafka相關(guān)注解）猛遍。
5）主題：主題有一些限制馋记，不能以/結(jié)尾，不支持通配符訂閱+
我當時還測試出了一些其他的問題懊烤，但是忘記了梯醒，而且這個項目竟然是上生產(chǎn)的項目……經(jīng)歷過2萬設(shè)備連接，我在commitlog里面看到作者還寫“不知道Redis會不會有性能問題”這種提交信息……不過代碼真的非常非常清晰簡潔腌紧，有助于理解MQTT協(xié)議交互過程茸习。
【推薦延伸閱讀】
5、Jmqtt
【簡介】
jmqtt是一個大佬對開源Broker現(xiàn)狀不滿意壁肋，自己做出來的一個開源Broker号胚。代碼思路很清晰，尤其對CONNECT做了優(yōu)化浸遗，而且Session的過期處理得也很好猫胁，編寫了大量多線程代碼，看得出是Java多線程高手跛锌。
【官方文檔宣稱的特性】
完整的QoS等級
支持MQTT弃秆、Websocket連接方式
支持RocksDB進行數(shù)據(jù)本地存儲
【實際的使用限制分析】
不支持集群，不支持共享訂閱，不支持SSL菠赚，MessageQueue不是隊列……但是和大佬交流得最深脑豹，教了我很多東西，很感謝衡查。
【推薦延伸閱讀】
Ciciz：《IoT MQ設(shè)計篇：調(diào)研與協(xié)議選型》
Ciciz：《IoT MQ設(shè)計篇：開源or自研瘩欺，系統(tǒng)復(fù)雜度分析》
Ciciz：《IoT MQ設(shè)計篇：基于開源項目二次開發(fā)的坑》
Ciciz：《IoT MQ設(shè)計篇：最終架構(gòu)與jmqtt介紹》
6、Moquette 0.10
【簡介】
0.10和0.12是兩個核心版本拌牲，功能變化巨大击碗，這里分開敘述。Moquette是我參考得最多的一個Broker了们拙，它是唯一的功能齊全稍途、Java語言編寫的開源Broker，網(wǎng)上很多人都是以Moquette為基礎(chǔ)進行開發(fā)的砚婆。Moquette怎么樣呢械拍，以研究HiveMQ的“西安PP”大佬的原話說——就是一個玩具項目……看和HiveMQ截圖的源碼成熟度對比其實我也能感覺出來。但免費的玩具只有這一個啊装盯，沒得挑坷虑。
【官方文檔宣稱的特性】
完整QoS服務(wù)
完整連接認證方式
多種持久化存儲支持
集群支持
性能監(jiān)控支持
【實際的使用限制分析】
“專注的力量”用它的代碼進行壓測，發(fā)現(xiàn)有內(nèi)存泄漏問題埂奈，于是自己修復(fù)了這些東西迄损，還支持了Redis持久化，發(fā)布了一個開源版本irubant/moquette账磺。moquette的集群只是用了hazelcast作消息總線芹敌，不支持共享訂閱，而且所有的消息都是廣播的垮抗，也沒有在不同Broker節(jié)點上相同clinetID相互踢下線的功能氏捞。沒有消息重發(fā)機制，只會在重連的時候重發(fā)冒版。訂閱樹編寫得非常復(fù)雜液茎，還不斷地以CAS（比較并替換）操作在并發(fā)環(huán)境下更換根節(jié)點，會帶來很多性能問題辞嗡。
【推薦延伸閱讀】
袁志健《從moquette源碼看IOT接入?yún)f(xié)議MQTT的實現(xiàn)》
7捆等、Moquette 0.12
【簡介】
Moquette0.12將整個項目簡化了，Jar包管理方式從Maven改為Gradle续室，不再支持集群栋烤，說是為了讓人1分鐘就能快速上手，放棄了Hazelcast說這種方式做集群不好猎贴，準備先支持MQTT5.0班缎，再考慮做集群的事情蝴光。不過這個版本改進了訂閱樹，還支持了重發(fā)未ACK的消息达址，MessageQueue也采用了Queue蔑祟，去掉了大部分持久化方式，只保留H2沉唠。
【官方文檔宣稱的特性】
支持完整QoS
支持完整連接認證方式
【實際的使用限制分析】
完全地退化……不過代碼更清晰一點了疆虚，各個功能模塊劃分得更清楚。但是單機是最大的缺陷满葛，很難改成集群径簿，幾乎要全改。
8嘀韧、其他
最近又出了一些新的Broker篇亭，例如基于moquette的cassandana，宣稱已經(jīng)用于生產(chǎn)锄贷，還有一些新特性译蒂，想去看看源碼是怎么寫的。
至于Apache ActiveMQ谊却、Apache ActiveMQ Artemis這種基于消息隊列制作的MQTT Broker還沒有使用過柔昼，只是看了一些文章說有性能問題。
