kafka面试（kafka面试避免重复消费）

本篇文章给大家谈谈kafka面试，以及kafka面试避免重复消费对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Kafka相关面试题
• 2、面试阿里巴巴有多难，看看面经你就知道了
• 3、Linux运维工程师会面试哪些
• 4、Kafka面试题
• 5、大数据架构选择消息队列，我选kafka。面试官问为什么？
• 6、2020-11-16-Kafka-3(面试题)

Kafka相关面试题

title: Kafka常见问题

date: 2020-04-01 16:25:49

update: 2020-04-01 20:31:30

excerpt: Kafka 面试中常见问题

toc_min_depth: 3

tags:

Kafka是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。

位置

内容

kafka中的消费者在读取服务端的数据时，需要将服务端的磁盘文件通过网络发送到消费者进程，网络发送需要经过几种网络节点。如下图所示：

传统的读取文件数据并发送到网络的步骤如下：

（1）操作系统将数据从磁盘文件中读取到内核空间的页面缓存；

（2）应用程序将数据从内核空间读入用户空间缓冲区；

（3）应用程序将读到数据写回内核空间并放入socket缓冲区；

（4）操作系统将数据从socket缓冲区复制到网卡接口，此时数据才能通过网络发送。

通常情况下，Kafka的消息会有多个订阅者，生产者发布的消息会被不同的消费者多次消费，为了优化这个流程，Kafka使用了“零拷贝技术”，如下图所示：

“零拷贝技术”只用将磁盘文件的数据复制到页面缓存中一次，然后将数据从页面渗掘哪缓存直接发送到网络中（发送给不同的订阅者时，都可以使用同一个页面缓存），避免了重复复制操作。

如果有10个消费者，传统方式下，数据复制次数为4*10=40次，而使用“零拷贝技术”只需要1+10=11次，一次为从磁盘复制到页面缓存，10次表示10个消费者各自读取一次页面缓存。

传统的文件拷贝通常需要从用户态去转到核心态，经过read buffer，然丛码后再返回到用户态的应用层buffer，然后再从用户态把数据拷贝到核心态的socket buffer，然后发送到网卡。

传统的数据传输需要多次的用户态和核心态之间的切换，而且还要把数据复制多次，最终才打到网卡。

如果减少了用户态与核心态之间的切换，是不是就会更快了呢？

此时我们会发现用户态“空空如也”。数据没有来到用户态，而是直接在核心态就进行了传输，但这样依然还是有多次复制。首先数据被读取到read buffer中，然后发到socket buffer，最后才发到网卡。虽然减少了用户态和核心态的切换，但依然存在多次数据复制。

如果可以进一步减少数据复制的次数，甚至没有数据复制是不是就会做到最快呢？

DMA

别急，这里我们先介绍一个新的武器:DMA。

DMA，全称叫Direct Memory Access，一种可让某些散清硬件子系统去直接访问系统主内存，而不用依赖CPU的计算机系统的功能。听着是不是很厉害，跳过CPU，直接访问主内存。传统的内存访问都需要通过CPU的调度来完成。如下图：

而DMA，则可以绕过CPU，硬件自己去直接访问系统主内存。如下图：

很多硬件都支持DMA，这其中就包括网卡。

零拷贝

回到本文中的文件传输，有了DMA后，就可以实现绝对的零拷贝了，因为网卡是直接去访问系统主内存的。如下图：

Java的零拷贝实现

在Java中的零拷贝实现是在FileChannel中，其中有个方法transferTo(position,fsize,src)。

传统的文件传输是通过java.io.DataOutputStream，java.io.FileInputStream来实现的，然后通过while循环来读取input，然后写入到output中。

零拷贝则是通过java.nio.channels.FileChannel中的transferTo方法来实现的。transferTo方法底层是基于操作系统的sendfile这个system call来实现的（不再需要拷贝到用户态了），sendfile负责把数据从某个fd（file descriptor）传输到另一个fd。

sendfile：

Java的transferTo：

传统方式与零拷贝性能对比

可以看出速度快出至少三倍多。Kafka在文件传输的过程中正是使用了零拷贝技术对文件进行拷贝。建议以后多用FileChannel的transferTo吧。

