Kafka架构

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同步

保证了数据的一致性。