开篇介绍

大家好，我是Java最全面试题库的提裤姐，明天这篇是中间件面试题系列的第三篇，次要总结了Kafka相干的面试题；在后续，会沿着第一篇开篇的常识线路始终总结上来，做到日更！如果我能做到百日百更，心愿你也能够跟着百日百刷，一百天养成一个好习惯。

Kafka中的ISR、AR代表什么？ISR的伸缩指什么？

  • ISR：In-Sync Replicas 正本同步队列
  • AR:Assigned Replicas 所有正本

ISR是由leader保护，follower从leader同步数据有一些提早（包含延迟时间replica.lag.time.max.ms和提早条数replica.lag.max.messages两个维度，以后最新的版本0.10.x中只反对replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR，存入OSR（Outof-Sync Replicas）列表，新退出的follower也会先寄存在OSR中。

AR=ISR+OSR。

kafka中的broker 是干什么的？

broker 是音讯的代理，
Producers往Brokers外面的指定Topic中写音讯，Consumers从Brokers外面拉取指定Topic的音讯，而后进行业务解决，broker在两头起到一个代理保留音讯的中转站。

kafka中的 zookeeper 起到什么作用？

zookeeper 是一个分布式的协调组件，晚期版本的kafka用zk做meta信息存储，consumer的生产状态，group的治理以及 offset的值。
思考到zk自身的一些因素以及整个架构较大概率存在单点问题，新版本中逐步弱化了zookeeper的作用。新的consumer应用了kafka外部的group coordination协定，也缩小了对zookeeper的依赖。

kafka follower如何与leader同步数据?

Kafka的复制机制既不是齐全的同步复制，也不是单纯的异步复制。
齐全同步复制要求All Alive Follower都复制完，这条音讯才会被认为commit，这种复制形式极大的影响了吞吐率。
异步复制形式下，Follower异步的从Leader复制数据，数据只有被Leader写入log就被认为曾经commit，这种状况下，如果leader挂掉，会失落数据；
kafka应用ISR的形式很好的平衡了确保数据不失落以及吞吐率。Follower能够批量的从Leader复制数据，而且Leader充分利用磁盘程序读以及send file(zero copy)机制，这样极大的进步复制性能，外部批量写磁盘，大幅缩小了Follower与Leader的音讯量差。

kafka 为什么那么快？

  • Cache Filesystem Cache PageCache缓存
  • 程序写：因为古代的操作系统提供了预读和写技术，磁盘的程序写大多数状况下比随机写内存还要快。
  • Zero-copy：零拷技术缩小拷贝次数
  • Batching of Messages：批量量解决。合并小的申请，而后以流的形式进行交互，直顶网络下限。
  • Pull 拉模式：应用拉模式进行音讯的获取生产，与生产端解决能力相符。

kafka producer如何优化打入速度？

  • 减少线程
  • 进步 batch.size
  • 减少更多 producer 实例
  • 减少 partition 数
  • 设置 acks=-1 时，如果提早增大：能够增大 num.replica.fetchers（follower 同步数据的线程数）来调解；
  • 跨数据中心的传输：减少 socket 缓冲区设置以及 OS tcp 缓冲区设置。

kafka producer发送数据，ack为0，1，-1别离是什么意思？

  • 1（默认） 数据发送到Kafka后，通过leader胜利接管音讯的的确认，就算是发送胜利了。在这种状况下，如果leader宕机了，则会失落数据。
  • 0 生产者将数据发送进来就不论了，不去期待任何返回。这种状况下数据传输效率最高，然而数据可靠性确是最低的。
  • -1producer须要期待ISR中的所有follower都确认接管到数据后才算一次发送实现，可靠性最高。当ISR中所有Replica都向Leader发送ACK时，leader才commit，这时候producer能力认为一个申请中的音讯都commit了。

kafka的message格局是什么样的？

一个Kafka的Message由一个固定长度的header和一个变长的音讯体body组成

  • header局部由一个字节的magic(文件格式)和四个字节的CRC32(用于判断body音讯体是否失常)形成。

当magic的值为1的时候，会在magic和crc32之间多一个字节的数据：attributes(保留一些相干属性，
比方是否压缩、压缩格局等等);如果magic的值为0，那么不存在attributes属性

  • body是由N个字节形成的一个音讯体，蕴含了具体的key/value音讯

kafka中consumer group 是什么概念？

同样是逻辑上的概念，是Kafka实现单播和播送两种音讯模型的伎俩。
同一个topic的数据，会播送给不同的group；
同一个group中的worker，只有一个worker能拿到这个数据。
换句话说，对于同一个topic，每个group都能够拿到同样的所有数据，然而数据进入group后只能被其中的一个worker生产。group内的worker能够应用多线程或多过程来实现，也能够将过程扩散在多台机器上，worker的数量通常不超过partition的数量，且二者最好放弃整数倍关系，因为Kafka在设计时假设了一个partition只能被一个worker生产（同一group内）。

Kafka中的音讯是否会失落和反复生产？

音讯发送
Kafka音讯发送有两种形式：同步（sync）和异步（async），
默认是同步形式，可通过producer.type属性进行配置。
Kafka通过配置request.required.acks属性来确认音讯的生产

  • 0---示意不进行音讯接管是否胜利的确认；
  • 1---示意当Leader接管胜利时确认；
  • -1---示意Leader和Follower都接管胜利时确认；

综上所述，有6种音讯生产的状况，音讯失落的场景：

  • acks=0，不和Kafka集群进行音讯接管确认，则当网络异样、缓冲区满了等状况时，音讯可能失落；
  • acks=1、同步模式下，只有Leader确认接管胜利后但挂掉了，正本没有同步，数据可能失落；

音讯生产
Kafka音讯生产有两个consumer接口，Low-level API和High-level API：

  • Low-level API：消费者本人保护offset等值，能够实现对Kafka的齐全管制；
  • High-level API：封装了对parition和offset的治理，应用简略；

如果应用高级接口High-level API，可能存在一个问题就是当音讯消费者从集群中把音讯取出来、并提交了新的音讯offset值后，还没来得及生产就挂掉了，那么下次再生产时之前没生产胜利的音讯就“诡异”的隐没了；

解决办法：
针对音讯失落：同步模式下，确认机制设置为-1，即让音讯写入Leader和Follower之后再确认音讯发送胜利；异步模式下，为避免缓冲区满，能够在配置文件设置不限度阻塞超时工夫，当缓冲区满时让生产者始终处于阻塞状态；

针对音讯反复：将音讯的惟一标识保留到内部介质中，每次生产时判断是否解决过即可。

为什么Kafka不反对读写拆散？

在 Kafka 中，生产者写入音讯、消费者读取音讯的操作都是与 leader 正本进行交互的，从 而实现的是一种主写主读的生产生产模型。

Kafka 并不反对主写从读，因为主写从读有 2 个很明 显的毛病:

  • 数据一致性问题。数据从主节点转到从节点必然会有一个延时的工夫窗口，这个工夫 窗口会导致主从节点之间的数据不统一。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值批改为 Y，那么在这个变更告诉到从节点之前，利用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不统一的问题。
  • 延时问题。相似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程须要经验网络→主节点内存→网络→从节点内存这几个阶段，整个过程会消耗肯定的工夫。而在 Kafka 中，主从同步会比 Redis 更加耗时，它须要经验网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘这几个阶段。对延时敏感的利用而言，主写从读的性能并不太实用。