总结

需要用到的类：

KafkaProducer ：需要创建一个生产者对象，用来发送数据

ProducerConfig ：获取所需的一系列配置参数

ProducerRecord ：每条数据都要封装成一个ProducerRecord对象

几个比较重要的配置项

//kafka集群，broker-list

props.put("bootstrap.servers", "hadoop102:9092");

[img]

面试阿里巴巴有多难，看看面经你就知道了

面试阿里巴巴有多难，看看面经你就知道了

研发工程师（Java）

我参与了阿里巴巴中间件部门的提前批面试，一共经历了四次面试，拿到了口头offer。这是我的面经，在这里分享给大家。

一面：

1 自我介绍

2 项目中做了什么，难点呢。

3 Java的线程池说一下，各个参数的作用，如何进行的。

4 Redis讲一下

5 分布式系统的全局id如何实现。用zookeeper如何实现的呢，机器号+时间戳即可。

6 分布式锁的方案，redis和zookeeper那个好，如果是集群部署，高并发情况下哪个性能更好。

7 kafka了解么，了解哪些消息队列。

8 想做业务还是研究。

9 然后出了一道题，linux的访问权限是rwx格式的。使用一个类支持访问权限的增删改查，并且注意使用的数据格式以及方法效率，规范。给了一个多小时写题。

耗时将近30分钟。

二面：

1 介绍你做的项目和其中的难点。

2 上次面试官问的问题，反射的作用是什么。

3 数据仓库，多线程和并发工具等。

4 私有云，docker和k8s等。

5 了解哪些中间件，dubbo，rocketmq，mycat等。

6 dubbo中的rpc如何实现。

7 自己实现rpc应该怎么做

9 dubbo的服务注册与发现。

10 听说我是非科班，于是问了些排序颤历算法

耗时将近30分钟。

三面：

三面不是面试，而是笔试，耗时三个肆凳小时，考的是Java核心的基础。但是好像不能透题，就不说了。都挺有难度的。

大概说一下就是有几个考点，Java并发的知识点，集茄雹搜合类，线程池，多线程之间的通信等。

HR面：

聊人生谈理想，HR小姐姐非常温柔，交流十分愉快。30分钟。

Linux运维工程师会面试哪些

给大家分享一些Linux面试题的笔记，从负载均衡、nginx、MySQL、redis、kafka、zabbix、k8s等方面拆解 Linux 知识点。用来对个人技术点进行查漏补缺。

目录：

1. 磁盘使用率检测（用shell脚本）

2. LVS 负载均衡有哪些策略？

3. 谈谈你对LVS的理解？

4. 负载均衡的原理是什么？

5. LVS由哪两部分组成的？

6. 与lvs相关的术语有哪些？

7. LVS-NAT模式的原理

8. LVS-NAT模型的特性

9. LVS-DR模式原理

10. LVS-DR模型的特性

11. LVS三种负载均衡模式的比较

12. LVS的负载调度算法

13. LVS与nginx的区别

14. 负载均衡的作用有哪些？

15. nginx实现负载均衡的分发策略

16. keepalived 是什么？

17. 你是如何理解VRRP协议的

18. keepalived的工作原理？

19. 出现脑裂的原因

20. 如何解决keepalived脑裂问题？

21. zabbix如何监控脑裂？

22. nginx做负载均衡实现的策略有哪些

23. nginx做负载均衡用到哪些模块

24. 负载均衡有哪些实现方式

25. nginx如何实现四层负载？

26. 你知道的web服务有哪些？

27. 为什么要用nginx

28 . nginx的性能为什么比apache高？

29 . epoll的组成

30 . nginx和apache的区别

31. Tomcat作为web的优缺点？

32. tomcat的三个端口及作用

33. fastcgi 和cgi的区别

34. nginx常用的命令

35. 什么咐氏是反向代理，什么是正向代理，以及区别？

36. Squid、Varinsh、Nginx 有什么区别？

37. nginx是如何处理http请求的

38. nginx虚拟主机有哪些？

39. nginx怎么实现后端服务的健康检查

