1. 什么是Apache Kafka?

答：Apache Kafka是一个发布 - 订阅开源消息代理应用程序。这个消息传递应用程序是用“scala”编码的。基本上，这个项目是由Apache软件启动的。Kafka的设计模式主要基于事务日志设计。

2. Kafka中有哪几个组件?

主题：Kafka主题是一堆或一组消息。

生产者：在Kafka，生产者发布通信以及向Kafka主题发布消息。

消费者：Kafka消费者订阅了一个主题，并且还从主题中读取和处理消息。

经纪人：在管理主题中的消息存储时，我们使用Kafka Brokers。

3. 解释偏移的作用。

答：给分区中的消息提供了一个顺序ID号，我们称之为偏移量。因此，为了唯一地识别分区中的每条消息，我们使用这些偏移量。

4. 什么是消费者组？

答：消费者组的概念是Apache Kafka独有的。基本上，每个Kafka消费群体都由一个或多个共同消费一组订阅主题的消费者组成。

5. ZooKeeper在Kafka中的作用是什么？

答：Apache Kafka是一个使用Zookeeper构建的分布式系统。虽然，Zookeeper的主要作用是在集群中的不同节点之间建立协调。但是，如果任何节点失败，我们还使用Zookeeper从先前提交的偏移量中恢复，因为它做周期性提交偏移量工作。

6. 没有ZooKeeper可以使用Kafka吗？

答：绕过Zookeeper并直接连接到Kafka服务器是不可能的，所以答案是否定的。如果以某种方式，使ZooKeeper关闭，则无法为任何客户端请求提供服务。

7. 为什么Kafka技术很重要？

答：Kafka有一些优点，因此使用起来很重要：

高吞吐量：我们在Kafka中不需要任何大型硬件，因为它能够处理高速和大容量数据。此外，它还可以支持每秒数千条消息的消息吞吐量。
低延迟：Kafka可以轻松处理这些消息，具有毫秒级的极低延迟，这是大多数新用例所要求的。
容错：Kafka能够抵抗集群中的节点/机器故障。
耐久性：由于Kafka支持消息复制，因此消息永远不会丢失。这是耐久性背后的原因之一。
可扩展性：卡夫卡可以扩展，而不需要通过添加额外的节点而在运行中造成任何停机。

8. 是什么确保了Kafka中服务器的负载平衡？

答：由于领导者的主要角色是执行分区的所有读写请求的任务，而追随者被动地复制领导者。因此，在领导者失败时，其中一个追随者接管了领导者的角色。基本上，整个过程可确保服务器的负载平衡。

9. 副本和ISR扮演什么角色？

答：基本上，复制日志的节点列表就是副本。特别是对于特定的分区。但是，无论他们是否扮演领导者的角色，他们都是如此。
此外，ISR指的是同步副本。在定义ISR时，它是一组与领导者同步的消息副本。

10. 为什么Kafka的复制至关重要？

答：由于复制，我们可以确保发布的消息不会丢失，并且可以在发生任何机器错误、程序错误或频繁的软件升级时使用。

11. 如果副本长时间不在ISR中，这意味着什么？

答：简单地说，这意味着跟随者不能像领导者收集数据那样快速地获取数据。

12. 在生产者中，何时发生QueueFullException？

答：每当Kafka生产者试图以代理的身份在当时无法处理的速度发送消息时，通常都会发生QueueFullException。但是，为了协作处理增加的负载，用户需要添加足够的代理，因为生产者不会阻止。

13. Apache Kafka是分布式流处理平台吗？如果是，你能用它做什么？

答：毫无疑问，Kafka是一个流处理平台。它可以帮助：
1.轻松推送记录

2.可以存储大量记录，而不会出现任何存储问题
3.它还可以在记录进入时对其进行处理。

14. 你能用Kafka做什么？

答：它可以以多种方式执行，例如：

为了在两个系统之间传输数据，我们可以用它构建实时的数据流管道。
另外，我们可以用Kafka构建一个实时流处理平台，它可以对数据快速做出反应。

15. 在Kafka集群中保留期的目的是什么？

答：保留期限保留了Kafka群集中的所有已发布记录。它不会检查它们是否已被消耗。此外，可以通过使用保留期的配置设置来丢弃记录。而且，它可以释放一些空间。

16. 解释Kafka可以接收的消息最大为多少？

