关于kafka:三天吃透Kafka面试八股文

本文曾经收录到 Github 仓库，该仓库蕴含 计算机根底、Java 根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享 等外围知识点，欢送 star~

Github 地址：https://github.com/Tyson0314/Java-learning

Kafka 都有哪些特点？

• 高吞吐量、低提早：kafka 每秒能够解决几十万条音讯，它的提早最低只有几毫秒，每个 topic 能够分多个 partition, consumer group 对 partition 进行 consume 操作。
• 可扩展性：kafka 集群反对热扩大
• 持久性、可靠性：音讯被长久化到本地磁盘，并且反对数据备份避免数据失落
• 容错性：容许集群中节点失败（若正本数量为 n, 则容许 n - 1 个节点失败）
• 高并发：反对数千个客户端同时读写

请简述下你在哪些场景下会抉择 Kafka？

• 日志收集：一个公司能够用 Kafka 能够收集各种服务的 log，通过 kafka 以对立接口服务的形式凋谢给各种 consumer，例如 hadoop、HBase、Solr 等。
• 音讯零碎：解耦和生产者和消费者、缓存音讯等。
• 用户流动跟踪：Kafka 常常被用来记录 web 用户或者 app 用户的各种流动，如浏览网页、搜寻、点击等流动，这些流动信息被各个服务器公布到 kafka 的 topic 中，而后订阅者通过订阅这些 topic 来做实时的监控剖析，或者装载到 hadoop、数据仓库中做离线剖析和开掘。
• 经营指标：Kafka 也常常用来记录经营监控数据。包含收集各种分布式应用的数据，生产各种操作的集中反馈，比方报警和报告。
• 流式解决：比方 spark streaming 和 Flink

Kafka 的设计架构你晓得吗？

Kafka 架构分为以下几个局部：

• Producer：音讯生产者，就是向 kafka broker 发消息的客户端。
• Consumer：音讯消费者，向 kafka broker 取音讯的客户端。
• Topic：能够了解为一个队列，一个 Topic 又分为一个或多个分区，
• Consumer Group：这是 kafka 用来实现一个 topic 音讯的播送（发给所有的 consumer）和单播（发给任意一个 consumer）的伎俩。一个 topic 能够有多个 Consumer Group。
• Broker：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 能够包容多个 topic。
• Partition：为了实现扩展性，一个十分大的 topic 能够散布到多个 broker 上，每个 partition 是一个有序的队列。partition 中的每条音讯都会被调配一个有序的 id（offset）。将音讯发给 consumer，kafka 只保障按一个 partition 中的音讯的程序，不保障一个 topic 的整体（多个 partition 间）的程序。
• Offset：kafka 的存储文件都是依照 offset.kafka 来命名，用 offset 做名字的益处是不便查找。例如你想找位于 2049 的地位，只有找到 2048.kafka 的文件即可。当然 the first offset 就是 00000000000.kafka。

Kafka 分区的目标？

分区对于 Kafka 集群的益处是：实现负载平衡。分区对于消费者来说，能够进步并发度，提高效率。

你晓得 Kafka 是如何做到音讯的有序性？

kafka 中的每个 partition 中的音讯在写入时都是有序的，而且独自一个 partition 只能由一个消费者去生产，能够在外面保障音讯的程序性。然而分区之间的音讯是不保障有序的。

Kafka Producer 的执行过程？

1，Producer 生产音讯 –> 2，从 Zookeeper 找到 Partition 的 Leader –> 3，推送音讯 –> 4，通过 ISR 列表告诉给 Follower –> 5，Follower 从 Leader 拉取音讯，并发送 ack –> 6，Leader 收到所有正本的 ack，更新 Offset，并向 Producer 发送 ack，示意音讯写入胜利。

讲一下你应用 Kafka Consumer 生产音讯时的线程模型，为何如此设计？

Thread-Per-Consumer Model，这种多线程模型是利用 Kafka 的 topic 分多个 partition 的机制来实现并行：每个线程都有本人的 consumer 实例，负责生产若干个 partition。各个线程之间是齐全独立的，不波及任何线程同步和通信，所以实现起来非常简单。

请谈一谈 Kafka 数据一致性原理

一致性就是说不论是老的 Leader 还是新选举的 Leader，Consumer 都能读到一样的数据。

假如分区的正本为 3，其中正本 0 是 Leader，正本 1 和正本 2 是 follower，并且在 ISR 列表外面。尽管正本 0 曾经写入了 Message4，然而 Consumer 只能读取到 Message2。因为所有的 ISR 都同步了 Message2，只有 High Water Mark 以上的音讯才反对 Consumer 读取，而 High Water Mark 取决于 ISR 列表外面偏移量最小的分区，对应于上图的正本 2，这个很相似于木桶原理。

