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
Kafka MQTT Bridge Example Mosca supports different backends such as redis and mongodb, but also kafka. A Kafka MQTT Bridge application is . |
--------------------- 本文来自 wang被注册了 的CSDN 博客 ,全文地址请点击:https://blog.csdn.net/yeshenzzrff/article/details/79021479?utm_source=copy