這篇文章主要介紹“MQTT與Kafka怎么理解”,在日常操作中,相信很多人在MQTT與Kafka怎么理解問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”MQTT與Kafka怎么理解”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
MQTT 與 Kafka 是完全不同的兩個東西, MQTT 是協議,是一個技術標準,由 OASIS 技術委員會的成員(其成員多數為 IBM 和微軟的頂級工程師)制訂。而 Kafka 是已經實現的開源流處理平臺,最早由 LinkedIn 開發,于2011年開源后交給 Apache Incubator 孵化后成為了 Apache 軟件基金會的頂級項目。
兩者之前唯一存在的聯系恐怕就是它們都和發布/訂閱范式有關了吧。MQTT 是基于發布/訂閱范式的消息協議,而 Apache Kafka 的生產、消費的流程也是屬于發布/訂閱范式的。那么如果我們基于 MQTT 協議去實現一個消息 broker ,是否這個 MQTT broker是否能和 Kafka 作用等價呢? 答案當然是否定的!
Kafka 雖然也是基于發布訂閱范式的消息系統,但它同時也被稱為“分布式提交日志”或者“分布式流平臺”,它的最主要的作用還是實現分布式持久化保存數據的目的。Kafka 的數據單元就是消息,可以把它當作數據庫里的一行“數據”或者一條“記錄”來理解,Kafka 通過主題來進行分類,Kafka 的生產者發布消息到某一特定主題上,由消費者去消費特定主題的消息,其實生產者和消費者就可以理解成發布者和訂閱者,主題就好比數據庫中的表,每個主題包含多個分區,分區可以分布在不同的服務器上,也就是說通過這種方式來實現分布式數據的存儲和讀取, Kafka 分布式的架構利于讀寫系統的擴展和維護(比如說通過備份服務器來實現冗災備份,通過架構多個服務器節點來實現性能的提升),在很多有大數據分析需求的大型企業,都會用到 Kafka 去做數據流處理的平臺。
而 MQTT 最開始就是為物聯網設備的網絡接入而設計的,物聯網設備大多都是性能低下,功耗較低的計算機設備,而且網絡連接的質量也是不可靠的,所以在設計協議的時候最需要考慮的幾個重點是:
協議要足夠輕量,方便嵌入式設備去快速地解析和響應。
具備足夠的靈活性,使其足以為 IoT 設備和服務的多樣化提供支持。
應該設計為異步消息協議而非同步協議,這么做是因為大多數 IoT 設備的網絡延遲很可能非常不穩定,若使用同步消息協議,IoT 設備需要等待服務器的響應,對于為大量的 IoT 設備提供服務這一情景,顯然是非常不現實的。
必須是雙向通信,服務器和客戶端應該可以互相發送消息。
MQTT 協議完美地解決了上述幾點要求,并且最新版的 MQTT v5.0 協議做了很多優化,使其協議相比過去的 v3.1.1 版本具備更強大的靈活性以及對帶寬的更少占用。
要說基于 MQTT 協議的消息 broker 和 Kafka 的區別的話,EMQ 君認為還是在于它們的側重點不同,Kafka 的側重點在于數據的存儲和讀取,針對實時性比較高的流式數據處理場景;而 MQTT broker 的側重點在于客戶端和服務器的通信。
MQTT broker 與 Kafka 所采用的消息交換范式是如此相近,將其兩者結合起來使用顯然是一個非常不錯的主意,事實上,很多 MQTT broker,諸如 EMQ X 已經實現了 MQTT broker 與 Kafka 的橋接。MQTT broker 用來快速的對大量物聯網設備發來的消息做接收處理響應,而 Kafka 對這些大量的數據做采集存儲,交給數據分析人員來分析處理消息。
到此,關于“MQTT與Kafka怎么理解”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。