Kafka-核心概念

最新推荐文章于 2024-04-27 16:44:53 发布

Andy技术支援

最新推荐文章于 2024-04-27 16:44:53 发布

阅读量1.2k

点赞数 22

分类专栏：队列文章标签： kafka 分布式

本文链接：https://blog.csdn.net/zhuyufan1986/article/details/135627268

版权

队列专栏收录该内容

27 篇文章 0 订阅

订阅专栏

消息

消息是Kafka中最基本的数据单元。

消息由一串字节构成，其中主要由key和value构成，key和value也都是byte数组。

key的主要作用是根据一定的策略，将此消息路由到指定的分区中，这样就可以保证包含同一key的消息全部写入同一分区中，key可以是null。

消息的真正有效负载是value部分的数据。

为了提高网络和存储的利用率，生产者会批量发送消息到Kafka,并在发送之前对消息进行压缩。

Topic&分区&Log

Topic是用于存储消息的逻辑概念，可以看作一个消息集合。

每个Topic可以有多个生产者向其中推送(push)消息，也可以有任意多个消费者消费其中的消息。

在这里插入图片描述
每个Topic可以划分成多个分区(每个Topic都至少有一个分区),同一Topic下的不同分区包含的消息是不同的。

每个消息在被添加到分区时，都会被分配一个offset,它是消息在此分区中的唯一编号，Kafka通过offset保证消息在分区内的顺序，offset的顺序性不跨分区，即Kafka只保证在同一个分区内的消息是有序的；

同一Topic的多个分区内的消息，Kafka并不保证其顺序性。

在这里插入图片描述
同一Topic的不同分区会分配在不同的Broker(Broker的概念见下文)上。

分区是Kafka水平扩展性的基础，我们可以通过增加服务器并在其上分配Partition的方式来增加Kafka的并行处理能力。

分区在逻辑上对应着一个Log,当生产者将消息写入分区时，实际上是写入到了分区对应的Log中。

Log是一个逻辑概念，可以对应到磁盘上的一个文件夹。

Log由多个Segment组成，每个Segment对应一个日志文件和索引文件。

在面对海量数据时，为避免出现超大文件，每个日志文件的大小是有限制的，当超出限制后则会创建新的Segment,继续对外提供服务。

这里要注意，因为Kafka采用顺序VO,所以只向最新的Segment追加数据。

为了权衡文件大小、索引速度、占用内存大小等多方面因素，索引文件采用稀疏索引的方式，大小并不会很大，在运行时会将其内容映射到内存，提高索引速度。

保留策略(Retention Policy)&日志压缩(Log Compaction)

无论消费者是否已经消费了消息，Kafka都会一直保存这些消息，但并不会像数据库那样长期保存。

为了避免磁盘被占满，Kafka会配置相应的“保留策略”(retentionpolicy),以实现周期性地删除陈旧的消息。

Kafka中有两种“保留策略”:

一种是根据消息保留的时间，当消息在Kafka中保存的时间超过了指定时间，就可以被删除；

另一种是根据Topic存储的数据大小，当Topic所占的日志文件大小大于一个阈值，则可以开始删除最旧的消息。

Kafka会启动一个后台线程，定期检查是否存在可以删除的消息。

“保留策略”的配置是非常灵活的，可以有全局的配置，也可以针对Topic进行配置覆盖全局配置。

除此之外，Kafka还会进行“日志压缩”(Log Compaction)。

在很多场景中，消息的key与value的值之间的对应关系是不断变化的，就像数据库中的数据会不断被修改一样，消费者只关心key对应的最新value值。

此时，可以开启Kafka的日志压缩功能，Kafka会在后台启动一个线程，定期将相同key的消息进行合并，只保留最新的value值。

日志压缩的工作原理如图所示，图展示了一次日志压缩过程的简化版本，为了图片清晰，只展示了key3的压缩过程。

在这里插入图片描述

Broker

一个单独的Kafka server就是一个Broker。

Broker的主要工作就是接收生产者发过来的消息，分配offset,之后保存到磁盘中；

同时，接收消费者、其他Broker的请求，根据请求类型进行相应处理并返回响应。

在一般的生产环境中，一个Broker独占一台物理服务器。

副本

