| 1.名稱 |
MQTT |
|
kafka |
|
| 2.歷史 |
IBM推出的一種針對移動終端設備的發布/預訂協議。 |
|
LinkedIn公司開發的分布式發布-訂閱消息系統。后來，成為Apache項目的一部分。 |
|
| 3.原理 |
基於二進制消息 發布/訂閱編程模式的消息協議。 |
|
發布/訂閱（Publish/Subscribe）模式 |
|
| 4.應用場景 |
物聯網：大量計算能力有限，且工作在低帶寬、不可靠的網絡的遠程傳感器和控制設備通訊而設計的協議。 •遙感數據 •汽車 •智能家居 •智慧城市 •醫療醫護
|
|
在線應用（消息）和離線應用（數據文件，日志） 1.消息系統（吞吐量，內置的分區，冗余及容錯性） 2.行為跟蹤（戶瀏覽頁面、搜索及其他行為） 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），還有層級主題、遺囑等特性。
|
|
||
| 12.有意思的東西 |
Mqtt to Apache Kafka Connect https://github.com/evokly/kafka-connect-mqtt
Kafka MQTT Bridge Example https://github.com/mcollina/mosca/tree/master/examples/kafka Mosca supports different backends such as redis and mongodb, but also kafka. A Kafka MQTT Bridge application is included in the Mosca examples. |
|||
--------------------- 本文來自 wang被注冊了 的CSDN 博客 ，全文地址請點擊：https://blog.csdn.net/yeshenzzrff/article/details/79021479?utm_source=copy