共计 2030 个字符，预计需要花费 6 分钟才能阅读完成。
锁屏面试题百日百刷，每个工作日保持更新面试题。 请看到最初就能获取你想要的, 接下来的是今日的面试题：
1. 解释一下，在数据制作过程中，你如何能从 Kafka 失去精确的信息？**
在数据中，为了准确地取得 Kafka 的音讯，你必须遵循两件事: 在数据耗费期间防止反复，在数据生产过程中防止反复。
这里有两种办法，能够在数据生成时精确地取得一个语义:
每个分区应用一个独自的写入器，每当你发现一个网络谬误，查看该分区中的最初一条音讯，以查看您的最初一次写入是否胜利
在音讯中蕴含一个主键 (UUID 或其余)，并在用户中进行重复制
2. 解释如何缩小 ISR 中的扰动？broker 什么时候来到 ISR？**
ISR 是一组与 leaders 齐全同步的音讯正本，也就是说 ISR 中蕴含了所有提交的音讯。ISR 应该总是蕴含所有的正本，直到呈现真正的故障。如果一个正本从 leader 中脱离进去，将会从 ISR 中删除。
3.Kafka 为什么须要复制？**
Kafka 的信息复制确保了任何已公布的音讯不会失落，并且能够在机器谬误、程序谬误或更常见些的软件降级中应用。
4. 如果正本在 ISR 中停留了很长时间表明什么？**
如果一个正本在 ISR 中保留了很长一段时间，那么它就表明，跟踪器无奈像在 leader 收集数据那样疾速地获取数据。
5. 请阐明如果首选的正本不在 ISR 中会产生什么？**
如果首选的正本不在 ISR 中，控制器将无奈将 leadership 转移到首选的正本。
6.Kafka 有可能在生产后产生音讯偏移吗？**
在大多数队列零碎中，作为生产者的类无奈做到这一点，它的作用是触发并遗记音讯。broker 将实现剩下的工作，比方应用 id 进行适当的元数据处理、偏移量等。
作为音讯的用户，你能够从 Kafka broker 中取得弥补。如果你凝视 SimpleConsumer 类，你会留神到它会获取包含偏移量作为列表的 MultiFetchResponse 对象。此外，当你对 Kafka 音讯进行迭代时，你会领有包含偏移量和音讯发送的 MessageAndOffset 对象。
7. 请阐明 Kafka 的音讯投递保障（delivery guarantee）机制以及如何实现？**
Kafka 反对三种音讯投递语义：
① At most once 音讯可能会丢，但绝不会反复传递
② At least one 音讯绝不会丢，但可能会反复传递
③ Exactly once 每条音讯必定会被传输一次且仅传输一次，很多时候这是用户想要的
consumer 在从 broker 读取音讯后，能够抉择 commit，该操作会在 Zookeeper 中存下该 consumer 在该 partition 下读取的音讯的 offset，该 consumer 下一次再读该 partition 时会从下一条开始读取。如未 commit，下一次读取的开始地位会跟上一次 commit 之后的开始地位雷同。
能够将 consumer 设置为 autocommit，即 consumer 一旦读到数据立刻主动 commit。如果只探讨这一读取音讯的过程，那 Kafka 是确保了 Exactly once。但实际上理论应用中 consumer 并非读取完数据就完结了，而是要进行进一步解决，而数据处理与 commit 的程序在很大水平上决定了音讯从 broker 和 consumer 的 delivery guarantee semantic。
·读完音讯先 commit 再解决音讯。这种模式下，如果 consumer 在 commit 后还没来得及解决音讯就 crash 了，下次从新开始工作后就无奈读到刚刚已提交而未解决的音讯，这就对应于 At most once。
·读完音讯先解决再 commit 生产状态 (保留 offset)。这种模式下，如果在解决完音讯之后 commit 之前 Consumer crash 了，下次从新开始工作时还会解决刚刚未 commit 的音讯，实际上该音讯曾经被解决过了，这就对应于 At least once。
·如果肯定要做到 Exactly once，就须要协调 offset 和实际操作的输入。经典的做法是引入两阶段提交，但因为许多输入零碎不反对两阶段提交，更为通用的形式是将 offset 和操作输出存在同一个中央。比方，consumer 拿到数据后可能把数据放到 HDFS，如果把最新的 offset 和数据自身一起写到 HDFS，那就能够保证数据的输入和 offset 的更新要么都实现，要么都不实现，间接实现 Exactly once。（目前就 high level API 而言，offset 是存于 Zookeeper 中的，
无奈存于 HDFS，而 low level API 的 offset 是由本人去保护的，能够将之存于 HDFS 中）。
总之，Kafka 默认保障 At least once，并且容许通过设置 producer 异步提交来实现 At most once，而 Exactly once 要求与指标存储系统合作，Kafka 提供的 offset 能够较为容易地实现这种形式。
全部内容在 git 上, 理解更多请点我头像或到我的主页去取得，谢谢 **
