锁屏面试题百日百刷，每个工作日保持更新面试题。 请看到最初就能获取你想要的, 接下来的是今日的面试题：
1. 如何保障 Kafka 的音讯有序 **
Kafka 对于音讯的反复、失落、谬误以及程序没有严格的要求。
Kafka 只能保障一个 partition 中的音讯被某个 consumer 生产时是程序的，事实上，从 Topic 角度来说，当有多个 partition 时，音讯依然不是全局有序的。
2.kafka 数据失落问题, 及如何保障 **
1）数据失落:
acks= 1 的时候 (只保障写入 leader 胜利)，如果刚好 leader 挂了。数据会失落。
acks= 0 的时候，应用异步模式的时候，该模式下 kafka 无奈保障音讯，有可能会丢。
2）brocker 如何保障不失落:
acks=all : 所有正本都写入胜利并确认。
retries = 一个正当值。
min.insync.replicas=2 音讯至多要被写入到这么多正本才算胜利。
unclean.leader.election.enable=false 敞开 unclean leader 选举，即不容许非 ISR 中的正本被选举为 leader，以防止数据失落。
3）Consumer 如何保障不失落
如果在音讯解决实现前就提交了 offset，那么就有可能造成数据的失落。
enable.auto.commit=false 敞开主动提交 offset
解决完数据之后手动提交。
3.kafka 的 balance 是怎么做的 **
官网原文
Producers publish data to the topics of their choice. The producer is able to choose which message
to assign to which partition within the topic. This can be done in a round-robin fashion simply to
balance load or it can be done according to some semantic partition function (say based on some
key in the message). More on the use of partitioning in a second. 翻译：
生产者将数据公布到他们抉择的主题。生产者能够抉择在主题中调配哪个分区的音讯。这能够通过循环的形式来实现，只是为了均衡负载，或者能够依据一些语义分区性能（比方音讯中的一些键）来实现。更多对于分区在一秒钟内的应用。
4.kafka 的消费者形式 **
consumer 采纳 pull（拉）模式从 broker 中读取数据。
push（推）模式很难适应生产速率不同的消费者，因为音讯发送速率是由 broker 决定的。它的指标是尽可能以最快速度传递音讯，然而这样很容易造成 consumer 来不及解决音讯，典型的体现就是拒绝服务以及网络拥塞。
而 pull 模式则能够依据 consumer 的生产能力以适当的速率生产音讯。
对于 Kafka 而言，pull 模式更适合，它可简化 broker 的设计，consumer 可自主管制生产音讯的速率，同时 consumer 能够本人管制生产形式——即可批量生产也可逐条生产，同时还能抉择不同的提交形式从而实现不同的传输语义。
pull 模式不足之处是，如果 kafka 没有数据，消费者可能会陷入循环中，始终期待数据达到。为了防止这种状况，咱们在咱们的拉申请中有参数，容许消费者申请在期待数据达到的“长轮询”中进行阻塞。
全部内容在 git 上, 理解更多请点我头像或到我的主页去取得，谢谢 **