40. apache中的Worker 和 Prefork 之间的区别是什么?

41. Tomcat缺省端口是多少，怎么修改

42. Tomcat的工作模式是什么？

43. Web请求在Tomcat请求中的请求流程是怎么样的?

44. 怎么监控Tomcat的内存使用情况

45. nginx的优化你都做过哪棚陵些？

46. Tomcat你做过哪些优化

47. nginx的session不同步怎么办

48. nginx的常用模块有哪些？

49. nginx常用状态码

50. 访问一个网站的流程

51. 三次握手，四次挥手

52. 什么是动态资源，什么是静态资源

53. worker支持的最大并发数是什么？

54. Tomcat和Resin有什么区别，工作中你怎么选择？

55. 什么叫网站灰度发布？56.. 统计ip访问情况，要求分析nginx访问日志，找出访问页面数量在前十位的ip

57. nginx各个版本的区别

58. nginx最新版本

59. 关于nginx access模块的链简戚面试题

60. nginx默认配置文件

61. location的规则

62. 配置nginx防盗链

63. drop，delete和truncate删除数据的区别？

64. MySQL主从原理

65. MySQL主从复制存在哪些问题？

66. MySQL复制的方法

67. 主从延迟产生的原因及解决方案？

68. 判断主从延迟的方法

69. MySQL忘记root密码如何找回

70. MySQL的数据备份方式

71. innodb的特性

