kafka组件(角色)介绍_结合官网、教材和实践

程序干货王

已于 2023-04-02 11:38:04 修改

阅读量657

点赞数

分类专栏： kafka 大数据文章标签： kafka 分布式

于 2023-04-02 11:33:36 首次发布

本文链接：https://blog.csdn.net/manformer/article/details/129850194

版权

大数据同时被 2 个专栏收录

4 篇文章 0 订阅

订阅专栏

kafka

2 篇文章 0 订阅

订阅专栏

kafka中有很多重要的组件，下面将一一介绍它们的功能以及它们内在的关系。

在文章中，可能会混用中英文来说明，英语中文对照表如下:

Component Name	中文名称
Producer	生产者
Consumer	消费者
Consumer	消费者组
Topic	主题
Partition	分区
Replica	副本
Offset	偏移量

一、Producer

定义：消息生产者，可以发布消息到kafka集群的终端或者服务

一般情况下，一个消息会被发布到一个特定的主题上。

生产者在默认情况下把消息均衡的分布到主题的所有分区上，而并不关心特定消息会被写到那个分区。生产者也可以把消息直接写到指定分区。这通常是通过消息key和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。

二、Consumer

消费者读取消息。消费者可以订阅一个或多个主题，并按照消息生成的顺序读取。消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka会把它添加到消息里。在给定的分区中，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在Zookeeper或者Kafka上，如果消费者关闭或重启，它的读取状态不会丢失。

消费者是消费者组的一部分，也就是说，会有一个或多个消费者共同读取一个主题。群组保证每个分区只能被一个消费者使用。

如图所示，有3个消费者同时读取一个主题，其中的两个消费者各自读取一个分区，另外一个消费者读取其他两个分区。消费者与分区之间的映射通常被称为消费者对分区的所有权关系。

通过这种方式，消费者可以消费包含大量消息的主题。而且，如果一个消费者失效，群组里的其他消费者可以接管失效消费者的工作。

三、Consumer Group

消费者可以消费Kafka Topic的消息，而消费者组可以实现单播与广播的功能；每条消息只能被消费者组中的一个消费者消费，但可以被多个消费者组消费。

原因：假设我们有一个应用程序需要从一个Kafka Topic中读取消息并验证，然后再把它们保存起来。应用程序需要创建一个消费者对象，订阅Topic 并开始接收消息，然后验证消息并保存结果。过了一阵，生产者往Topic写入消息的速度超过了应用程序验证数据的速度，这时候怎么办？如果只使用单个消费者处理消息，应用程序会远远跟不上消息生成的速度。显然，此时很有必要对消费者进行横向伸缩。就像多个生产者可以向相同的分区写入消息一样，我们也可以使用多个消费者从一个主题读取消息，对消息进行分流。

Kafka消费者从属于消费者组，一个群组里的消费者订阅的时同一个主题，每个消费者接收主题一部分分区的消息。

假设主题T1 有4个Partition，我们创建了消费者C1，它是群组G1里唯一的消费者，我们用它订阅主题T1。消费者C1将收到主题T1全部四个分区的消息。

如果在群组G1里新增一个消费者C2，那么每个消费者将分别从两个分区接收消息。假设消费者C1接收分区0和2的消息，消费者C2接收分区1和3的消息。

如果群组G1有4个消费者，那么每个消费者可以分配到一个分区。

如果群组G1中，再添加更多的消费者，超过主题的分区数量，那么有一部分消费者就会闲置，不会接收到任何消息。

往群组里增加消费者是横向伸缩消费能力的主要方式。Kafka消费者会经常做一些高延迟的操作，比如把数据写到数据库或者HDFS，或者使用数据进行比较耗时的计算。在这些情况下，单个消费者无法跟上数据生成的速度，所以可以增加更多的消费者，让它们分担负载，每个消费者只处理部分分区的消息，这就是横向伸缩的主要手段。

四、Broker

定义：一个独立的Kafka服务器被称为Broker，多个Broker可以组成一个Kafka集群。

Broker接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。Broker为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个Broker可以轻松处理数千个分区以及每秒百万级的消息量。

