|
在機(jī)智云的整個(gè)架構(gòu)里面，如上圖，GAgent實(shí)現(xiàn)了從模塊到云端的數(shù)據(jù)交互，其實(shí)GAgent里面就是用MQTT協(xié)議實(shí)現(xiàn)的，可見(jiàn)MQTT協(xié)議的重要性。從今天開始的幾節(jié)內(nèi)容，小編將會(huì)帶大家了解物聯(lián)網(wǎng)MQTT協(xié)議的內(nèi)容。這里先介紹MQTT信息和協(xié)議背景。 MQTT介紹
MQTT是客戶端服務(wù)器發(fā)布/訂閱消息傳輸協(xié)議，它重量輕，開放，簡(jiǎn)單，設(shè)計(jì)好，易于實(shí)施，這些特性使其成為在許多情況下的理想選擇，包括了受限的環(huán)境，例如在機(jī)器到機(jī)器（M2M）和物聯(lián)網(wǎng)（IoT）環(huán)境中的通信，只需要小的代碼占用和低網(wǎng)絡(luò)帶寬。
MQTT規(guī)范的摘要很好地描述了MQTT是什么，它是非常輕量級(jí)的二進(jìn)制協(xié)議，相比于HTTP之類的協(xié)議，在傳輸數(shù)據(jù)上比較優(yōu)越因?yàn)樗挥凶钚〉臄?shù)據(jù)包開銷。另一個(gè)重要的方面是MQTT在客戶端非常容易實(shí)現(xiàn)，這很適合于有限資源的設(shè)備。實(shí)際上，這是MQTT發(fā)明的目標(biāo)之一。 MQTT的一點(diǎn)點(diǎn)歷史
MQTT于1999年由Andy Stanford-Clark（IBM）和Arlen Nipper（Arcom，現(xiàn)為Cirrus Link）發(fā)明，當(dāng)他們的是創(chuàng)建一個(gè)協(xié)議，以最小的電池?fù)p耗和最小帶寬連接把石油管道通過(guò)衛(wèi)星進(jìn)行連接。他們指定了以下目標(biāo)，未來(lái)的協(xié)議應(yīng)該有：
這些目標(biāo)仍然是MQTT的核心，雖然重點(diǎn)已經(jīng)從專有的嵌入式系統(tǒng)改為開放的物聯(lián)網(wǎng)使用案例，另一件事是經(jīng)常困惑為什么是MQTT是縮寫呢？MQTT的意義是什么？這是一個(gè)漫長(zhǎng)的故事，簡(jiǎn)短的回答是，MQTT正式?jīng)]有縮寫，只是MQTT，（mqtt很長(zhǎng)的一段歷史這里省略了） 標(biāo)準(zhǔn)版本和當(dāng)前版本
大約3年后首次出版，據(jù)宣布，MQTT應(yīng)在OASIS的標(biāo)準(zhǔn)化下進(jìn)行，OASIS是一個(gè)開放組織，旨在提高標(biāo)準(zhǔn)，AMQP，SAML，DocBook只是已經(jīng)發(fā)布的幾個(gè)標(biāo)準(zhǔn)標(biāo)準(zhǔn)化過(guò)程大約需要1年時(shí)間，2014年10月29日，MQTT被正式批準(zhǔn)為OASIS標(biāo)準(zhǔn)。 MQTT 3.1.1現(xiàn)在是該協(xié)議的最新版本。 發(fā)布/訂閱模式
發(fā)布/訂閱模式（pub / sub）是傳統(tǒng)客戶端 - 服務(wù)器模型的替代方案，客戶端直接與端點(diǎn)通信。然而，Pub / Sub將正在接收消息（稱為訂戶）的另一客戶端（或更多客戶端）發(fā)送特定消息（稱為發(fā)布者）的客戶端去耦，這意味著發(fā)布者和訂閱者不了解彼此的存在，有一個(gè)第三個(gè)組件，稱為代理，由它作為中轉(zhuǎn)，它將過(guò)濾所有傳入的消息并相應(yīng)地分發(fā)給它們，所以我們來(lái)詳細(xì)介紹一下剛剛提及的方面。記住，這仍然是關(guān)于pub / sub的基本部分，我們將在短短的一個(gè)時(shí)間內(nèi)討論MQTT細(xì)節(jié)。
如上所述，pub / sub的主要方面是發(fā)布者和接收者的解耦，可以在更多維度上進(jìn)行區(qū)分 空間解耦：發(fā)布者和訂閱者不需要彼此認(rèn)識(shí)， 時(shí)間解耦：發(fā)布者和訂閱者不需要同時(shí)運(yùn)行 同步解耦：兩個(gè)組件的操作在發(fā)布或接收過(guò)程中都不會(huì)停止，同步進(jìn)行
總之，發(fā)布/訂閱解除消息的發(fā)布者和接收者，通過(guò)過(guò)濾消息，只有某些客戶端可能接收到某些消息，解耦有三個(gè)維度：空間，時(shí)間，同步。 可擴(kuò)展性
Pub / Sub還提供比傳統(tǒng)的客戶端 - 服務(wù)器方法更大的可擴(kuò)展性，這是因?yàn)榇砩系牟僮骺梢愿叨炔⑿谢⑻幚硎录?qū)動(dòng)，消息緩存和消息的智能路由通常也是提高可擴(kuò)展性的決定性因素，但是，擴(kuò)展發(fā)布/訂閱數(shù)百萬(wàn)的連接絕對(duì)是一個(gè)挑戰(zhàn)，這可以使用集群代理節(jié)點(diǎn)實(shí)現(xiàn)，以便通過(guò)負(fù)載平衡器將負(fù)載分配到更多個(gè)體服務(wù)器上（這個(gè)問(wèn)題，我會(huì)在后面詳細(xì)講解） 消息過(guò)濾
那么有趣的是，代理如何篩選所有的消息的？為什么每個(gè)訂閱者只收到它感興趣的消息？ 過(guò)濾是基于主題的，這是每個(gè)消息的一部分，接收客戶端訂閱與該代理商感興趣的主題，并從中獲取所有基于訂閱主題的消息，主題通常具有層次結(jié)構(gòu)的字符串，允許基于有限數(shù)量的表達(dá)式進(jìn)行過(guò)濾。 基于內(nèi)容的過(guò)濾正如名稱所說(shuō)的的那樣，當(dāng)代理根據(jù)特定內(nèi)容過(guò)濾器語(yǔ)言過(guò)濾消息時(shí)，因此，客戶端訂閱過(guò)濾他們感興趣的消息的進(jìn)行查詢，這樣做的一大缺點(diǎn)是，消息的內(nèi)容必須事先知道，不能輕易加密或更改。 當(dāng)使用面向?qū)ο笳Z(yǔ)言時(shí)，通常的做法是根據(jù)消息的類型/類進(jìn)行過(guò)濾 ，在這種情況下，訂閱者可以監(jiān)聽這種類型所有消息。
當(dāng)然，發(fā)布/訂閱不是一個(gè)新技術(shù)，在使用它之前有些事情要考慮。發(fā)布商和訂閱者的解耦pub / sub的關(guān)鍵，這里也帶來(lái)了一些要求，您必須事先知道已發(fā)布數(shù)據(jù)的結(jié)構(gòu)，在基于主題的過(guò)濾的情況下，發(fā)布者和訂閱者都需要了解正確的主題，另一方面是傳遞消息，發(fā)布者不能假設(shè)有人正在收聽他發(fā)送的消息，因此，任何用戶都不會(huì)讀取消息。 MQTT中的發(fā)布和訂閱
現(xiàn)在我們已經(jīng)學(xué)到了很多關(guān)于發(fā)布/訂閱的內(nèi)容，但是在具體的MQTT中呢?MQTT體現(xiàn)了所有提到的方面，這取決于你想要實(shí)現(xiàn)的內(nèi)容。MQTT解除了發(fā)布者和訂閱者的空間上的耦合，所以他們只需要知道主機(jī)名/ ip和端口的代理才能發(fā)布/訂閱消息。它也能在時(shí)間上分離，但這往往只是一個(gè)倒退的行為，因?yàn)橹饕菍?shí)時(shí)發(fā)送消息。當(dāng)然，代理能夠?yàn)椴辉诰�的客戶端存儲(chǔ)消息（這需要兩個(gè)條件：客戶端連接一次，會(huì)話持續(xù)，并且已經(jīng)訂閱了服務(wù)質(zhì)量大于0的主題）。
MQTT也能夠解耦同步，因?yàn)榇蠖鄶?shù)客戶端庫(kù)都是異步工作的，并且基于回調(diào)或類似模型。因此，在等待消息或發(fā)布消息時(shí)不會(huì)阻止其他任務(wù)。但是在某些使用情況下，同步是可取的，也是可能的，因此，某些庫(kù)具有同步API以及等待某個(gè)消息。但通常流程是異步的。應(yīng)該提到的另一件事是MQTT在客戶端特別容易使用，大多數(shù)pub / sub系統(tǒng)在代理方面具有最大的邏輯，但是MQTT在使用客戶端庫(kù)實(shí)際上是pub / sub的本質(zhì)，并且使其成為小型而且受限設(shè)備的輕量級(jí)協(xié)議。
采用基于消息的主題過(guò)濾MQTT，每個(gè)消息都包含一個(gè)主題，如果訂閱客戶端將收到消息，則代理用于查找，有關(guān)主題的更多詳細(xì)信息，請(qǐng)參見(jiàn)MQTT 要點(diǎn)的第5部分。還可以使用HiveMQ MQTT代理及其自定義插件系統(tǒng)進(jìn)行基于內(nèi)容的過(guò)濾。為了處理一般的pub/sub 系統(tǒng)的挑戰(zhàn)，MQTT具有服務(wù)質(zhì)量（QoS）級(jí)別，很容易指定消息從客戶端成功傳遞到代理或從代理到客戶端，但仍然有機(jī)會(huì)沒(méi)有人訂閱特定的主題。
如果這是一個(gè)問(wèn)題，這取決于代理服務(wù)器如何處理這種情況。例如，HiveMQ MQTT代理有一個(gè)插件系統(tǒng)，它能夠識(shí)別這種情況并采取行動(dòng)或只是將每條消息記錄到數(shù)據(jù)庫(kù)中進(jìn)行歷史分析，為了減輕主題的不靈活性，重要的是非常仔細(xì)地設(shè)計(jì)主題樹，并為未來(lái)的使用留下空間。如果您遵循這些策略，MQTT將是完美裝置。 與消息隊(duì)列區(qū)分開來(lái)
所以有很多關(guān)于MQTT的混亂，因?yàn)樗拿郑袽QTT和消息隊(duì)列混在一起了。我們將解釋這個(gè)分歧，在我們的最后一篇文章中，我們已經(jīng)指出了這個(gè)名字，MQTT來(lái)自名為MQSeries的IBM產(chǎn)品，與之無(wú)關(guān)。但不管名字，MQTT和傳統(tǒng)消息隊(duì)列之間有什么區(qū)別？ 當(dāng)使用消息隊(duì)列時(shí)，每個(gè)傳入的消息將被存儲(chǔ)在該隊(duì)列中，直到被任何客戶端（通常稱為消費(fèi)者）拾取。否則，消息將被卡在隊(duì)列中并等待獲取，消息不可能被任何客戶端處理，就像在MQTT中，如果沒(méi)有人訂閱主題。
另一個(gè)很大的區(qū)別是，傳統(tǒng)的隊(duì)列中只有一個(gè)消費(fèi)者處理消息。因此，負(fù)載可以在特定隊(duì)列的所有消費(fèi)者之間分配。在MQTT中，如果訂閱主題，每個(gè)訂閱者都會(huì)收到消息。
隊(duì)列比主題要僵硬得多，在使用隊(duì)列之前，必須使用單獨(dú)的命令創(chuàng)建它，只有在此之后，才有可能發(fā)布或使用消息，而在MQTT中，主題非常靈活，可以即時(shí)創(chuàng)建。
如果有什么不同見(jiàn)解，歡迎在評(píng)論中我們討論。 學(xué)習(xí)總結(jié)
MQTT是基于發(fā)布和訂閱機(jī)制的 發(fā)布者和接收者是解耦的，沒(méi)有直接的聯(lián)系 如何實(shí)現(xiàn)消息匹配對(duì)應(yīng)是通過(guò)過(guò)濾實(shí)現(xiàn)的 MQTT是與消息隊(duì)列機(jī)制是不同的
| 
