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 最開始就是爲物聯網設備的網絡接入而設計的，物聯網設備大多都是性能低下，功耗較低的計算機設備，並且網絡鏈接的質量也是不可靠的，因此在設計協議的時候最須要考慮的幾個重點是：

1. 協議要足夠輕量，方便嵌入式設備去快速地解析和響應。
2. 具有足夠的靈活性，使其足覺得 IoT 設備和服務的多樣化提供支持。
3. 應該設計爲異步消息協議而非同步協議，這麼作是由於大多數 IoT 設備的網絡延遲極可能很是不穩定，若使用同步消息協議，IoT 設備須要等待服務器的響應，對於爲大量的 IoT 設備提供服務這一情景，顯然是很是不現實的。
4. 必須是雙向通訊，服務器和客戶端應該能夠互相發送消息。

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 對這些大量的數據作採集存儲，交給數據分析人員來分析處理消息。

---

更多信息請訪問咱們的官網 emqx.io，或關注咱們的開源項目 github.com/emqx/emqx ，詳細文檔請訪問 官方文檔。