关于java:持续输出面试题之Kafka篇

开篇介绍

大家好，我是 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 更加耗时，它须要经验 网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘 这几个阶段。对延时敏感的利用而言，主写从读的性能并不太实用。