1.名稱

MQTT

kafka

2.歷史

IBM推出的一種針對移動終端裝置的釋出/預訂協議。

LinkedIn公司開發的分散式釋出-訂閱訊息系統。後來，成為Apache專案的一部分。

3.原理

基於二進位制訊息 釋出/訂閱程式設計模式的訊息協議。

釋出/訂閱（Publish/Subscribe）模式

4.應用場景

物聯網：大量計算能力有限，且工作在低頻寬、不可靠的網路的遠端感測器和控制裝置通訊而設計的協議。

•遙感資料

•汽車

•智慧家居

•智慧城市

•醫療醫護

線上應用（訊息）和離線應用（資料檔案，日誌）

3.日誌收集（抽象成一個個日誌或事件的訊息流）

訊息系統

ZooKeeper是一個分散式的，開放原始碼的分散式應用程式協調服務。kafka叢集，還是producer和consumer都依賴於zookeeper來保證系統可用性。

5.訊息消費(push/pull)

6.角色對比

建立主題(一類訊息)

5.主題（Topic）

主題篩選器：通過主題對訊息進行分類的層級主題：通過反斜槓表示多個層級關係；通過萬用字元進行過濾：+可以過濾一個層級，而*只能出現在主題最後表示過濾任意級別的層級。舉個例子：

•building-b/floor-5：代表B樓5層的裝置。

•+/floor-5：代表任何一個樓的5層的裝置。

•building-b/*：代表B樓所有的裝置。

注意，MQTT允許使用萬用字元訂閱主題，但是並不允許使用萬用字元廣播。

每個topic劃分為多個partition。每個partition在儲存層面是append log檔案。

6.服務質量（Quality of Service，QoS）

為了滿足不同的場景，MQTT支援三種不同級別的服務質量為不同場景提供訊息可靠性：

•級別0：盡力而為。訊息可能會丟，但絕不會重複傳輸

•級別1：訊息絕不會丟，但可能會重複傳輸

•級別2：恰好一次。每條訊息肯定會被傳輸一次且僅傳輸一次

級別1，Kafka利用這一特點減少確認從而大大提高了併發。

7.儲存方式

記憶體、redis、mongdb等

磁碟

將訊息持久化到磁碟，因此可用於批量消費。因為kafka是對日誌檔案進行append操作,因此磁碟檢索的開支是較小的;為了減少磁碟寫入的次數,broker會將訊息暫時buffer起來,當訊息的個數(或尺寸)達到一定閥值時,再flush到磁碟,這樣減少了磁碟IO呼叫的次數.

8.設計原則（為什麼MQTT用來做物聯網訊息傳輸、Kafka用來做日誌收集）

1.協議精簡，不新增可有可無的功能。

2.釋出/訂閱（Pub/Sub）模式，方便訊息在感測器之間傳遞。

3.允許使用者動態建立主題，零運維成本。

4.把傳輸量降到最低以提高傳輸效率。（固定長度的頭部是2位元組），協議交換最小化，以降低網路流量。

5.把低頻寬、高延遲、不穩定的網路等因素考慮在內。

6.支援連續的會話控制。

7.理解客戶端計算能力可能很低。

8.提供服務質量管理。

9.假設資料不可知，不強求傳輸資料的型別與格式，保持靈活性。

吞吐量

1.資料磁碟持久化：訊息不在記憶體中cache，直接寫入到磁碟，充分利用磁碟的順序讀寫效能

2.zero-copy：減少IO操作步驟

3.資料批量傳送

4.資料壓縮

5.Topic劃分為多個partition，提高parallelism

負載均衡

1.生產者傳送訊息到pattition

2.存在多個partiiton，每個partition有自己的replica，每個replica分佈在不同的Broker節點上

3.多個partition需要選取出lead partition，lead partition負責讀寫，並由zookeeper負責fail over

4.通過zookeeper管理broker與consumer的動態加入與離開

拉取系統

kafka broker會持久化資料，consumer採取pull的方式消費資料：

1.consumer根據消費能力自主控制訊息拉取速度

2.consumer根據自身情況自主選擇消費模式，例如批量，重複消費，從尾端開始消費等

可擴充套件性

當需要增加broker結點時，新增的broker會向zookeeper註冊，而producer及consumer會根據註冊在zookeeper上的watcher感知這些變化，並及時作出調整。

9.訊息型別

1.CONNECT：客戶端連線到MQTT代理

2.CONNACK：連線確認

3.PUBLISH：新發布訊息

4.PUBACK：新發布訊息確認，是QoS 1給PUBLISH訊息的回覆

5.PUBREC：QoS 2訊息流的第一部分，表示訊息釋出已記錄

6.PUBREL：QoS 2訊息流的第二部分，表示訊息釋出已釋放

7.PUBCOMP：QoS 2訊息流的第三部分，表示訊息釋出完成

8.SUBSCRIBE：客戶端訂閱某個主題

9.SUBACK：對於SUBSCRIBE訊息的確認

10.UNSUBSCRIBE：客戶端終止訂閱的訊息

11.UNSUBACK：對於UNSUBSCRIBE訊息的確認

12.PINGREQ：心跳

13.PINGRESP：確認心跳

14.DISCONNECT：客戶端終止連線前優雅地通知MQTT代理

／

10.服務端實現

數十個 MQTT 伺服器端程式Mosquitto(C/C++)

emqttd(Erlang/OTP)

Moquette

HiveMQ(Java)

Scala官方實現的系統

11.總結

兩者都是從傳統的Pub/Sub訊息系統演化出來的，但是進化的方向不一樣。 Kafka是為了資料整合的場景，通過分散式架構提供了海量訊息處理、高容錯的方式儲存海量資料流、保證資料流的順序等特性。

MQTT是為了物聯網場景而優化，提供多個QoS選項（exact once、at least once、at most once），還有層級主題、遺囑等特性。