72. varchar(100) 和varchar(200）的区别

73. MySQL主要的索引类型

74. 请说出非关系型数据库的典型产品、特点及应用场景？

75. 如何加强MySQL安全，请给出可行的具体措施？

76. Binlog工作模式有哪些？各什么特点，企业如何选择？

77. 生产一主多从从库宕机，如何手工恢复？

78. MySQL中MyISAM与InnoDB的区别，至少5点

79. 网站打开慢，请给出排查方法，如是数据库慢导致，如何排查并解决，请分析并举例？

80. xtrabackup的备份，增量备份及恢复的工作原理

81.误执行drop数据，如何通过xtrabackup恢复？

82. 如何做主从数据一致性校验？

83. MySQL有多少日志

84. MySQL binlog的几种日志录入格式以及区别

85. MySQL数据库cpu飙升到500%的话他怎么处理？

86. redis是单线程还是多线程？

87. redis常用的版本是？

88. redis 的使用场景？

89. redis常见的数据结构

90. redis持久化你们怎么做的？

91. 主从复制实现的原理

92. redis哨兵模式原理

93. memcache和redis的区别

94. redis有哪些架构模式？

95. 缓存雪崩？

96. 缓存穿透

97. 缓存击穿

98. redis为什么这么快

99. memcache有哪些应用场景

100. memcache 服务特点及工作原理

101. memcached是如何做身份验证的？

102. mongoDB是什么？

103. mongodb的优势

104. mongodb使用场景

105. kafka 中的ISR，AR代表什么，ISR伸缩又代表什么

106.kafka中的broker 是干什么的

107. kafka中的 zookeeper 起到什么作用，可以不用zookeeper么

108. kafka follower如何与leader同步数据

109. kafka 为什么那么快

110. Kafka中的消息是否会丢失和重复消费？

111. 为什么Kafka不支持读写分离？

112. 什么是消费者组?

113. Kafka 中的术语114. kafka适用于哪些场景

115. Kafka写入流程：

116. zabbix有哪些组件

117. zabbix的两种监控模式

118. 一个监控系统的运行流程

119. zabbix的工作进程

120. zabbix常用术语

121. zabbix自定义发现是怎么做的？

122. 微信报警

123. zabbix客户端如何批量安装

124. zabbix分布式是如何做的

125. zabbix proxy 的使用场景

126. prometheus工作原理

127. prometheus组件

128. ELK工作流程

129. logstash的输入源有哪些？

130. logstash的架构

131. ELK相关的概念

132. es常用的插件

134. zabbix你都监控哪些参数

135. MySQL同步和半同步

136. CI/CD

137 K8S监控指标

138. k8s是怎么做日志监控的

139. 【运维面试】k8s中service和ingress的区别

140. k8s组件的梳理

141. 关于tcp/IP协议

142. 谈谈你对CDN的理解

Kafka面试题

Kafka是分布式发布-订阅消息系统，它最初是由LinkedIn公司开发的，之后成为Apache项目的一部分，Kafka是一个分布式，可划分的，冗余备份的持久性的日志服务，它主要用于处理流式数据。

为什么要使用 kafka，为什么要使用消息队列

消息发送

解决方案

1.配置ack=all/-1，tries 1,unclean.leader.election.enable = false

producer发送完消息，等待follower同步完成再返回，如果异常则重试，副本数量可能影响吞吐量

不允许选举ISR的副本作为leader

2.配置min.insync.replicas1

副本指定必须行弊写操作成功的最小副本数量，如果不能满足这个最小值，则生产者引发一个异常（NotEnoughReplicash或者NotEnoughReplicashAfterAppend）

消费

先commit再处理消息，如果处理消息的时候异常了，但offset已经提交了，这条消息对于消费者来说丢失了

broker的刷盘

减少刷盘的间隔

kafka如何保证不重复消费又不丢失数据

1.必须要求至少一个 Follower 在 ISR 列表里。

2.第二条，每次写入数据的时候，要求 Leader 写入成功以外，至少一个 ISR 里的 Follower 也写成功。

pull模式

push模式

缺点：速率固定，忽略了consumer的消费能力，可能导致拒绝服务或者网络阻塞等情况

1. Broker注册 Broker是分布式部署并且相互之间相互独立，但是需要有一个注册系统能够将整个集群中的则如Broker管理起来 /brokers/ids

2. Topic注册 在Kafka中，同一个Topic的消息会被分成多个分区并将其分布在多个Broker上，这些分区信息及与Broker的对应关系也都是由Zookeeper在维护 /borkers/topics

3. 生产者负载均衡 由于同一个Topic消息会被分区并将其分布在多个Broker上，因此，生产者需要将消息合理地发送到这些分布式的Broker上，那么如何实现生产者的负载均衡，Kafka支持传统的四层负载均衡，也支持Zookeeper方式实现负载均衡。

4. 消费者负载均衡 与生产者类似，Kafka中的消费者同样需要进行负载均衡来实现多个消费者合理地从对应的Broker服务器上接收消息，每个消费者分组包含若干消费者，每条消息都只会发送给分组中的一个消费者，不同的消费者分组消费自己特定的Topic下面的消息，互不干扰。

5. 分区与消费者 的关系 在Kafka中，规定了每个消息分区 只能被同组的一个消费者进行消费，因此，需要在 Zookeeper 上记录 消息分区 与 Consumer 之间的关系，每个消费者一旦确定了对一个消息分区的消费权力，需要将其Consumer ID 写入到 Zookeeper 对应消息分区的临时节点上，例如：

/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]

其中，[broker_id-partition_id]就是一个 消息分区 的标识，节点内容就是该 消息分区 上 消费者的Consumer ID。

6. 消息消费进度Offset 记录 在消费者对指定消息档盯族分区进行消息消费的过程中，需要定时地将分区消息的消费进度Offset记录到Zookeeper上，以便在该消费者进行重启或者其他消费者重新接管该消息分区的消息消费后，能够从之前的进度开始继续进行消息消费。Offset在Zookeeper中由一个专门节点进行记录，其节点路径为:

/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]

节点内容就是Offset的值。

7. 消费者注册 消费者服务器在初始化启动时加入消费者分组的步骤如下

注册到消费者分组。每个消费者服务器启动时，都会到Zookeeper的指定节点下创建一个属于自己的消费者节点，例如/consumers/[group_id]/ids/[consumer_id]，完成节点创建后，消费者就会将自己订阅的Topic信息写入该临时节点。

Kafka不基于内存，而是硬盘存储，因此消息堆积能力更强

1.顺序写磁盘（相比磁盘的随机写快很多）。如果你是追加文件末尾按照顺序的方式来写数据的话，那么这种磁盘顺序写的性能基本上可以跟写内存的性能本身也是差不多的。