答：Kafka可以接收的最大消息大小约为1000000字节。
问题24：传统的消息传递方法有哪些类型？
答：基本上，传统的消息传递方法有两种，如：

排队：这是一种消费者池可以从服务器读取消息并且每条消息转到其中一个消息的方法。
发布-订阅：在发布-订阅中，消息被广播给所有消费者。

17. ISR在Kafka环境中代表什么？

答：ISR指的是同步副本。这些通常被分类为一组消息副本，它们被同步为领导者。

18. 什么是Kafka中的地域复制？

答：对于我们的集群，Kafka MirrorMaker提供地理复制。基本上，消息是通过MirrorMaker跨多个数据中心或云区域复制的。因此，它可以在主动/被动场景中用于备份和恢复；也可以将数据放在离用户更近的位置，或者支持数据位置要求。

19. 解释多租户是什么？

答：我们可以轻松地将Kafka部署为多租户解决方案。但是，通过配置主题可以生成或使用数据，可以启用多租户。此外，它还为配额提供操作支持。

20. Kafka中的数据日志是什么？

答：我们知道，在Kafka中，消息会保留相当长的时间。此外，消费者还可以根据自己的方便进行阅读。尽管如此，有一种可能的情况是，如果将Kafka配置为将消息保留24小时，并且消费者可能停机超过24小时，则消费者可能会丢失这些消息。但是，我们仍然可以从上次已知的偏移中读取这些消息，但仅限于消费者的部分停机时间仅为60分钟的情况。此外，关于消费者从一个话题中读到什么，Kafka不会保持状态。

21. Apache Kafka的缺陷

答：Kafka的局限性是：

没有完整的监控工具集
消息调整的问题
不支持通配符主题选择
速度问题

22. 什么是kafka 消费者重平衡？会造成什么影响？

重平衡本质上是一种协议，规定了 消费者组下的所有消费者，按照什么策略消费 Topic

就是 给消费组 中的每一个消费者分配消费 任务的过程。

重平衡的发生在启动一个消费者组前，但是在某些情况下，会正在运行消费的时，再次发生，可能会导致整个集群的暂时性的瘫痪，影响kafka的高可用。

23. 消费者重平衡的发生时机？

1. 订阅主题数发生变化，这种一般发生在业务改变，数据一定变化

2. 主题的分区发生变化， 启动集群前设置分区数， 之后调节，也是人为调节，可以在半夜

3. 消费端消费组成员的变化， 这个原因产生较大影响，消费者处理消息超时，Kafka集群配置的 max.poll.interval.ms 的值，那么该消费者将会自动离组. 心跳超时，如果消费者在指定的session.timeout.ms时间内没有汇报心跳，
   那么Kafka就会认为该消费已经dead了

24. Kafka 的 副本备份策略是什么？

kafka 采用的是同步和异步共同优点的备份策略，即将leader 的所有 follower 进行同步完毕才返回，ack. 只不过这个全部的副本是指的是 在 ISR 队列中的副本。

ISR 队列，是指 follower 副本存活且和 zookeeper 保持连接，同时其响应时间 较快。不满足条件的会被踢出去，满足的会被加入。

HW 高水位，表明 所有副本都同步到的 offset ，所有分区的最小offset ,那么 leader 也向 消费者提供的 HW.

LEO 每一个分区上的最新(大) offset

kafka采取同步和异步的共同优点，所以使用ISR的方法。把Follow中同步慢的节点从ISR中进行T除，从而保证了复制数据的速度。如果leader副本宕机，那么从ISR中选举出来新的leader副本。因为follow副本中都有记录HW。这样也会减少数据的丢失。Follow副本能够从leader中批量的读取数据并批量写入，从而减少了I/0的开销。

25. kafka 处理请求方案？

kafka 处理请求 类似于 Reactor 模式。

网络线程负责接受 请求， 然后将请求放入共享的请求队列中。

broker 有个 IO线程池， 负责从共享队列中取出请求， 执行真正的处理， 如果是 produce ,将消息写入底层磁盘的日志中， 如果是 fetch ，则从磁盘读取消息。

当 IO线程 处理完请求，将生成的响应 发送到 网络 线程池的响应队列中

请求队列是所有网络线程共享的，而响应队列是每个网络线程专属的

26. kafka controller 的作用？什么是脑裂怎么解决？

早期的版本并没有采用 kafka Controller 对分区和副本进行管理，而是依赖于 zookeeper， 每一个 broker 都会在 zookeeper 上为分区和副本注册大量的监听器。这种严重依赖于zookeeper 会有脑裂和 羊群效应。

