MQTT与kafka对比分析

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Yeshenzzrff/article/details/79021479

本人的公司内部分享,分享给大家。上面是图片版,下面是文字表格微笑





1.名称

MQTT


kafka


2.历史

IBM推出的一种针对移动终端设备的发布/预订协议。


LinkedIn公司开发的分布式发布-订阅消息系统。后来,成为Apache项目的一部分。


3.原理

基于二进制消息    发布/订阅编程模式的消息协议。


发布/订阅(Publish/Subscribe)模式


4.应用场景

物联网:大量计算能力有限,且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议。                                   

遥感数据

汽车

智能家居

智慧城市

医疗医护



在线应用(消息)和离线应用(数据文件,日志)               1.消息系统(吞吐量,内置的分区,冗余及容错性)                                                       2.行为跟踪(户浏览页面、搜索及其他行为)

3.日志收集(抽象成一个个日志或事件的消息流)




消息系统










ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务。kafka集群,还是producerconsumer都依赖于zookeeper来保证系统可用性。                                                        


5.消息消费(push/pull)









6.角色对比







创建主题(一类消息)

5.主题(Topic

主题筛选器:通过主题对消息进行分类的                             层级主题:通过反斜杠表示多个层级关系;                                 通过通配符进行过滤+可以过滤一个层级,而*只能出现在主题最后表示过滤任意级别的层级。举个例子:

building-b/floor-5:代表B5层的设备。

+/floor-5:代表任何一个楼的5层的设备。

building-b/*:代表B楼所有的设备。

注意,MQTT允许使用通配符订阅主题,但是并不允许使用通配符广播。


每个topic划分为多个partition                                            每个partition在存储层面是append log文件。


6.服务质量(Quality of ServiceQoS

为了满足不同的场景,MQTT支持三种不同级别的服务质量为不同场景提供消息可靠性:

级别0:尽力而为。消息可能会丢,但绝不会重复传输

级别1:消息绝不会丢,但可能会重复传输

级别2:恰好一次。每条消息肯定会被传输一次且仅传输一次


级别1Kafka利用这一特点减少确认从而大大提高了并发。


7.存储方式

内存、redismongdb


磁盘 

 将消息持久化到磁盘,因此可用于批量消费。因为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 partitionlead partition负责读写,并由zookeeper负责fail over

4.通过zookeeper管理brokerconsumer的动态加入与离开                                                                                        

拉取系统

kafka broker会持久化数据,consumer采取pull的方式消费数据:

1.consumer根据消费能力自主控制消息拉取速度

2.consumer根据自身情况自主选择消费模式,例如批量,重复消费,从尾端开始消费等

可扩展性

当需要增加broker结点时,新增的broker会向zookeeper注册,而producerconsumer会根据注册在zookeeper上的watcher感知这些变化,并及时作出调整。








9.消息类型

1. CONNECT:客户端连接到MQTT代理

2. CONNACK:连接确认

3. PUBLISH:新发布消息

4. PUBACK:新发布消息确认,是QoS 1PUBLISH消息的回复

5. PUBRECQoS 2消息流的第一部分,表示消息发布已记录

6. PUBRELQoS 2消息流的第二部分,表示消息发布已释放

7. PUBCOMPQoS 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 onceat least onceat most once),还有层级主题、遗嘱等特性。



12.有意思的东西

Mqtt to Apache Kafka Connect

https://github.com/evokly/kafka-connect-mqtt


Mosca

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.




阅读更多

没有更多推荐了,返回首页