kafka常见经典面试题

深藏阁楼爱情的钟 2022-10-15 09:59 208阅读 0赞

## kafka工作原理 ##

kafka 分为server、生产者和消费者，生产者发送消息的时候必须要指定哪个topic，消费者在消费消息的时候必须要指定哪个topic 的消息，kafka 的消息是完全持久化的，topic下分为多个分区（partition），消息是保存到分区的。

## kafka的broker 是干什么的 ##

broker 是消息的代理，Producers往Brokers里面的指定Topic中写消息，Consumers从 Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。

## kafka中的zookeeper 起到了什么作用。可以不使用zookeeper么 ##

zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖，但是broker依然依赖于ZK，zookeeper 在kafka中还用来选举controller 和 检测broker是否存活等等。

## kafka follower如何与leader同步数据? ##

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

## kafka 为什么那么快 ##

Cache Filesystem Cache PageCache缓存  
顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。  
Zero-copy 零拷贝技术减少拷贝次数  
Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。  
Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。

## kafka producer如何优化写入速度？ ##

1.  增加线程
2.  提高 batch.size
3.  增加更多 producer 实例
4.  增加 partition 数
5.  设置 acks=-1 时，如果延迟增大：可以增大 num.replica.fetchers（follower 同步数据的线程数）来调解；
6.  跨数据中心的传输：增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。

## 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了

## 重复消费问题如何解决： ##

数据交互的时候需要一个唯一的id,利用redis 的setnx 写入数据

## 引入消息队列之后该如何保证其高可用性 ##

推荐链接: [https://www.cnblogs.com/qingmuchuanqi48/p/11124035.html][https_www.cnblogs.com_qingmuchuanqi48_p_11124035.html]

## 如何保证顺序消费 ##

一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可

## 百万消息推积了如何处理 ##

1.  先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉
2.  新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
3.  然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
4.  接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
5.  这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
6.  等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息

## 扩展: ZooKeeper工作原理 ##

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议（ZooKeeper Atomic Broadcast protocol）。Zab协议有两种模式，它们分别是恢复模式（Recovery选主）和广播模式（Broadcast同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。  
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

[https_www.cnblogs.com_qingmuchuanqi48_p_11124035.html]: https://www.cnblogs.com/qingmuchuanqi48/p/11124035.html