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 對這些大量的資料做採集儲存，交給資料分析人員來分析處理訊息。

MQTT 與 Kafka

相關文章