2.利用Page Cache（页高速缓冲存储器，简称页高缓）空中接力的方式来实现高效读写，操作系统本身有一层缓存，叫做page cache，是在内存里的缓存，我们也可以称之为os cache，意思就是操作系统自己管理的缓存。原理就是Page Cache可以把磁盘中的数据缓存到内存中，把对磁盘的访问改为对内存的访问。

3.零拷贝 零拷贝技术是一种避免CPU将数据从一块存储拷贝到另一块存储的技术。Kafka使用零拷贝技术将数据直接从磁盘复制到网卡设备缓冲区中，而不需要经过应用程序的转发。

通常应用程序将磁盘上的数据传送至网卡需要经过4步：

-调用read()，将数据从磁盘复制到内核模式的缓冲区；

-CPU会将数据从内核模式复制到用户模式下的缓冲区；

-调用write()，将数据从用户模式下复制到内核模式下的Socket缓冲区；

-将数据从内核模式的Socket缓冲区复制到网卡设备。

上面的步骤中，第2、3步将数据从内核模式经过用户模式再绕回内核模式，浪费了两次复制过程。采用零拷贝技术，Kafka可以直接请求内核把磁盘中的数据复制到Socket缓冲区，而不用再经过用户模式

Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有consumer如何达成一致，来分配订阅 Topic 的每个分区。

Rebalance 的触发条件有3个

Rebalance 发生时，Group 下所有 consumer 实例都会协调在一起共同参与，kafka 能够保证尽量达到最公平的分配。但是 Rebalance 过程对 consumer group 会造成比较严重的影响。在 Rebalance 的过程中 consumer group 下的所有消费者实例都会停止工作，等待 Rebalance 过程完成。

GroupCoordinator(协调者)：协调消费者组完成消费者Rebalance的重要组件，每一个broker都会启动一个GroupCoodinator，Kafka 按照消费者组的名称将其分配给对应的GroupCoodinator进行管理；每一个GroupCoodinator只负责管理一部分消费者组，而非集群中全部的消费者组。通常是partition的leader节点的broker

如果C1消费消息超时，出入rebalance，重新分配后该消息被其他消费者消费，此时C1消费完成提交offset，导致错误

解决：Coordinator每次进行rebalance，会标记一个generation给consumer，每次rebalance该generation会+1,consumer提交offset时，会对比generation，不一致则拒绝提交。

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。

在 Kafka 中，每个 主题分区下的每条消息都被赋予了一个唯一的 ID 数值，用于标识它在分区中的位置。这个 ID 数值，就被称为位移，或者叫偏移量。一旦消息被写入到分区日志，它的位移值将不能被修改。

auto.offset.reset：消费规则，默认earliest 。

earliest: 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费

latest: 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据

none: topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset，则抛出异常

Kafka 副本当前分为领导者副本和追随者副本。只有Leader副本才能 对外提供读写服务，响应Clients端的请求。Follower 副本只是采用拉(PULL)的方 式，被动地同步Leader副本中的数据，并且在Leader副本所在的 Broker 宕机后，随时准备应聘 Leader 副本。

kafka在所有broker中选出一个controller，所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式（比Zookeeper Queue的方式更高效）通知需为此作出响应的Broker。同时controller也负责增删Topic以及Replica的重新分配。

分区的 Leader 副本选举对用户是完全透明的，它是由 Controller 独立完成的。你需要回答的是，在哪些场景下，需要执行分区 Leader 选举。每一种场景对应于一种选举策略。当前，Kafka 有 4 种分区 Leader 选举策略。

集群 partition 备份 Kafka 支持设置针对每个 partition 备份，可以将 partition 备份到不同的 broker 上，其中 leader partition 负责读写，其他 follower 仅负责同步，当 leader 挂掉后会从 follower 中选取新的 leader 。

消息消费顺序 一个 partition 同一时刻在一个 consumer group 中只能有一个 consumer 实例在消费，从而保证了消费顺序。consumer group 中的 consumer 实例的数量不能比一个 topic 中的 partition 的数量多，否则，多出来的 consumer 无法消费到消息。Kafka 的消息在单个 partition 上是可以保证顺序的，但是在整体上无法保证顺序消费