这样做的起因是还没有被足够多正本复制的音讯被认为是“不平安”的，如果 Leader 产生解体，另一个正本成为新 Leader，那么这些音讯很可能失落了。如果咱们容许消费者读取这些音讯，可能就会毁坏一致性。试想，一个消费者从以后 Leader（正本 0）读取并解决了 Message4，这个时候 Leader 挂掉了，选举了正本 1 为新的 Leader，这时候另一个消费者再去从新的 Leader 读取音讯，发现这个音讯其实并不存在，这就导致了数据不一致性问题。

当然，引入了 High Water Mark 机制，会导致 Broker 间的音讯复制因为某些起因变慢，那么音讯达到消费者的工夫也会随之变长（因为咱们会先期待音讯复制结束）。延迟时间能够通过参数 replica.lag.time.max.ms 参数配置，它指定了正本在复制音讯时可被容许的最大延迟时间。

ISR、OSR、AR 是什么？

ISR：In-Sync Replicas 正本同步队列

OSR：Out-of-Sync Replicas

AR：Assigned Replicas 所有正本

ISR 是由 leader 保护，follower 从 leader 同步数据有一些提早（具体能够参见 图文理解 Kafka 的正本复制机制），超过相应的阈值会把 follower 剔除出 ISR, 存入 OSR（Out-of-Sync Replicas）列表，新退出的 follower 也会先寄存在 OSR 中。AR=ISR+OSR。

LEO、HW、LSO、LW 等别离代表什么

LEO：是 LogEndOffset 的简称，代表以后日志文件中下一条

HW：水位或水印（watermark）一词，也可称为高水位(high watermark)，通常被用在流式解决畛域（比方 Apache Flink、Apache Spark 等），以表征元素或事件在基于工夫层面上的进度。在 Kafka 中，水位的概念反而与工夫无关，而是与地位信息相干。严格来说，它示意的就是地位信息，即位移（offset）。取 partition 对应的 ISR 中 最小的 LEO 作为 HW，consumer 最多只能生产到 HW 所在的地位上一条信息。

LSO：是 LastStableOffset 的简称，对未实现的事务而言，LSO 的值等于事务中第一条音讯的地位(firstUnstableOffset)，对已实现的事务而言，它的值同 HW 雷同

LW：Low Watermark 低水位, 代表 AR 汇合中最小的 logStartOffset 值。

数据传输的事务有几种？

数据传输的事务定义通常有以下三种级别：

（1）最多一次: 音讯不会被反复发送，最多被传输一次，但也有可能一次不传输
（2）起码一次: 音讯不会被漏发送，起码被传输一次，但也有可能被反复传输.
（3）准确的一次（Exactly once）: 不会漏传输也不会反复传输, 每个音讯都传输被

Kafka 消费者是否能够生产指定分区音讯？

Kafa consumer 生产音讯时，向 broker 收回 fetch 申请去生产特定分区的音讯，consumer 指定音讯在日志中的偏移量（offset），就能够生产从这个地位开始的音讯，customer 领有了 offset 的控制权，能够向后回滚去从新生产之前的音讯，这是很有意义的。

Kafka 音讯是采纳 Pull 模式，还是 Push 模式？

Kafka 最后思考的问题是，customer 应该从 brokes 拉取音讯还是 brokers 将音讯推送到 consumer，也就是 pull 还 push。在这方面，Kafka 遵循了一种大部分音讯零碎独特的传统的设计：producer 将音讯推送到 broker，consumer 从 broker 拉取音讯。

一些音讯零碎比方 Scribe 和 Apache Flume 采纳了 push 模式，将音讯推送到上游的 consumer。这样做有益处也有害处：由 broker 决定音讯推送的速率，对于不同生产速率的 consumer 就不太好解决了。音讯零碎都致力于让 consumer 以最大的速率最疾速的生产音讯，但可怜的是，push 模式下，当 broker 推送的速率远大于 consumer 生产的速率时，consumer 恐怕就要解体了。最终 Kafka 还是选取了传统的 pull 模式。

Pull 模式的另外一个益处是 consumer 能够自主决定是否批量的从 broker 拉取数据。Push 模式必须在不晓得上游 consumer 生产能力和生产策略的状况下决定是立刻推送每条音讯还是缓存之后批量推送。如果为了防止 consumer 解体而采纳较低的推送速率，将可能导致一次只推送较少的音讯而造成节约。Pull 模式下，consumer 就能够依据本人的生产能力去决定这些策略。