只有kafka 的 controller 监控 zookeeper , 其他的 node 再和 controller 通信，减少 zookeeper的 压力。

什么是脑裂？
kafka中只有一个控制器controller 负责分区的leader选举，同步broker的新增或删除消息，但有时由于网络问题，可能同时有两个broker认为自己是controller，这时候其他的broker就会发生脑裂，不知道该听从谁的。

如何解决？controller epoch
每当新的controller产生的时候就会在zk中生成一个全新的、数值更大的controller epoch的标识，并同步给其他的broker进行保存，这样当第二个controller发送指令时，其他的broker就会自动忽略。

27. kafka controller 的竞选策略？

在任意时刻，集群中有且仅有一个控制器。

每个broker启动的时候会去尝试去读取zookeeper 中/controller节点的brokerid的值，如果读取到brokerid的值不为-1，则表示已经有其它broker节点成功竞选为控制器，所以当前broker就会放弃竞选；如果Zookeeper中不存在/controller这个节点，或者这个节点中的数据异常，那么就会尝试去创建/controller这个节点，当前broker去创建节点的时候，也有可能其他broker同时去尝试创建这个节点，只有创建成功的那个broker才会成为控制器，而创建失败的broker则表示竞选失败。每个broker都会在内存中保存当前控制器的brokerid值，这个值可以标识为activeControllerId。

28. 生产者幂等性和事务是什么？

目的： 进行retry重试时，只会生成一个消息。

为了实现Producer的幂等性，Kafka引入了Producer ID（即PID）和Sequence Number。

PID。每个新的Producer在初始化的时候会被分配一个唯一的PID，这个PID对用户是不可见的。

Sequence Numbler。（对于每个PID，该Producer发送数据的每个<Topic, Partition>都对应一个从0开始单调递增的Sequence Number。不是offset

实现原理： broker 在缓存中保存 序列号， 对于接受的每一条消息，如果序列号 比 缓存中的大 1 则接受，否则丢弃。但是者只能保证单个生产者对分区的 exactly once 语义。

，kafka事务属性是指一系列的生产者生产消息和消费者提交偏移量的操作在一个事务，或者说是是一个原子操作），同时成功或者失败。

在事务属性之前先引入了生产者幂等性，它的作用为：

生产者多次发送消息可以封装成一个原子操作，要么都成功，要么失败
consumer-transform-producer模式下，因为消费者提交偏移量出现问题，导致在重复消费消息时，生产者重复生产消息。需要将这个模式下消费者提交偏移量操作和生成者一系列生成消息的操作封装成一个原子操作。

事务属性实现前提是幂等性，即在配置事务属性transaction id时，必须还得配置幂等性；但是幂等性是可以独立使用的，不需要依赖事务属性。

29. 什么是kafka 消费者组？

消费者组是 kafka 提供的可以扩展且具有容错性的消费者机制。 一个分区，只能被消费者组中的一个消费者进行消费。

当消费者数量多于分区数量时，多于的消费者空闲。

当消费者数量少于分区数量时，一个消费者可能订阅多个分区。

发挥 consumer 最大的效果就是，consumer 数和topic 下的 partitions 数相等。

30. Kafka中是怎么体现消息顺序性的？

kafka每个partition中的消息在写入时都是有序的，消费时，每个partition只能被每一个group中的一个消费者消费，保证了消费时也是有序的。
整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1.

31. Kafka生产者客户端中使用了几个线程来处理？分别是什么？

2个，主线程和Sender线程。主线程负责创建消息，然后通过分区器、序列化器、拦截器作用之后缓存到累加器RecordAccumulator中。Sender线程负责将RecordAccumulator中消息发送到kafka中.

32. 消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?

offset+1

33. 有哪些情形会造成重复消费？

消费者消费后没有commit offset(程序崩溃/强行kill/消费耗时/自动提交偏移情况下unscrible)

34. 有哪些情形会造成重复消费？

消费者消费后没有commit offset(程序崩溃/强行kill/消费耗时/自动提交偏移情况下unscrible)

35. KafkaConsumer是非线程安全的，那么怎么样实现多线程消费？

1.在每个线程中新建一个KafkaConsumer

2.单线程创建KafkaConsumer，多个处理线程处理消息（难点在于是否要考虑消息顺序性，offset的提交方式）

