Kafka架构

    技术2026-02-18  12

    1、概述

    Kafka中消息是以topic进行分类的,生产者生产消息,消费者消费消息,都是面向topic的。

    基础架构

    (1)Producer :消息生产者,就是向kafka broker发消息的客户端;

    (2)Consumer :消息消费者,向kafka broker取消息的客户端;

    (3)Consumer Group (CG):消费者组,由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据,一个分区只能由一个消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。

    (4)Broker :一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

    (5)Topic :可以理解为一个队列,生产者和消费者面向的都是一个topic;

    (6)Partition:为了实现扩展性,一个非常大的topic可以分布到多个broker(即服务器)上,一个topic可以分为多个partition,每个partition是一个有序的队列;

    (7)Replica:副本,为保证集群中的某个节点发生故障时,该节点上的partition数据不丢失,且kafka仍然能够继续工作,kafka提供了副本机制,一个topic的每个分区都有若干个副本,一个leader和若干个follower。

    (8)leader:每个分区多个副本的“主”,生产者发送数据的对象,以及消费者消费数据的对象都是leader。

    (9)follower:每个分区多个副本中的“从”,实时从leader中同步数据,保持和leader数据的同步。leader发生故障时,某个follower会成为新的follower。


    2、存储结构

    topic是逻辑上的概念,而partition是物理上的概念。

    每个partition对应于一个log文件,该log文件中存储的就是producer生产的数据。

    生产者生产的消息会不断追加到log文件末尾,为防止log文件过大导致数据定位效率低下,Kafka采取了分片索引机制,将每个partition分为多个segment。

    每个segment对应两个文件——“.index”文件和“.log”文件。这些文件位于一个文件夹下,该文件夹的命名规则为:topic名称+分区序号。

    例如,first这个topic有三个分区,则其对应的文件夹为first-0,first-1,first-2。

    3、分区

    3.1 分区原因

    方便扩展、提高并发读写

    3.2 分区策略

    producer发送的数据会封装成一个ProducerRecord对象

    (1)指明 partition 的情况下,直接将指明的值直接作为 partiton 值;

    (2)没有指明 partition 值但有 key 的情况下,将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值;

    (3)既没有 partition 值又没有 key 值的情况下,第一次调用时随机生成一个整数(后面每次调用在这个整数上自增),将这个值与 topic 可用的 partition 总数取余得到 partition 值,也就是常说的 round-robin 算法。

    3.3 数据可靠性的实现原理(面试重点)

    1、如何确定数据的可靠性

    通过确认应答机制

    2、什么时候发送应答?

    副本与leader同步后再发送应答

    3、多少个副本同步后再发送应答?

    现有方案两个:

    ①半数以上follower同步完成以后发送ack(延迟低、容忍度2n+1)


    关于半数机制

    半数机制是为了防止脑裂

    只有在半数以上的follower同步完成,才能保证参与投票的半数以上的follower里至少有一个同步完成的。

    关于容忍度

    在容忍n台故障的情况下,需要多少个副本。


    ②所有follower同步完成以后发送ack(kafak选择的方案)(延迟高、容忍度n+1

    4、若有一个follower一直未同步完成,那么leader会一直等下去吗?

    不会。

    Leader维护了一个动态的in-sync replica set (ISR),意为和leader保持同步的follower集合。

    ISR中的follower完成数据的同步之后,leader就会给follower发送ack

    如果follower长时间未向leader同步数据,则该follower将被踢出ISR。

    该时间阈值由replica.lag.time.max.ms参数设定。

    Leader发生故障之后,就会从ISR中选举新的leader

    3.4 ack应答机制

    对于某些不太重要的数据,对数据的可靠性要求不是很高,能够容忍数据的少量丢失,所以没必要等ISR中的follower全部接收成功。

    所以Kafka为用户提供了三种可靠性级别,用户根据对可靠性和延迟的要求进行权衡,选择以下的配置。

    acks参数配置:

    acks:

    0:producer不等待broker的ack。

    可能会丢失数据

    1:producer等待broker的ack,partition的leader落盘成功后返回ack。

    可能会丢失数据,若leader刚落盘成功,挂了,则选举新leader,数据丢失。

    -1:producer等待broker的ack,partition的leader和follower全部落盘成功后才返回ack。

    可能会重复数据,若leader落盘成功,同步成功,挂了,此数据无应答,会有重复数据。

    3.5 故障处理细节(一致性的实现)

    Follower故障,踢出ISR之后再次同步时,会将HW之后的数据截掉,从HW开始向Leader同步

    Leader故障,选取新的Leader,所有follower截取HW后的数据,从HW开始向Leader同步

    保证了数据的一致性。

    Processed: 0.020, SQL: 9