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