36. 生产者策略?

1. 分区：默认是 RR 的轮询分区划分规则， 若指定了Key 则将key的hash值 % 分区号进行分区

2. kafka数据的可靠性： 分区必须确认收到，同时副本备份成功。 ack

半数以上follower完成备份 发送 ACK, 问题是选举新的leader ,容忍 n 台故障，需要 2n + 1 个副本

全部完成， 问题是延迟长， Kafka 选择这种，但是问题是 存在一个慢 ，或者挂掉，

3. ISR 代表同步副本，leader 从 ISR 中选新 leader, 通信时间 ，在延迟时间内去掉

kafka 中维护 ISR 的队列

当leader 接受到消息后，通知 ISR 中的follow 完成备份

4. acks 0 收到， 1 leader 完成 -1 leader,follower所有follow完成，（重复数据）

产生同步数据 ，follower 备份完成后， 这是leader 挂掉， producer 任务没收到，向follewer备份选举后的重复发送数据

一致性： follower还没同步完成，同步一半 leader 挂了，选举后作为leader 后原leader 活了，导致数据不一致

消费数据一致性：Leo: 每一个分区副本的最大 offset ，设置一个 HW 指的是高水位，所有分区leo的最小位置,HW之前的数据才对消费者可见

存储数据一致性： 重新选leader 给所有分区发生消息，直接截取数据到HW.

5. exactly-once : ack 为0 at-less-most

幂等性 + 至少一次 为精准一次

使用幂等性，在kafka 的 broker 消除数据的重复， kafka使用幂等性，默认 ack 为-1

首先给每一个生产者 添加一个 id , 给每一个消息 添加一个序列号， 如果同一个 生产者， 同一个消息序列号， 发往同一个分区，如果已经接受过，就进行去重。

但是生产者挂了重启，那么它的id 号也就变了，也就不能保证精准 一致性

37. 消费者策略?

1. 分区 ， RR 轮询，将当前消费者组不同的主题，当做一个整体，经轮询。好处，消费者组里面的消费最多差一个。

保证消费者组里面消费的topic 是一样的。 Range 是按照单个主题进行划分，将不同的topic 不当做一个整体进行考虑。

触发时在消费者组里面消费者个数变化时会触发分区，重新设置分配分配策略。

2. offset

消费者组 + 主题 + 分区 决定 offset, 消费者连接
Kafka 可以顺序写磁盘， 零拷贝技术

38. Range 分区?

Range 分区不会把主题看做一个整体进行划分

假设 有两个主题， T1(0,1,2), T2(0,1,2), 两个消费者组 （A，B） (C)

A 消费者 订阅 T1 , B 订阅 T1， T2 ，C 订阅了 T1

RR : 如果采用的RR 发现 A,B 消费者共用同一个组， 则会把 A,B 订阅的topic 当做一个整体进行考虑。

A,B 进行轮询的分区有：　T1 0 T1 1 T1 2 T2 0 T2 1 T2 3

Range : 按主题划分，先考虑谁订阅了这个主题，然后再进行划分

39. Kafka 如何保证数据的顺序性？

kafka：一个topic，一个partition，一个consumer，内部多线程.

kafka写到一个partition中的数据一定是有数据的。

解决办法： 一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可，既消费者不要使用多线程进行处理。或者你想多线程进行处理，你可以建立一个内存队列，通过hash进任务id相同分到一个内存队列，每一个内存队列对应一个线程。

40. 常见MQ 的区别？

ActiveMQ ：最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，单机吞吐量，万级，吞吐量比RocketMQ和Kafka要低了一个数量级，响应为ms级别，有较低的概率丢失数据。

RabbitMQ ：单机吞吐率万级，吞吐量比RocketMQ和Kafka要低了一个数量级，但是适合于中小型企业，因为自带了友好的监控和维护界面，社区相对比较活跃，几乎每个月都发布几个版本分，在国内一些互联网公司近几年用rabbitmq也比较多一些，但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重，同时语言在国内很少有人会。

RocketMQ ：单机吞吐量10万级，RocketMQ也是可以支撑高吞吐的一种MQ，topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降，这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic，可用性非常高，分布式架构，在阿里大规模应用过，有阿里品牌保障，日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，源码是JAVA.

Kafka : 单机吞吐量10万级别，这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景.topic从几十个到几百个的时候，吞吐量会大幅度下降
所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源,可用性非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用。