爲什麼當我需要mqtt經紀人的物聯網/ M2M應用

Question

只是問一個愚蠢的問題，希望有人能回答這個問題。

對於MQTT代理，我有點困惑。基本上，混淆是，數據存儲，傳輸和處理有很多東西（如Flume，HDInsight，Spark等）。那麼，何時以及爲什麼我需要使用一個MQTT代理？

如果我想使用HiveMQ的Windows 10 IOT應用程序，從哪裏可以獲得詳細信息？如何使用它？我如何從MQTT經紀人中獲益？我能否直接使用Azure或HDFS從我的IoT應用程序發送數據？那麼，MQTT經紀人如何融入其中或幫助我實現某些目標？

我是新來的所有這些，並試圖找到一些教程，但我沒有得到任何正確的。請詳細解釋一下，或者給出一些教程？

Answer 1

這是一個建築選擇。物聯網應用可能沒有MQTT，但使用MQTT有一些優勢。如果你是完全新的MQTT，看看這種深入MQTT系列：http://forkbomb-blog.de/2015/all-you-need-to-know-about-mqtt

基本上主要的架構優勢是發佈/訂閱設計的低延遲，高吞吐量（移動），以最小的協議開銷通信（如果帶寬很高，這一點很重要）。你可以完全分離消費者和生產者。

HDFS是（分佈式）Hadoop文件系統，是Map/Reduce處理的基礎。這與MQTT經紀人無法比擬。但是，MQTT代理可以寫入HDFS（如果HiveMQ使用自定義插件）。

基本上MQTT是一個協議，而你是提的產品，以及，這解決完全不同的問題的產品：

水槽基本上用於日誌聚合在規模。您不會使用MQTT，至少沒有太多優勢，因爲這通常在後端應用程序中完成。

Spark和Hadoop在大數據處理方面大放異彩。他們是一個框架，而不是一個隨時可用的解決方案。它們與MQTT沒有真正的可比性。通常，像HiveMQ這樣的MQTT代理與這些，Spark/Hadoop進行數據處理以及HiveMQ進行通信。

我希望這可以幫助您入門。最好的方法是閱讀所有這些技術的典型用例，這對於單個SO回答來說有點過於寬泛。

Answer 2

MQTT是一種基於pub-sub傳輸的客戶端 - 服務器協議，具有相對較小的開銷，因此適用於移動和物聯網應用（與Flume等不同）。 MQTT代理基本上是一個處理MQTT客戶端消息傳遞的服務器。儘管存在各種MQTT附件，但傳輸層的功能幾乎停止。

如果您正在尋求實施一種解決方案，將數據從物聯網設備可靠地傳輸到後端系統進行處理，我建議您查看Kaa open-source IoT platform。它不僅提供了適用於低功耗物聯網設備的傳輸層，而且還提供了一個可靠的應用程序級邏輯塊（包括用於應用程序級數據結構的對象綁定，臨時數據持久性等），這比MQTT更進一步。 ）。

這裏是一個網絡研討會的鏈接，解釋how to build a scalable IoT analytics system with Kaa and Spark in less than an hour。

Answer 3

MQTT是一種數據傳輸方式，所以我必須將其與HTTP進行比較。 HTTP有兩個重要的特徵：a）從一點到另一點，b）它是請求/響應，所以只有一端可以啓動數據傳輸。 MQTT將許多端點連接到許多端點，並且任一端都可以啓動數據傳輸。因此，如果您只有一臺設備，並且只有一個服務或人員可以訪問它，並且只通過輪詢，那麼HTTP非常棒。 MQTT意味着許多設備可以將數據發佈到許多服務或人員，反過來也是如此。您的問題假設您的數據總是會在某種數據存儲中出現，但許多交互是關於事件並立即響應，例如敲響門鈴或降低起落架。在這些情況下，您經常需要記錄數據並立即採取措施，例如您的手機發出門鈴噪音。

最後，您將數據以語義方式發送到MQTT，而不是通過IP地址發送。 這意味着您的服務訂閱了/ mikeshouse/doorbell，而不是輪詢192.168.22.4，這是一旦您擁有多個設備後的巨大收益。