MQTT与Kafka怎么理解
这篇文章主要介绍“MQTT与Kafka怎么理解”,在日常操作中,相信很多人在MQTT与Kafka怎么理解问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”MQTT与Kafka怎么理解”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
十多年的翔安网站建设经验,针对设计、前端、开发、售后、文案、推广等六对一服务,响应快,48小时及时工作处理。成都营销网站建设的优势是能够根据用户设备显示端的尺寸不同,自动调整翔安建站的显示方式,使网站能够适用不同显示终端,在浏览器中调整网站的宽度,无论在任何一种浏览器上浏览网站,都能展现优雅布局与设计,从而大程度地提升浏览体验。创新互联从事“翔安网站设计”,“翔安网站推广”以来,每个客户项目都认真落实执行。
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 最开始就是为物联网设备的网络接入而设计的,物联网设备大多都是性能低下,功耗较低的计算机设备,而且网络连接的质量也是不可靠的,所以在设计协议的时候最需要考虑的几个重点是:
协议要足够轻量,方便嵌入式设备去快速地解析和响应。
具备足够的灵活性,使其足以为 IoT 设备和服务的多样化提供支持。
应该设计为异步消息协议而非同步协议,这么做是因为大多数 IoT 设备的网络延迟很可能非常不稳定,若使用同步消息协议,IoT 设备需要等待服务器的响应,对于为大量的 IoT 设备提供服务这一情景,显然是非常不现实的。
必须是双向通信,服务器和客户端应该可以互相发送消息。
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怎么理解”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!
分享名称:MQTT与Kafka怎么理解
转载注明:http://pwwzsj.com/article/gjpgjg.html