kafka面经

Kafka回顾–2023-3-14

消费者组：由多个消费者组成，消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费，消费者组之间互不影响，所有的消费者者都属于某个消费者组
分区：一个topic可以分布到多个服务器上，一个topic可以分为多个partition
副本：一个topic的每个分区都有若干个副本、一个Leader（副本的主）和若干个Follower
生产者发送原理：涉及两个线程，main和sender，在main中创建了一个双端队列（RecordAccumulator）。main线程中经过拦截器、序列化器和分区器，将数据发送给RecordAccumulator，默认大小32M，其中包含了多个队列（producerbatch默认16k）。Sender线程会不断从RecordAccumulator中拉去消息发送到kaafka集群，其中kafka集群会返回应答消息acks（0，1，-1），0表示生产者发送过来的数据，不需要等待数据落盘，发送到kafka集群就返回。1表示生产者发送过来的数据，Lender收到数据后应答。-1表示生产者发送过来的数据，Leader和SR对流所有的系欸但收齐数据以后应答。

生产者分区的好处：

便于合理使用存储资源，每个partition在一个broker(服务器)上存储，可以把含量的数据按照分区切割成一块一块数据存储在多平台上，合理控制分区的任务，可以实现负载均衡

• 提高并行度：生产者可以以分区为单位发送数据，消费者可以以分区为单位进行数据消费
  生产者分区器分区原则：
• 指明partition的情况下，直接将指明的值作为partiion值
• 没有指明partition的情况下，将key的hash值与topic的partition数进行取余得到partition值。例如：key1的hash值=5， key2的hash值=6 ，topic的partition数=2，那
  么key1 对应的value1写入1号分区，key2对应的value2写入0号分区。
• 既没有partition值又没有key值的情况下，Kafka采用Sticky Partition（黏性分区器），会随机选择一个分区，并尽可能一直使用该分区，待该分区的batch已满或者已完成，Kafka再随机一个分区进行使用（和上一次的分区不同）。

生产者如何提高吞吐量：

Batch size:批次大小，默认为16k
Linger ms ：等待时间，修改为 5-100ms
Compression type：压缩数据
RecordAccumulator：修改缓冲区大小，

Leader收到数据，所有Follower都开始同步数据，但有一个Follower，因为某种故障，迟迟不能与Leader进行同步，那这个问题怎么解决呢？
Leader维护了一个动态的in-sync replica set（ISR），意为和Leader保持同步的Follower+Leader集合(leader：0，isr:0,1,2)。如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR。该时间阈值由replica.lag.time.max.ms参数设定，默认30s。例如2超时，(leader:0, isr:0,1)。这样就不用等长期联系不上或者已经故障的节点

数据完全可靠条件：

= ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2

数据去重：
至少一次（At Least Once）= ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2
最多一次（At Most Once）= ACK级别设置为0
At Least Once可以保证数据不丢失，但是不能保证数据不重复；
At Most Once可以保证数据不重复，但是不能保证数据不丢失。
• 精确一次（Exactly Once）：对于一些非常重要的信息，比如和钱相关的数据，要求数据既不能重复也不丢失。

幂等性原理：

就是指producer不论向broker发送多少次重复的数据，broker端都只会持久化一条，保证不了重复

Leader的选举流程：

在isr中存活为前提，按照AR中排在前面的优先。例如ar[1,0,2], isr [1，0，2]，那么leader
就会按照1，0，2的顺序轮询。选举新的Leader（在isr中存活为前提，按照AR中排在前面的优先）

Leader 和 Follower 故障处理细节

LEO（Log End Offset）：每个副本的最后一个offset，LEO其实就是最新的offset + 1。
HW（High Watermark）：所有副本中最小的LEO 。

Leader Partition 负载平衡

在一般的情况下，kafka本身会自动把leader parition均匀分散在各个机器上，来保证每台机器的读吞吐是均匀的。在默认的情况下，一台broker宕机，会把这台机器上的partition一起放到另一台机器上，导致集群过载，负荷不均衡。
leader.imbalance.per.broker.percentage，默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值，控制器会触发leader的平衡。

Kafka的文件存储机制：

Topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是Producer生产的数据。Producer生产的数据会被不断追加到该log文件末端，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment。每个segment包括：“.index”文件、“.log”文件和.timeindex等文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号，

高效读写数据：

1）Kafka 本身是分布式集群，可以采用分区技术，并行度高
2）读数据采用稀疏索引，可以快速定位要消费的数据
3）顺序写磁盘：同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这
与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

零拷贝：

Kafka的数据加工处理操作交由Kafka生产者和Kafka消费者处理。Kafka Broker应用层不关心存储的数据，所以就不用走应用层，传输效率高。
PageCache页缓存：
Kafka重度依赖底层操作系统提供的PageCache功 能。当上层有写操作时，操作系统只是将数据写入PageCache。当读操作发生时，先从PageCache中查找，如果找不到，再去磁盘中读取。实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。

Kafka消费者

Kafka消费者实际上是从kafka集群拉数据（poll），而不是集群把数据推给kafka

消费者组，由多个consumer组成。形成一个消费者组的条件，是所有消费者的groupid相同。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费。消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
生产经验——分区的分配以及再平衡–为了解决消费者消费哪一个分区的数据

Kafka有四种主流的分区分配策略：

Range、RoundRobin、Sticky、CooperativeSticky。（Kafka 默认的分区分配策略就是 Range + CooperativeSticky）
Range：是对同一个topic而言的，首先对同一个topic里面的分区按照序号进行排序，并对消费者按照字母顺序进行排列。通过 partitions数/consumer数 来决定每个消费者应该
消费几个分区。如果除不尽，那么前面几个消费者将会多消费 1 个分区。
注意：如果只是针对 1 个 topic 而言，C0消费者多消费1个分区影响不是很大。但是如果有 N 多个 topic，那么针对每个 topic，消费者 C0都将多消费 1 个分区，topic越多，C0消费的分区会比其他消费者明显多消费 N 个分区。容易产生数据倾斜
RoundRobin：针对集群中所有Topic而言。RoundRobin 轮询分区策略，是把所有的 partition 和所有的consumer 都列出来，然后按照 hashcode 进行排序，最后通过轮询算法来分配 partition 给到各个消费者
Sticky ：首先会尽量均衡的放置分区到消费者上面，在出现同一消费者组内消费者出现问题的时候，会尽量保持原有分配的分区不变化