Kafka权威指南 —— 1.2 初识Kafka

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: Kafka权威指南 —— 1.2 初识Kafka

什么是Kafka


Apache Kafka是一个基于分布式日志提交机制设计的发布订阅系统。数据在kafka中持久化,用户可以随时按需读取。另外数据以分布式的方式存储,提高容错性,易于扩展。


Message和Batches


Kafka中最基本的数据单元是消息message,如果使用过数据库,那么可以把Kafka中的消息理解成数据库里的一条行或者一条记录。消息是由字符数组组成的,kafka并不关系它内部是什么,索引消息的具体格式与Kafka无关。消息可以有一个可选的key,这个key也是个字符数组,与消息一样,对于kafka也是透明的。key用来确定消息写入分区时,进入哪一个分区。最简单的处理方式,就是把key作为hash串,拥有相同key的消息,肯定会进入同一个分区。


为了提高效率,Kafka以批量的方式写入。一个batch就是一组消息的集合,这一组的数据都会进入同一个topic和partition(这个是根据producer的配置来定的)。每一个消息都进行一次网络传输会很消耗性能,因此把消息收集到一起,再同时处理就高效的多了。当然,这样会引入更高的延迟以及吞吐量:batch越大,同一时间处理的消息就越多。batch通常都会进行压缩,这样在传输以及存储的时候效率都更高一些。


Schemas


对于Kafa来说,消息本身是不透明的,这样就能对消息定义更多容易理解的内容。根据个人的需求不同,消息也会有不同的schema。比如JSON或者XML都是对人来说很容易阅读的格式。然后他们在不同的模式版本中间缺乏一些处理的鲁棒性和可扩展性。一些Kafka的开发者也倾向于使用Apache Avro(最开始是用来为Hadoop做序列化的),提供了紧凑的序列化格式,在发生变化时,也不需要重新生成代码,具有很强的数据类型和模式,具有很好的向前扩展与向后兼容的能力。


Kafka中数据是连续的,在数据在写入到同时也可能被读取消费,这样数据的格式就很重要了。如果数据的格式发生变化,消费的应用也需要做出适当的调整。如果事先定义好了数据存储的格式,那么读取数据的时候就不需要做特殊的处理了。


Topics和Partitions


消息都是以主题Topic的方式组织在一起,Topic也可以理解成传统数据库里的表,或者文件系统里的一个目录。一个主题由broker上的一个或者多个Partition分区组成。在Kafka中数据是以Log的方式存储,一个partition就是一个单独的Log。消息通过追加的方式写入日志文件,读取的时候则是从头开始按照顺序读取。注意,一个主题通常都是由多个分区组成的,每个分区内部保证消息的顺序行,分区之间是不保证顺序的。如果你想要kafka中的数据按照时间的先后顺序进行存储,那么可以设置分区数为1。如下图所示,一个主题由4个分区组成,数据都以追加的方式写入这四个文件。分区的方式为Kafka提供了良好的扩展性,每个分区都可以放在独立的服务器上,这样就相当于主题可以在多个机器间水平扩展,相对于单独的服务器,性能更好。

72bcd22bafe5c81af540ff8d01d71593.jpg


在Kafka这种数据系统中经常会提起stream流这个词,通常流被认为是一个主题中的数据,而忽略分区的概念。这就意味着数据流就是从producer到consumer。在很多框架中,比如kafka stream,apache samza,storm在操作实时数据的时候,都是这样理解数据流的。这种操作的模式跟离线系统处理数据的方式不同,如hadoop,是在某一个固定的时间处理一批的数据。


Producer和Consumer


Kafka中主要有两种使用者:Producer和consumer。


Producer用来创建消息。在发布订阅系统中,他们也被叫做Publisher发布者或writer写作者。通常情况下,消息都会进入特定的主题。默认情况下,生产者不关系消息到底进入哪个分区,它会自动在多个分区间负载均衡。也有的时候,消息会进入特定的一个分区中。一般都是通过消息的key使用哈希的方式确定它进入哪一个分区。这就意味着如果所有的消息都给定相同的key,那么他们最终会进入同一个分区。生产者也可以使用自定义的分区器,这样消息可以进入特定的分区。