如果某个Topic有n个Partition而且集群有n个Broker，那么每个Broker会存储该Topic的一个Partition。

如果某个Topic有n个Paritition而且集群有(n+m)个Broker，那么其中只有n个Broker会存储该Topic中的一个Partition。

如果某个Topic有n个Partition而且集群中Broker数量小于n，那么一个Broker会存储该Topic的一个或多个Partition。但是我们在日常的工作中，要尽量避免这种情况发生，很容易导致Kafka集群发生数据倾斜。

五、Topic

Kafka的消息是通过主题进行分类，kafka是面向Topic的，主题就好比数据库的表，或者文件系统里的文件夹。主题可以被分为若干个分区，一个分区就是一个提交日志。消息以追加的方式写入分区，然后以先入先出（FIFO）的顺序读取。

要注意，由于一个主题一般包含几个分区，因此无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。

假如主题有四个分区，消息被追加写入到每个分区的尾部。Kafka通过分区来实现数据冗余和伸缩性。分区可以分布在不同的服务器上，也就是说，一个主题可以横跨多个服务器，以此来提供比单个服务器更强大的性能。

六、Partition

Partition是Topic在Kafka集群物理机上的分区，一个Topic中的数据可以分到多个Partition中，每个Partition是一个有序的不可变的记录序列。分区中每条记录都有一个顺序ID号作为它的offset，它唯一的标识分区中的每个记录。

同一个Topic中的分区可以分配在不同的机器上，以此实现Kafka的伸缩性，单一分区中的数据有序，但无法保证全局（同一Topic中的所有分区）有序。

七、Replica

复制功能是Kafka架构的核心。在Kafka的文档里，Kafka把自己描述成“一个分布式的、可分区的、可复制的提交日志服务”。复制之所以这么关键，是因为它可以在个别节点失效时仍能保证Kafka的可用性和持久型。

Kafka使用主题来组织数据，每个主题被划分成若干个分区，每个分区有多个副本。那些副本被保存在broker上，每个broker可以保存成百上千个属于不同主题和分区的副本。

副本主要分为首领（Leader）副本和跟随者（Follower）副本。

八、Leader

每个分区都有一个Leader。为了保证一致性，所有生产者请求和消费者请求都会经过这个副本。

九、Follower

Leader以外的副本都是Follower副本，Follower副本不处理来自客户端的请求，它们唯一的任务就是从Leader那里复制消息，保持与Leader一致的状态。如果Leader发生崩溃，其中一个Follower会被提升为新Leader。

Follower紧跟Leader，所有写请求都通过Leader路由，数据变更会广播给所有的Follower，Follower与Leader保持数据同步。如果Leader挂了，则从ISR队列中选举出一个Follower作为新的Leader。当Follower与Leader同步落后太多，Leader会把这个Follower从ISR（in sync replicas）队列中删除。

十、Controller

控制器其实就是Kafka集群中的一个Broker，用来进行Leader选举以及各种Failover操作。

Controller的选举：

在集群里第一个启动的Broker通过在Zookeeper里创建一个临时节点/Controller让自己成为控制器。其他Broker在启动时会尝试创建这个节点，不过它们会收到一个“节点”已存在的异常，然后“意识”到控制节点已经存在，其他Broker就会在控制器节点上创建Zookeeper watch对象，这样它们就可以收到这个节点的变更通知。这种方式可以确保集群里有且只有一个控制器存在。

如果控制器被关闭或者与Zookeeper断开连接，Zookeeper上的临时节点就会消失。集群里的其他Broker通过Watch对象得到控制器节点消失的通知，它们会尝试让自己成为新的控制器。第一个在Zookeeper里创建控制器节点的Broker就会成为新的控制器，其他节点会收到“节点已存在”的异常，然后在新的控制器节点上再次创建watch对象。每个新选出的控制器通过Zookeeper的条件递增操作获得一个全新的、数值更大的Controller epoch。其他Broker在知道当前Controller epoch后，如果收到由控制器发出的包含较旧的epoch的消息，就会忽略它们。