Pull 有个毛病是，如果 broker 没有可供生产的音讯，将导致 consumer 一直在循环中轮询，直到新音讯到 t 达。为了防止这点，Kafka 有个参数能够让 consumer 阻塞晓得新音讯达到(当然也能够阻塞晓得音讯的数量达到某个特定的量这样就能够批量发

Kafka 高效文件存储设计特点

Kafka 把 topic 中一个 parition 大文件分成多个小文件段，通过多个小文件段，就容易定期革除或删除曾经生产完文件，缩小磁盘占用。

通过索引信息能够疾速定位 message 和确定 response 的最大大小。

通过 index 元数据全副映射到 memory，能够防止 segment file 的 IO 磁盘操作。

通过索引文件稠密存储，能够大幅升高 index 文件元数据占用空间大小

Kafka 创立 Topic 时如何将分区搁置到不同的 Broker 中

正本因子不能大于 Broker 的个数；

第一个分区（编号为 0）的第一个正本搁置地位是随机从 brokerList 抉择的；

其余分区的第一个正本搁置地位绝对于第 0 个分区顺次往后移。也就是如果咱们有 5 个 Broker，5 个分区，假如第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，顺次类推；

残余的副本相对于第一个正本搁置地位其实是由 nextReplicaShift 决定的，而这个数也是随机产生的

谈一谈 Kafka 的再平衡

在 Kafka 中，当有新消费者退出或者订阅的 topic 数发生变化时，会触发 Rebalance(再平衡：在同一个消费者组当中，分区的所有权从一个消费者转移到另外一个消费者)机制，Rebalance 顾名思义就是从新平衡消费者生产。Rebalance 的过程如下：

第一步：所有成员都向 coordinator 发送申请，申请入组。一旦所有成员都发送了申请，coordinator 会从中抉择一个 consumer 负责 leader 的角色，并把组成员信息以及订阅信息发给 leader。

第二步：leader 开始调配生产计划，指明具体哪个 consumer 负责生产哪些 topic 的哪些 partition。一旦实现调配，leader 会将这个计划发给 coordinator。coordinator 接管到调配计划之后会把计划发给各个 consumer，这样组内的所有成员就都晓得本人应该生产哪些分区了。

所以对于 Rebalance 来说，Coordinator 起着至关重要的作用

Kafka 是如何实现高吞吐率的？

Kafka 是分布式音讯零碎，须要解决海量的音讯，Kafka 的设计是把所有的音讯都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，应用硬盘并没有带来过多的性能损失。kafka 次要应用了以下几个形式实现了超高的吞吐率：

• 程序读写；
• 零拷贝
• 文件分段
• 批量发送
• 数据压缩。

Kafka 毛病？

• 因为是批量发送，数据并非真正的实时；
• 对于 mqtt 协定不反对；
• 不支持物联网传感数据间接接入；
• 仅反对对立分区内音讯有序，无奈实现全局音讯有序；
• 监控不欠缺，须要装置插件；
• 依赖 zookeeper 进行元数据管理；

Kafka 新旧消费者的区别

旧的 Kafka 消费者 API 次要包含：SimpleConsumer（简略消费者）和 ZookeeperConsumerConnectir（高级消费者）。SimpleConsumer 名字看起来是简略消费者，然而其实用起来很不简单，能够应用它从特定的分区和偏移量开始读取音讯。高级消费者和当初新的消费者有点像，有消费者群组，有分区再平衡，不过它应用 ZK 来治理消费者群组，并不具备偏移量和再平衡的可操控性。

当初的消费者同时反对以上两种行为，所以为啥还用旧消费者 API 呢？

Kafka 分区数能够减少或缩小吗？为什么？

咱们能够应用 bin/kafka-topics.sh 命令对 Kafka 减少 Kafka 的分区数据，然而 Kafka 不反对缩小分区数。

Kafka 分区数据不反对缩小是由很多起因的，比方缩小的分区其数据放到哪里去？是删除，还是保留？删除的话，那么这些没生产的音讯不就丢了。如果保留这些音讯如何放到其余分区外面？追加到其余分区前面的话那么就毁坏了 Kafka 单个分区的有序性。如果要保障删除分区数据插入到其余分区保障有序性，那么实现起来逻辑就会非常复杂。

最初给大家分享一个 Github 仓库，下面有大彬整顿的 300 多本经典的计算机书籍 PDF，包含 C 语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构和算法、机器学习、编程人生 等，能够 star 一下，下次找书间接在下面搜寻，仓库继续更新中~

Github 地址：https://github.com/Tyson0314/java-books