Consumer读取消息。在发布订阅系统中,也叫做subscriber订阅者或者reader阅读者。消费者订阅一个或者多个主题,然后按照顺序读取主题中的数据。消费者需要记录已经读取到消息的位置,这个位置也被叫做offset。每个消息在给定的分区中只有唯一固定的offset。通过存储最后消费的Offset,消费者应用在重启或者停止之后,还可以继续从之前的位置读取。保存的机制可以是zookeeper,或者kafka自己。


消费者是以consumer group消费者组的方式工作,由一个或者多个消费者组成一个组,共同消费一个topic。每个分区在同一时间只能由group中的一个消费者读取,在下图中,有一个由三个消费者组成的grouop,有一个消费者读取主题中的两个分区,另外两个分别读取一个分区。某个消费者读取某个分区,也可以叫做某个消费者是某个分区的拥有者。


在这种情况下,消费者可以通过水平扩展的方式同时读取大量的消息。另外,如果一个消费者失败了,那么其他的group成员会自动负载均衡读取之前失败的消费者读取的分区。

41ba3ffc1b20d8d04316e8e31af416f6.jpg

Brokers和Clusters


单独的kafka服务器也叫做broker,Broker从生产者那里获取消息,分配offset,然后提交存储到磁盘年。他也会提供消费者,让消费者读取分区上的消息,并把存储的消息传给消费者。依赖于一些精简资源,单独的broker也可以轻松的支持每秒数千个分区和百万级的消息。


Kafka的broker支持集群模式,在Broker组成的集群中,有一个节点也被叫做控制器(是在活跃的节点中自动选择的)。这个controller控制器负责管理整个集群的操作,包括分区的分配、失败节点的检测等。一个partition只能出现在一个broker节点上,并且这个Broker也被叫做分区的leader。一个分区可以分配多个Broker,这样可以做到多个机器之间备份的效果。这种多机备份在其中一个broker失败的时候,可以自动选举出其他的broker提供服务。然而,producer和consumer都必须连接leader才能正常工作。


6683a3578da386972d4cffaf8e26f217.jpg

Kafka的一个重要特性就是支持数据的过期删除,数据可以在Broker上保留一段时间。Kafka的broker支持针对topic设置保存的机制,可以按照大小配置也可以按照时间配置。一旦达到其中的一个限制,可能是时间过期也可能是大小超过配置的数值,那么这部分的数据都会被清除掉。每个topic都可以配置它自己的过期配置,因此消息可以按照业务的需要进行持久化保留。比如,一个数据追踪分析的topic可以保留几天时间,一些应用的指标信息则只需要保存几个小时。topic支持日志数据的压缩,这样kafka仅仅会保留最后一条日志生成的key。这在修改日志类型的时候会非常有用。


Multiple Cluster


随着Kafka部署环境的演变,有时候需要莉利用多集群的优势。使用多集群的原因如下:

1 不同类型数据的分离

2 安全隔离

3 多数据中心(灾备)

在使用多数据中心的时候,需要很清楚的理解消息是如何在她们之间传递的。一般情况下,用户可以在多个对外提供服务的网址,产生一些前端数据,然后利用kafka把他们统一的汇总到一起,进行分析监控告警。这种备份的机制一般都是应用于单个集群,而不是多集群。


Kafka项目提供了一个叫做mirro maker的工具,它支持多机房的数据传输。它其实就是一个基于queu连接的consumer和producer。消息从kafka中消费,然后传输给另一个集群的kafka。如下图所示,就是使用mirror maker的一个例子,消息在两个集群的本地聚合,然后再传输给另一个集群进行分析。由于kafka设计的精简,可以在多机房中实现这种简单的管道处理机制。

e51f501d543e24aadc00323acef9384d.jpg

