微前端架构如何改变企业的开发模式与效率提升
1350
2022-09-30
Kafka基础知识
Apache Kafka源于LinkedIn,是一个分布式的发布-订阅消息系统。最初LinkedIn开发Kafka的目的,是将Kafka作为内部的活动流和运营数据处理管道处理的基础,因此,所开发的Kafka特点是基于Pull模式来处理消息,追求高吞吐量。2010年,LinkedIn将Kafka贡献给Apache,现在Kafka已经成为应用非常广泛的一个消息中间件。
Kafka使用Scala和Java进行编写,具有快速、可扩展、高吞吐量、内置分区、支持数据副本和可容错等特性,能够支撑海量数据的高效传递。同时Kafka支持消息持久化,从而能够保障对数据高效处理的同时,防止消息数据的丢失。因此,Kafka非常适合在大规模消息处理场景中使用。
Kakfa的基础术语如下:
主题:Topic
在Kafka中将每一个不同类别的消息称为一个主题Topic。在物理上,不同主题(Topic)的消息是分开存储的。在逻辑上,同一个主题(Topic)的消息可能保存在一个或多个代理(Broker)中,但对于生产者或消费者来说,只需指定消息的主题(Topic)就可生产或消费数据,而不用关心消息数据到底存于何处。
生产者:Producer
生产者也就是消息的发布者。负责将消息发布到Kafka中的某个主题(Topic)中,消息代理(Broker)在接收到生产者所发送的消息后,将该消息追加到当前分区中。生产者在发布消息的时候也可以选择将消息发布到主题上的哪一个分区上。
消息代理:Broker
生产者所发布的消息将保存在一组Kafka服务器中,称之为Kafka集群。而集群中的每一个Kafka服务器节点就是一个消息代理Broker。消费者通过消息代理从中获取所订阅的消息并进行消费。
消息分区:Partition
主题所发布的消息数据将会被分割为一个或多个分区(Partition),每一个分区的数据又可以使用多个Segment文件进行存储。在一个分区中的消息数据是有序的,而多个分区之间则没有消息数据顺序。如果一个主题的数据需要严格保证消息的消费顺序,那么需要将分区数目设为1。
当生产者将消息存储到一个分区中时,Kafka会为每条消息数据建立一个唯一索引号(index),这个索引号称为偏移量(offset)。对于消费者来说都会在本地保存该offset,这样当消费者正常消费时,相应本地的偏移量也会增加。同时消费者可以自己控制该偏移量,以便进行消息的重新消费等处理。Kafka的这种设计对消费者来说非常实用。
当新的消息数据追加到分区中时,Kafka集群就会在不同的消息代理(Broker)之间做个备份,从而保证了消息数据的可靠性。此外,Kafka还支持实时的流处理。通过流处理可以持续从某个主题中获取输入数据,并进行处理加工,然后将其写入输出主题中。对于复杂的转换,Kafka提供了Streams API来辅助流处理。通过这种实时的流处理,可以构建聚合计算或者将流连接到一起,形成复杂的应用。
因为Kafka是一个分布式的消息系统,消息代理(Broker)、消费者(Consumer)等都需要ZooKeeper来提供分布式支持,因此在启动Kafka服务器之前需要先启动一个ZooKeeper服务。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~