【kafka机制】kafka常见题目

一、kafka常见面试题

1、kafka定义/理解/优点

分布式的高性能，高吞吐的消息队列系统

如何保证高可用？
1、kafka基本架构由多个broker节点组成的；一个topic主题对应多个分区，而每一个分区存存在broker节点；
2、kafka的副本机制，副本存在其他分区，提高数据的容错性

如何保证高性能/高吞吐？
1、单个partition内的消息是顺序读写，先进先出，消息ID是自增长，按ID分段成不同所Segment文件存储，检索快速；
2、内存读写是零拷贝，使用了Linux的sendfile技术，减了用户态与内核态的内存拷贝移动次数；
3、mmap文件映射
在进程 的非堆内存开辟一块内存空间，和OS内核空间的一块内存进行映射，
kafka数据写入、是写入这块内存空间，但实际这块内存和OS内核内存有映射，也就是相当于写在内核内存空间了，且这块内核空间、内核直接能够访问到，直接落入磁盘。

用途：削峰、解藕、异步通信

缺点：
1、引入外部依赖，外部依赖越多，越容易挂掉
2、系统复杂度提高：使用 MQ 后可能需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题；

引申：什么是零拷贝
背景：平时从服务器读取静态文件时，服务器先将文件从复制到内核空间，再复制到用户空间，最后再复制到内核空间并通过网卡发送出去，而零拷贝则是直接从内核到内核再到网卡，省去了用户空间的复制。

1、第一次：将磁盘文件，读取到操作系统内核缓冲区；
2、第二次：将内核缓冲区的数据，copy到application应用程序的buffer；
3、第三步：将application应用程序buffer中的数据，copy到socket网络发送缓冲区(属于操作系统内核的缓冲区)；
4、第四次：将socket buffer的数据，copy到网卡，由网卡进行网络传输。

2、Kafka中的ISR、AR又代表什么？

ISR:In-Sync Replicas 副本同步队列
AR:Assigned Replicas 所有副本
ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

3、kafka producer 打数据，ack 为 0， 1， -1 的时候代表啥， 设置 -1 的时候，什么情况下，leader 会认为一条消息 commit了

1（默认） 数据发送到Kafka后，经过leader成功接收消息的的确认，就算是发送成功了。在这种情况下，如果leader宕机了，则会丢失数据。
0 生产者将数据发送出去就不管了，不去等待任何返回。这种情况下数据传输效率最高，但是数据可靠性确是最低的。
-1 producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成，可靠性最高。当ISR中所有Replica都向Leader发送ACK时，leader才commit，这时候producer才能认为一个请求中的消息都commit了

4、Kafka中的消息是否会丢失和重复消费？

要确定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费。

1、消息发送

     Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.required.acks属性来确认消息的生产：

0—表示不进行消息接收是否成功的确认；
1—表示当Leader接收成功时确认；
-1—表示Leader和Follower都接收成功时确认；
综上所述，有6种消息生产的情况，下面分情况来分析消息丢失的场景：

（1）acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；

（2）acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

另外，还有设置重试次数

2、消息重复消费
根本原因 已经消费了数据，但是offset没有成功提交；或者生产者重复推送消息。

其中很大一部分原因在于发生了再均衡。
1）消费者宕机、重启等。导致消息已经消费但是没有提交offset。
2）消费者使用自动提交offset，但当还没有提交的时候，有新的消费者加入或者移除，发生了rebalance。再次消费的时候，消费者会根据提交的偏移量来，于是重复消费了数据。
3）消息处理耗时，或者消费者拉取的消息量太多，处理耗时，超过了max.poll.interval.ms的配置时间，导致认为当前消费者已经死掉，触发再均衡。

3、rebalance过程
第一阶段：选择组协调器
组协调器GroupCoordinator：每个consumer group都会选择一个broker作为自己的组协调器coordinator，负责监控这个消费组里的所有消费者的心跳，以及判断是否宕机，然后开启消费者rebalance。consumer group中的每个consumer启动时会向kafka集群中的某个节点发送FindCoordinatorRequest请求来查找对应的组协调器GroupCoordinator，并跟其建立网络连接。