消息消费模式 关于消费模式，Kafka 通过 消费组的概念可以灵活设置。如常见的 队列模式 即 所有的 consumer 在同一个 consumer group 下。发布订阅模式 则设置多个 consumer group 进行消费即可

acks:消息的确认机制，默认值是0。

acks=0：如果设置为0，生产者不会等待kafka的响应。

acks=1：这个配置意味着kafka会把这条消息写到本地日志文件中，但是不会等待集群中其他机器的成功响应。

acks=all：这个配置意味着leader会等待所有的follower同步完成。这个确保消息不会丢失，除非kafka集群中所有机器挂掉。这是最强的可用性保证。

大数据架构选择消息队列，我选kafka。面试官问为什么？

毫无疑问 Kafka!

最多前面加个Flume。

任睁配卜何选型的原因，都源自你的需求是什么。 Fast,Scalable,Durable是我的需求，Kafka完美满足。卖或稍微讲些细节，好多想必大家也都知道。

Kafka将数据写到磁盘，实际上都会写到OS的page cache里， 而读的时候又用sendfile非常高效的将数据传输到NIC。

Kafka的扩展性也非常好，只要增加broker即可。Kafka的逻辑也非常清晰，可以将不同业务逻辑的数据写进不同到topic，而topic又可以切分成若干个悉穗partition来并行处理，并且Kafka0.9后，zk只需要被broker所使用，consumer并不再需要使用zk来记录offset，大大降低zk的压力，同时也从侧面降低了scale的压力。

Kafka也有比较友好的删除策略。可以直接按照max age或者max size自动删除，也可以按照key进行compact，基本上都能满足需求。另一方面，Kafka的社区非常活跃，并且现在几乎所有流行的(流式)计算框架都支持Kafka，如Spark Streaming，Storm，Flink 等。对了，有个叫camus的工具定期可以将Kafka里的数据搬到HDFS上。

2020-11-16-Kafka-3(面试题)

集群硬盘大小：每天的数据量/70% 日志保存天数

机器数量：Kafka 机器数量=2 （峰值生产速度*副本数/100）+1

日志保存时间：可以回答保存7天

监控Kafka：一般公司有自己开发的监控器，或者cdh配套的监控器，另外还有一些开源的监控器

分区数一般设置为：3-10 个

副本数一般设置为：2-3个

topic数量需要根据日志类型来定，一般有多少个日志类型就定多少个topic，不过也有对日志类型进行合并的

LEO：每个副本的最后一条消息的offset

HW：一个分区中所有副本最小的offset

ISR：与leader保持同步的follower集合

AR：分区的所有副本

kafka无法保证整个topic多个分区有序，但是由于每个分区（partition）内，每条消息都有一个offset，故可以保证分区内有序

topic的分区数只能增加不能减少，因为减少掉的分区也就是被删除的分区的数据难以处理

消费者组中的消费者个数如果超过topic的分区，那么就会有消费者消费不到数据

1.维护offset的原因：由于consumer在消费过程中可能会出现断电宕机等故障，consumer恢复后，需要从故障前的位置的继续消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费

消费者提交消费位移时提交的是当前消费到的最新消息的offset+1而不是offset。

Kafka官方自带了压力测试脚本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）， Kafka 压测时，可以查看到哪个地方出现了瓶颈（CPU，内存，网络 IO），一般都是网络 IO 达到瓶颈

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

一个单独的kafka server就是一个broker，broker主要工作就是接收生产者发过来的消息，分配offset，之后保存到磁盘中。同时，接收消费者、其他broker的请求，根据请求类型进行相应的处理并返回响应，在一般的生产环境中，一个broker独占一台物理服务器

接收Producer发过来的数据，并且将它持久化，同时提供给Consumer去订阅

组成Kafka集群节点，之间没有主从关系，依赖ZooKeeper来协调，broker负责消息的读取和存储，一个broker可以管理多个partition

Message

一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成。

header部分由一个字节的magic(文件格式)和四个字节的CRC32(用于判断body消息体是否正常)构成。当magic的值为1的时候，会在magic和crc32之间多一个字节的数据：attributes(保存一些相关属性，比如是否压缩、压缩格式等等)；如果magic的值为0，那么不存在attributes属性。