目录
相关文章
|
消息中间件 存储 缓存
kafka权威指南 第二章第6节 Kafka集群配置与调优
kafka权威指南 第二章第6节 Kafka集群配置与调优
289 0
kafka权威指南 第二章第6节 Kafka集群配置与调优
|
消息中间件 Kafka
《kafka权威指南》读书笔记
《kafka权威指南》读书笔记
134 0
|
消息中间件 监控 Kafka
《Kafka权威指南》——初识 Kafka
发布与订阅消息系统 在正式讨论Apache Kafka (以下简称Kafka)之前,先来了解发布与订阅消息系统的概念, 并认识这个系统的重要性。数据(消息)的发送者(发布者)不会直接把消息发送给接收 者,这是发布与订阅消息系统的一个特点。
1511 0
|
1月前
|
消息中间件 存储 运维
为什么说Kafka还不是完美的实时数据通道
【10月更文挑战第19天】Kafka 虽然作为数据通道被广泛应用,但在实时性、数据一致性、性能及管理方面存在局限。数据延迟受消息堆积和分区再平衡影响;数据一致性难以达到恰好一次;性能瓶颈在于网络和磁盘I/O;管理复杂性涉及集群配置与版本升级。
|
1月前
|
消息中间件 Java Kafka
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
46 1
|
3月前
|
消息中间件 Java Kafka
Kafka不重复消费的终极秘籍!解锁幂等性、偏移量、去重神器,让你的数据流稳如老狗,告别数据混乱时代!
【8月更文挑战第24天】Apache Kafka作为一款领先的分布式流处理平台,凭借其卓越的高吞吐量与低延迟特性,在大数据处理领域中占据重要地位。然而,在利用Kafka进行数据处理时,如何有效避免重复消费成为众多开发者关注的焦点。本文深入探讨了Kafka中可能出现重复消费的原因,并提出了四种实用的解决方案:利用消息偏移量手动控制消费进度;启用幂等性生产者确保消息不被重复发送;在消费者端实施去重机制;以及借助Kafka的事务支持实现精确的一次性处理。通过这些方法,开发者可根据不同的应用场景灵活选择最适合的策略,从而保障数据处理的准确性和一致性。
268 9
|
3月前
|
消息中间件 负载均衡 Java
"Kafka核心机制揭秘:深入探索Producer的高效数据发布策略与Java实战应用"
【8月更文挑战第10天】Apache Kafka作为顶级分布式流处理平台,其Producer组件是数据高效发布的引擎。Producer遵循高吞吐、低延迟等设计原则,采用分批发送、异步处理及数据压缩等技术提升性能。它支持按消息键值分区,确保数据有序并实现负载均衡;提供多种确认机制保证可靠性;具备失败重试功能确保消息最终送达。Java示例展示了基本配置与消息发送流程,体现了Producer的强大与灵活性。
67 3
|
3月前
|
vr&ar 图形学 开发者
步入未来科技前沿:全方位解读Unity在VR/AR开发中的应用技巧,带你轻松打造震撼人心的沉浸式虚拟现实与增强现实体验——附详细示例代码与实战指南
【8月更文挑战第31天】虚拟现实(VR)和增强现实(AR)技术正深刻改变生活,从教育、娱乐到医疗、工业,应用广泛。Unity作为强大的游戏开发引擎,适用于构建高质量的VR/AR应用,支持Oculus Rift、HTC Vive、Microsoft HoloLens、ARKit和ARCore等平台。本文将介绍如何使用Unity创建沉浸式虚拟体验,包括设置项目、添加相机、处理用户输入等,并通过具体示例代码展示实现过程。无论是完全沉浸式的VR体验,还是将数字内容叠加到现实世界的AR应用,Unity均提供了所需的一切工具。
135 0
|
3月前
|
消息中间件 存储 关系型数据库
实时计算 Flink版产品使用问题之如何使用Kafka Connector将数据写入到Kafka
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。