组协调器选择方式：通过如下公式可以选出consumer消费的offset要提交到__consumer_offsets的哪个分区，这个分区leader对应的broker就是这个consumer group的coordinator

公式：hash(consumer group id) % __consumer_offsets主题的分区数

第二阶段：加入消费组
在成功找到消费组所对应的GroupCoordinator之后就进入加入消费组的阶段，在此阶段的消费者会向GroupCoordinator发送JoinGroupRequest请求，并处理响应。然后GroupCoordinator从一个consumer group中选择第一个加入group的consumer作为leader(消费组协调器)，把consumer group情况发送给这个leader，接着这个leader会负责制定分区方案（由于rebalance等策略有客户端配置决定，因此分区方案需要consumer来制定，以消费组协调器的配置为准）。

第三阶段：SYNC GROUP
consumer leader通过给GroupCoordinator发送SyncGroupRequest，接着GroupCoordinator就把分区方案下发给各个consumer，他们会根据指定分区的leader broker进行网络连接以及消息消费。

5、Kafka中是怎么体现消息顺序性的？

分区之间无序，单个分区内有序；
比如说我们建了一个 topic，有三个 partition。生产者在写的时候，其实可以指定一个 key，比如说我们指定了某个订单 id 作为 key，那么这个订单相关的数据，一定会被分发到同一个 partition 中去，而且这个 partition 中的数据一定是有顺序的。

消费者分布式锁保证消费有序，防止线程并发；

6、kafka如何实现延迟队列？

基于时间轮自定义了一个用于实现延迟功能的定时器；时间轮插入和删除都是O(1)，数据结构是：底层使用数组实现，数组中的每个元素可以存放一个TimerTaskList对象。TimerTaskList是一个环形双向链表，在其中的链表项TimerTaskEntry中封装了真正的定时任务TimerTask.
参考：https://blog.csdn.net/u013256816/article/details/80697456

7、几种消息队列对比？

1）kafaka支持多种客户端语言
2）rocketmq支持java语言

8、大量消息在 MQ 里长时间积压，该如何解决？
出现原因：
其一为消费的太慢或消费方出现异常，其二为生产方生产的太快，总的来说就是消息的速度赶不上生产的速度，生产和消费速度不匹配造成的。
消息堆积的解决方案
1） 消费端：增加消费者，多部署几台消费者机器（横向扩展），提升消费者的消费能力。
2）消费端：此种情况可以将这些消费不成功的消息转发到其它队列里去(类似死信队列)，后面再慢慢分析死信队列里的消息处理问题。
3）消费端：mq 中的消息过期失效了。可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回来。
4）生产端：流量激增的话，我们需要评估是否需要增加资源还是通过限流的方式解决

https://www.jianshu.com/p/5f4b3a520719

9、消息中间件面试题：如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时呢？
https://www.jianshu.com/p/5f4b3a520719

10、消息中间件面试题：消息队列的优缺点，区别
参考：https://www.jianshu.com/p/eaafb1581e55

11、kafka如何保障消息发送顺序性？
1）kafka可以通过partitionKey，将某类消息写入同一个partition，一个partition只能对应一个消费线程，以保证数据有序。

引申：producer发消息到队列时，通过加锁保证有序。先后两条消息发送时，前一条消息发送失败，后一条消息发送成功，然后失败的消息重试后发送成功，造成乱序？

为了解决重试机制引起的消息乱序为实现Producer的幂等性，Kafka引入了Producer ID（即PID）和Sequence Number。

对于接收的每条消息，如果其序号比Broker维护的序号大一，则Broker会接受它，否则将其丢弃

如果消息序号比Broker维护的序号差值比一大，说明中间有数据尚未写入，即乱序，此时Broker拒绝该消息

如果消息序号小于等于Broker维护的序号，说明该消息已被保存，即为重复消息，Broker直接丢弃该消息

引申：消费端只用单线程消费效率低？
解决方案
消费者端创建多个内存队列，具有相同 key 的数据都路由到同一个内存 队列；然后每个线程分别消费一个内存队列即可，这样就能保证顺序性。