body是由N个字节构成的一个消息体，包含了具体的搜做差key/value消息。

ISR就是kafka的副本同步队列，全称是In-Sync Replicas。ISR 中包括 Leader 和 Follower。如果 Leader 进程挂掉，会在 ISR 队列中选择一个服务作为新的 Leader。有 replica.lag.max.messages（延迟条数）和replica.lag.time.max.ms（延迟时间胡毕）两个参数决定一台服务是否可以加入 ISR 副 本队列，在 0.10 版本移除了 replica.lag.max.messages 参数，防止服务频繁的进去队列。

任意一个维度超过阈值都会把 Follower 剔除出 ISR，存入 OSR（Outof-Sync Replicas） 列表，新加入的 Follower 也会先存放在 OSR 中。

重点

消费者的分区分配

在Kafka内部存在两种默认的分区分配策略：Range和RoundRobin。当以下事件发生时，Kafka将会进行一次分区分配：

同一个Consumer Group内新增消费者

消费者离开当前所属的Consumer Group，包括关闭或崩溃

订阅的主题新增分区

将分区的所有权从一个消费者移到另一个消费者称为重新平衡（再平衡），如何再平衡就涉及到本文提到的分区分配策略。下面我们将详细介绍Kafka内置的两种分区分配策略。本文假设我们有个名为T1的主题，其包含了10个分区，然后我们有两个消费者（C1，C2）来消费这10个分区里面的数据，而且C1的num.streams = 1，C2的num.streams = 2。

范围策略

一系列策略是对每个主题而言的，首先对同一个主题里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。在我们的例子里面，排完序的分区将会是0,1,2,3,4,5,6,7,8,9;消费者线程排序将会是C1-0，C2-0，C2-1。然后将partitions的个数除于消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。在我们的例子里面，我们有10个分区，3个消费者线程，10/3 = 3，而且除除不尽，那么消费者线程C1-0将会多消费一个分区，所以最后分区分配的结果看起来是这样的：

假如我们有11个分区，那么最后分区分配的结果看起来是这样的：

假如我们有2个主题（T1和T2），分别有10个分区，那么最后分区分配的结果看起来是这样的：

可以看出，C1-0消费者线程比其他消费者线程多消费了2个分区，这就是范围策略的一个很明显的弊端。

RoundRobin战略

必须满足如下条件

同一个Consumer Group里面的所有消费者的num.streams必须相等;

每个消费者订阅的主题必须相同

在我们的例子里面，加入按照hashCode排序完的主题 - 分区组依次为T1-5，T1-3，T1-0，T1-8，T1-2，T1-1，T1-4，T1-7， T1-6，T1-9，我们的消费者线程排序为C1-0，C1-1，C2-0，C2-1，最后分区分配的结果为：

Sticky

分区的分配要尽可能的均匀

分区的分配尽可能的与上次分配的保持相同

当两者发生冲突时，第一个目标优先于第二个目标

数据积压主要可以从两个角度去分析：

idempotent + at least once = exactly once

谈谈你对Kafka幂等性的理解？

Producer的幂等性指的是当发送同一条消息时，数据在 Server 端只会被持久化一次，数据不丢不重，但是这里的幂等性是有条件的：

Kafka是在0.11 版本开始引入了事务支持。事务可以保证 Kafka 在 Exactly Once 语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。

为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer 获得的 PID 和 Transaction ID 绑定。这样当 Producer 重启后就可以通过正在进行的 Transaction ID 获得原来的 PID。

为了管理 Transaction，Kafka 引入了一个新的组件 Transaction Coordinator。Producer 就 是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。Transaction Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于 事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

上述事务机制主要是从Producer方面考虑，对于 Consumer 而言，事务的保证就会相对较弱，尤其时无法保证 Commit 的信息被精确消费。这是由于 Consumer 可以通过offset访问任意信息，而且不同的 Segment File生命周期不同，同一事务的消息可能会出现重启后被删除的情况。

关于kafka面试和kafka面试避免重复消费的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。