10 道 Kafka 基础面试，不看答案你会几道题

写在前面

这次给大家分享的是Kafka的10道面试题，就难度我觉得是比较基础的，但考的知识点还比较全面，可以用来考察自己掌握Kafka基础的程度。

1. Kafka是什么？

Kafka起初是一个多分区、多副本且基于ZooKeeper协调的分布式消息系统，现已被定位为一个分布式流式处理平台。

2. Kafka的架构了解吗？

建议按以下顺序讲述：

1. Kafka是基于发布/订阅的消息系统（引出Producer、Consumer和Broker），所以存在三个角色Producer（生产消息）、Broker（Kafka实例）和Consumer（消费消息）。
2. 生产者会将消息推送到Kafka的某个Topic上，以此区分消息。
3. 为了高可用性，通过在集群上部署多个Broker，一个Topic将以多副本的形式分布在多个Broker上，基于ZK选出一个Leader副本，而其他Follower副本则负责同步Leader副本，避免单点问题。
4. 为了高吞吐量，再将Topic划分成多个分区，可让Topic的吞吐量不受单机限制。
5. 为了高吞吐量，对于多个分区，单个消费者也可变成多个，形成消费组，一个分区由一个消费者负责。

最后可画出下图，如想看逐步的画图过程，可看下《图解Kafka中的基本概念》。

3. 了解其他MQ吗？有什么不同？

有了解RadbbitMQ，RabbitMQ由于有消息确认机制，所以数据丢失的可能性更小，适合严格的金融场景。

而Kafka的优势则在于其吞吐量更大，适合处理活跃的流式数据。

4. 如何保证消息的有序性？

Kafka只能保证局部有序，即只能保证一个分区里的消息有序。而其具体实现是通过生产者为每个分区的消息维护一个发送队列，我们需要将保证顺序的消息都发送到同一个分区中。并且由于Kafka会同时发送多个消息，所以还需指定max.in.flight.requests.per.connection为1，保证前一个消息发送成功，后一个消息才开始发送。

max.in.flight＞1 时能保证有序性吗？

可以，设置幂等能保证。不过max.in.flight不能大于5。这是因为Broker端只会缓存最近5个Batch的SequenceNumber，例如我们发送1到6的报文，其中1发送失败，2-5发送成功，Broker缓存下来，当1重试时，Broker检查到1小于缓存中的最小序号，会抛出异常，而Producer将重试发送1超过最多次数或超时，影响性能。

幂等如何保证有序性？

通过引入ProduceID(PID)和SequenceNumber的概念，每个Producer在初始化时被分配唯一的PID，而的每条有一个从0单调递增的SequenceNumber。在发送消息时，由以下三点保证：

1. 验证序号连续：Broker会验证Batch的SequenceNumber是否连续，若不连续，抛出异常；
2. 重试时，batch放置正确位置：Producer请求重试时，会根据SequenceNumber将Batch放在队列中的合适位置；
3. 重试时，max.in.flight调为1：当请求重试时，会把max.in.flight动态调整为1，保证请求序号小的先发送成功。

5. 如何保证幂等？

Kafka具有幂等机制，但默认不开启，需要设置enable.idempotence为true开启。但只能实现单会话、单分区上的幂等。

为什么只能实现单会话上的幂等？

在Producer初始化时，Kafka会为其重新分配一个新的PID，而Broker端在维护SequenceNumber时是以作为维度，因此当PID变化时Broker将无法获得之前的状态信息，无法做到单会话上的不丢不冲。

如何实现跨会话幂等？

事务机制，通过引入TransactionID和Epoch。不同于PID是由内部进行分配，TrasactionID是由用户提供。而TransactionID与PID会一一对应，这样当Producer宕机时，集群启动一个新的Producer，在初始化时可以通过TransactionID获得PID，便能继续工作。同时会被分配一个单调递增的Epoch，来保证当旧Producer恢复后可能生产出重复消息，Broker段会拒绝旧Epoch的消息。

6. 支持什么语义？

三种语义：

1. 最多一次(At Most Once)：不会重复发送，可能消息丢失
2. 最少一次(At Least Once)：会重复发送，消息不会丢失(默认)
3. 只有一次(Exactly Once)：不会重复发送，消息不会丢失

7. 如何保证Exactly Once语义？

1. Producer幂等 + At Least Once = Exactly Once（单分区、单会话）
2. 事务可实现跨分区、跨会话的Exactly Once语义

8. 消息重复的场景有哪些？如何解决？

Broker在写入消息后，Producer没有收到成功的响应。

解决方法：

1. 启动幂等；
2. acks = 0，不重试，但会丢失消息。

9. 消息丢失的场景有哪些？如何解决？

（一）Producer端丢失消息

在调用send方法时，由于网络原因发送失败。

解决办法：设置retries为一个合适的值，一般为3，此外重试的间隔不能太小，避免网络一次波动的区间就把三次重试用完了。

（二）Consumer端丢失消息

自动提交offset时，可能未来得及处理消息，但offset已被提交。

解决办法：关闭自动提交，消费完后手动提交offset。

（三）Broker端丢失消息

Leader副本所在的Broker宕机，而Follower副本还没有完全通过Leader

解决办法：

1. 设置acks =-1或ALL，保证Follower副本写入消息；
2. replication.factor > 3，保证分区至少有3个副本，冗余消息；
3. min.insync.replicas >1，消息至少被写入2个副本才认为成功；
4. unclean.leader.election.enable=false，避免从非ISR中选举Leader。

10. Kafka吞吐量高的原因

1. 顺序写：写读数据时，数据直接追加在文件的末尾；
2. MMAP：数据不实时写入硬盘，以此提高IO效率；
3. 零拷贝：读数据时，使用了sendfile，磁盘文件读到OS内核缓冲区后，直接转到socket buffer进行网络发送；
4. 批量压缩：消耗少量的CPU资源，提高IO效率；

一句话贯穿：Kafka把所有的消息都变成一个个批量的文件，并且进行合理的批量压缩，减少网络IO的损耗，写入是通过MMAP提高IO效率，同时由于单个分区是顺序写文件，所以速度最优；读取数据的时候配合sendfile直接暴力输出。

以上就是本次分享的10道Kafka面试题，有问题的地方，欢迎留言交流。