Kafka对消息进行了冗余备份，每个Partition可以有多个副本，每个副本中包含的消息是一样的(在同一时刻，副本之间其实并不是完全一样的，本书后面在介绍副本机制的时候会再进行说明)。

每个分区至少有一个副本，当分区中只有一个副本时，就只有Leader副本，没有Follower副本。

每个分区的副本集合中，都会选举出一个副本作为Leader副本，Kafka在不同的场景下会采用不同的选举策略。

所有的读写请求都由选举出的Leader副本处理，其他都作为Follower副本，Follower副本仅仅是从Leader副本处把数据拉取到本地之后，同步更新到自己的Log中。下图展示了一个拥有三个Replica的Partition。

在这里插入图片描述
一般情况下，同一分区的多个分区会被分配到不同的Broker上，这样，当Leader所在的Broker宕机之后，可以重新选举新的Leader,继续对外提供服务。

ISR集合

ISR(In-Sync Replica)集合表示的是目前“可用”(alive)且消息量与Leader相差不多的副本集合，这是整个副本集合的一个子集。“可用”和“相差不多”都是很模糊的描述，其实际含义是ISR集合中的副本必须满足下面两个条件：

副本所在节点必须维持着与ZooKeeper的连接。
副本最后一条消息的offset与Leader副本的最后一条消息的offset之间的差值不能超出指定的阈值。

每个分区中的Leader副本都会维护此分区的ISR集合。

写请求首先由Leader副本处理，之后Follower副本会从Leader上拉取写入的消息，这个过程会有一定的延迟，导致Follower副本中保存的消息略少于Leader副本，只要未超出阈值都是可以容忍的。

如果一个Follower副本出现异常，比如：宕机，发生长时间GC而导致Kafka僵死或是网络断开连接导致长时间没有拉取消息进行同步，就会违反上面的两个条件，从而被Leader副本踢出ISR集合。

当Follower副本从异常中恢复之后，会继续与Leader副本进行同步，当Follower副本“追上”(即最后一条消息的offset的差值小于指定阈值)Leader副本的时候，此Follower副本会被Leader副本重新加入到ISR中。

HW&LEO

HW(HighWatermark)和LEO与上面的ISR集合紧密相关。HW标记了一个特殊的offset,当消费者处理消息的时候，只能拉取到HW之前的消息，HW之后的消息对消费者来说是不可见的。

与ISR集合类似，HW也是由Leader副本管理的。

当ISR集合中全部的Follower副本都拉取HW指定消息进行同步后，Leader副本会递增HW的值。

Kafka官方网站将HW之前的消息的状态称为“commit”,其含义是这些消息在多个副本中同时存在，即使此时Leader副本损坏，也不会出现数据丢失。

下面通过一个示例进行分析，图中展示了针对offset为11的消息，ISR集合、HW与LEO是如何协调工作的：

Producer向此Partition推送消息。
Leader副本将消息追加到Log中，并递增其LEO。
Follower副本从Leader副本拉取消息进行同步。
Follower副本将拉取到的消息更新到本地Log中，并递增其LEO。
当ISR集合中所有副本都完成了对offset=11的消息的同步，Leader副本会递增HW。
在1～5步完成之后，offset=11的消息就对生产者可见了。

在这里插入图片描述
为什么Kafka要这么设计?在分布式存储中，冗余备份是常见的一种设计，常用的方案有同步复制和异步复制：

同步复制要求所有能工作的Follower副本都复制完，这条消息才会被认为提交成功。一旦有一个Follower副本出现故障，就会导致HW无法完成递增，消息就无法提交，生产者获取不到消息。这种情况下，故障的Follower副本会拖慢整个系统的性能，甚至导致整个系统不可用。
异步复制中，Leader副本收到生产者推送的消息后，就认为此消息提交成功。Follower副本则异步地从Leader副本同步消息。这种设计虽然避免了同步复制的问题，但同样也存在一定的风险。现在假设所有Follower副本的同步速度都比较慢，它们保存的消息量都远远落后于Leader副本，如图所示。

此时Leader副本所在的Broker突然宕机，则会重新选举新的Leader副本，而新Leader副本中没有原来Leader副本的消息，这就出现了消息的丢失，而有些消费者则可能消费了这些丢失的消息，状态变得不可控。