众人拾柴火焰高，这里贴个本面经的共享在线文档，大家可以自由编辑，共同丰富题库。整理不易，来个关注+收藏+点赞呗[狗牛头]在线文档：    Hadoop面试大全    HBase面试大全    Kafka面试大全-----------------------------------------分界线-----------------------------------------1.消息队列1.1 消息队列的好处解耦：允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束可恢复性：系统的一部分组件失效时，不会影响到整个系统缓冲：有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它灵活性 & 峰值处理能力1.2 消息队列的两种模式点对点（一对一）发布/订阅（一对多）1.3 生产者消费者模式与发布订阅模式有何异同?    相同：都是一端生产数据，一端消费数据    不同：生产者-消费者，同一类别下，消费者拿到的都是一样的数据；发布-订阅，订阅者只拿自己感兴趣的数据。1.4 Kafka作为消息队列，能够解决什么问题（1）增加数据可靠性和持久性：采用了分布式复制机制，将消息副本分布到不同的Broker节点上，并确保故障发生时的数据可恢复性。（2）高吞吐量和低延迟：处理大量的消息并能够提供毫秒级的延迟，适用于实时数据流处理和高负载场景。（3）分布式流处理：Kafka不仅仅是一个消息队列，还是一个流处理平台。它支持对数据流进行实时处理、转换和聚合，可以构建复杂的流处理应用程序。（4）水平扩展和负载均衡：通过增加Broker节点来处理更多的消息和请求。（5）数据持久化和回溯能力：将消息持久化存储在磁盘上，保证数据的可靠性和持久性。1.5 Kafka相比于其它消息组件有什么好处高性能：单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作，Kafka性能远超过传统的消息队列可扩展性：提供透明扩展，增加新的服务器进集群容错性：每个分区有多个副本保障数据安全性持久性：提供数据的磁盘存储2.Kafka是什么Kafka是一种分布式流处理平台，可以处理大规模动作流数据，主要应用于大数据实时处理，具有高吞吐量、低延迟和持久化的特点。3.介绍下Kafka的作用以及使用场景主要作用有：（1）消息传递系统；因为它具有高吞吐量和低延迟的特点，能够在分布式系统中可靠地传输大量数据消息。（2）流处理平台：Kafka支持实时数据流处理，在数据流中进行转换、聚合和分析，并将结果输出到其他系统中。（3） 存储系统；Kafka可持久化存储，可以将数据持久保存在磁盘上，以便进行后续的处理和分析。基于以上作用，可以应用于日志的收集聚合、实时检测分析系统、消息队列、事件驱动架构等场景。4.Kafka的组件有哪些Producer：生产者，就是向kafka broker发消息的客户端。Consumer：消费者，向kafka broker取消息的客户端。Consumer Group：消费者组，由1个或n个consumer组成，消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。Broker：一台kafka服务器就是一个broker。Topic：消费主题，可以理解为一个队列，生产者和消费者面向的都是一个topic。Partition：为了实现扩展性，一个topic可以分为多个partition，分布到多个broker（即服务器）上。Replication：为了实现Partition的可靠性，一个Partition会保留多个Replication，分为一个leader和若干个follower；其中leader是Producer发送数据的对象，以及Consumer消费数据的对象。Zookeeper：用于leader选举和follower信息同步、Broker的管理、Topic维护、生产者负载均衡、消费者负载均衡，在0.9版本之前还存储Customer的消费的offset。5.讲下Kafka的整体结构Kafka由生产者、Broker集群和消费者组成。其中消息以Topic分类，每个Topic可以看做是一个队列，为提高其扩展性、安全性以及并发能力，每个Topic由多个Partition组成。每个Partition有多个副本，分为leader和follower，leader负责读写，follower与leader数据保持同步，以做容错作用。同时为了防止文件过大，partition分为了多个segment，每个segment由一个.index文件和.log文件组成，存储在同一个文件夹：topic名字-分区号。消费者则是以组为单位消费数据，消费者组内的消费者消费不同的Partition，每个Partition只能组内一个消费者消费，消费者组之间互不影响，消费者会记录每一次消费的offset。同时还有zookeeper提供broker管理，topic管理，leader选举等服务。6.Kafka的优缺点6.1 优点（1）吞吐量高，单机TPS约在百万条/秒（2）时效性高，毫秒级（3）可用性高，每个数据有多个副本（4）消费者采用pull方式，通过控制能保证所有消息精准一次消费（5）在日志领域比较成熟6.2 缺点（1）队列越多，load时间越长，发送消息响应时间变长。（2）使用轮询方式时，实时性取决于轮询间隔时间。（3）相对较大的存储需求：支持持久性，并且为了保证高可靠性，数据有多个副本，因此需要较大的存储容量。（4）不适用小规模数据：kafka结构较为复杂，对于小规模应用而言，显得复杂笨重。（5）数据顺序保证局限性：保证了同一分区内消息的顺序性，但对于跨分区的消息顺序性无法保证。7.Kafks的单播和多播单播：一条消息只能被同一个消费者组中的一个消费者消费多播：一条消息能被多个消费者组中的消费者共同消费8.Kafka的HW和LEOLEO (Log End Offset)：LEO 是指当前分区中日志的最高偏移量。HW (High Watermark)：HW 是指消费者组能够读取的最大偏移量。每个副本（leader/follow）都会有自己的LEO，表示当前自身数据的最大偏移量，HW则表示目前该分区对消费者组可见的最大偏移量，取的是所有副本的最小LEO（木桶原理），除了保存自身LEO外，还保存了其他follower的LEO，一般称为副本LEO。概念作用每个角色更新时机LEO副本写入下一条消息的位移值leader接受到生产者消息落盘后follower从leader拉取消息落盘后远程副本（leader存储）follower从leader拉取消息时，会告诉leader拉取起始位置，即为该值HW定义消息可见性帮助kafka完成副本同步leader自身更新LEO后更新完远程副本的LEO后follower自身LEO更新完后，取min(LEO,HW)9.Kafka数据的一致性如何保证每个副本都有一个HW和一个LEO，LEO是每个副本末端偏移量，HW则是表示该Partition对外服务的最大位移量（木桶原理，木桶装多少水取决于最短的木板有多长）。10.Kafka的leader挂掉之后的选举过程Kafka中leader的选举由controller管理。旧的leader挂掉后，被Zookeeper监听到，注销掉相应节点，通知controller开始选举新的leader。首先确定挂掉的leader的ISR队列中有哪些follower，这些follower抢占式在Zookeeper创建节点，谁先创建谁作为新的leader，所有follower删除HW以上的消息，重新向新的leader同步数据。11.Kafka的ISR、OSR和ARISR(InSyncRepli)：内部副本同步队列；OSR(OutSyncRepli)：外部副本同步队列；AR(AllRepli)：所有副本；AR = ISR + OSR；任意一个超过延迟时间或延迟条数阈值的follower都会被剔除出ISR, 存入OSR列表，新加入的follower也会先存放在OSR中。12.说下Kafka的ISR机制为避免因某个副本的follower故障不能同步数据而造成leader一直等待，leader维护了一个列表，为保持同leader同步的follower集合，该集合中副本和leader相差数据不超过一个阈值（可设置），超出一定时间数据未达到该阈值，则follower会被踢出ISR。ISR主要在leader出现故障后作为选举新leader的备用池。13.Kafka的ack有几种值三种：0 - 生产者向leader发送数据后即视为leader已经成功接收数据登上，有数据丢失风险1 - leader接收数据写入后，向生产者发送确认信息。如果leader返回ack后还未向follower同步消息而挂掉，会造成数据丢失情况。-1/all - leader收到数据后，向所有follower发送数据，等所有follower数据罗盘后再向生产者回复确认信息。如果follower同步完消息还未向生产者发送确认信息时leader挂掉，则可能数据重复。14.Kafka怎么保证数据不重复（at-most-noce语义）生产者：Kafka存在幂等性机制，Produce初始化时会有一个PID，向同一个partition发送数据时会带有一个sequence number，borker端会对<PID，partition, seq>缓存起来，produce多次发送时，broker会保证只消费一条数据。但只能保证在同一会话中有效。消费者：将消费过程和提交offset过程做原子绑定，保存到支持事务的自定义介质中（比如MySQL）。15.Kafka怎么保证数据不丢失（at-least-once语义）生产者：ack设为-1/all消费者：设置消费者手动提交offset同上个问题合并就保证了exactly-one语义16.Kafka有哪些分区策略（1）RoundRobin(轮询)kafka默认策略，对所有分区和所有消费者循环分配，分区更均衡。（2）Range(平均)以Topic为单位，以数据顺序排列可用分区，以字典顺序排列消费者，将topic分区数除以消费者总数，以确定分配给每个消费者的分区数；如果没有平均分配，那么前几个消费者将拥有一个额外的分区。（3）Sticky（粘性分配，0.11后出现）当触发重新分配时（消费者组中消费者数量发生变化），尽可能保留现有分配，将已经终止的消费者所分配的分区移动到另一个消费者，避免全部分区重新平衡，节省开销（不知道这个的小伙伴可以找下相关例子，这里座作为面试回答，不做详细讲解）。17.Kafka的消费者组是如何消费数据的（1）一个消费者组有n个消费者（2）一个消费者组内，一个分区只能由一个消费者消费（3）一个消费者组，所有消费者组合起来消费一个Topic下所有分区（4）一个消费者组内，一个消费者可消费多个分区（5）分区通过分配算法分配给一个组内的消费者，消费者消费时会有一个offset来保存自己的消费位置18.Kafka的offset管理  0.9版本之前zookeeper管理，0.9之后由kafka在broker中名为__consumer_offsets的topic中19.消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1？offset+120.有哪些情形会造成重复消费？消费者消费后没有提交offset(程序崩溃/强行kill/消费耗时/自动提交偏移情况下unsubscrible)。21.有哪些情形会造成消息漏消费？消费者没有处理完消息就提交offset(自动提交偏移 未处理情况下程序异常结束)。22.当你使用kafka-topics.sh创建（删除）了一个topic之后，Kafka背后会执行什么逻辑？创建：在zk上/brokers/topics/下创建一个新的topic节点，然后触发Controller的监听程序，kafkabroker会监听节点变化创建topic，kafka Controller 负责topic的创建工作，并更新metadata cache删除：调用脚本删除topic会在zk上将topic设置待删除标志，kafka后台有定时的线程会扫描所有需要删除的topic进行删除，也可以设置一个配置server.properties的delete.topic.enable=true直接删除23.topic的分区数可不可以增加/减少？只能增加，不能减少。24.Kafka为什么同一个消费者组的消费者不能消费相同的分区?kafka的offset不是为单个消费者存的，是为消费者组存的groupid-topic-partition -> offset25.如果有一条offset对应的数据，消费完成之后，手动提交失败，如何处理?可以给offset提交设置失败后重复提交，如果依旧提交失败，就要进行人工干预了26.正在消费一条数据，Kafka挂了，重启以后，消费的offset是哪一个先看current-offset，再看auto.offset.resetcurrent-offset表示消费者消费了数据之后提交的offset；auto.offset.reset表示消费者在初始化或偏移发生故障时的起始位置。current-offsetauto.offset.reset开始位置unknownearliest从该分区当前最开始的offset消息开始消费latest只消费当前消费者启动完成后生产者新生产的数据none启动消费者时，该消费者所消费的主题的分区没有被消费过，就会抛异常knownearliest/latest/none不考虑auto.offset.reset配置，直接从current-offset一直消费到log-end-offset。也就是不会更新offset。27.为什么需要消费者组?性能：为了实现水平扩展和提供高吞吐量的消息处理能力灵活：不同的组合方式，可以实现不同的效果，比如每个消费者组只有一个消费者，同时消费一个主题，可以实现订阅-广播模式容灾：如果只有一个消费者，出现问题就是灾难性的；消费者组的话，组内消费者出现问题，它的消费任务，可以被分配到其他消费者。28.Kafka producer的写入数据过程?（1）创建ProducerRecord（以下记为PR）对象，包含Topic和要发送的内容，还可以指定key或分区。（2）调用拦截器来对消息进行相应的定制化操作。（3）发送PR时，生产者先把key-value序列化成字节数组，这样才能在网络上传输。（4）数据被传给分区器，如果有key，则按照hash返回分区，如果没有key，则按照某种策略（默认轮询）。（5）选好分区后，信息被添加到一个记录的批次里（Segment），这个批次里的所有消息都会被发送的相同的主题分区上，Broker 会为消息生成一个 Offsets（在 Partition 内唯一标识消息的数字），Producer 可以通过检查 Offsets 来确认消息是否已被正确写入 Kafka Topic。（6）如果发送消息的过程中出现错误或异常，Producer 可以选择重试、忽略或处理失败。29.Kafka读取消息Pull模式的优缺点优点：灵活控制消费速率；批量拉取提高效率。缺点：需要消费者不断进行主动拉取，会增加网络负担；消费者长时间不拉取或拉取速度过慢情况下，可能导致信息阻塞。30.Kafka高可用体现在哪里（1）消息中间件副本机制。（2）ISR只有与leader数据相差在阈值以内的副本才有可能被选为leader。31.Kafka的生成者客户端有几个线程?（1）主线程负责初始化和设置 Producer 的配置，创建 KafkaProducer 实例，并处理用户发送的消息等。主线程还负责管理其他后台线程。（2）IO线程负责与 Kafka Broker 进行网络通信，将消息发送到指定的主题分区。（3）超时检测线程通过参数设置。32.Kafka连接Spark Streaming的几种方式以及适用场景（1）KafkaUtils适用于数据的吞吐量要求不是很高，且不需要精确控制分区读取和处理。（2）Direct允许直接从 Kafka 分区读取数据，并将其作为 RDD 在 Spark Streaming 中进行处理；适用于高吞吐量，低延迟的场景，可以实现精准分区读取和负载均衡（3）Receiver通过在 Spark Streaming Application 中创建 Kafka Receiver 来读取 Kafka 数据，并将其作为 DStream 在 Spark Streaming 中处理；适用于低吞吐量且对数据处理的可靠性要求较高的场景，通过数据复制和容错机制来保证数据处理的可靠性。（4）结合 Spark Structured Streaming 和 KafkaSpark 2.0 及以上版本引入了 Structured Streaming，可以直接集成 Kafka，并使用高级的结构化 API 处理流数据；适用于需要更复杂的流数据处理逻辑和数据转换的场景。33.说一下Kafka的分区器、拦截器、序列化器?依次顺序：拦截器、序列化器、分区器拦截器：用来在消息发送前做一些准备工作，如过滤，修改，定制化。序列化器：将key和value序列化成字节数组，以便进行网络传输。分区器：如果制定了partition字段，就不需要分区器作用；默认调用两个方法，partition(~)方法，参数分别表示主题、键、序列化后的键、值、序列化后的值以及集群的元数据信息，返回值为分区号；close()方法，关闭分区器并回收一些资源。34.Kafka在哪些地方会有选举过程，使用什么工具支持选举?角色说明选举过程controller在 ZooKeeper 的帮助下管理和协调整个 Kafka 集群，集群中的每个 broker 都可以成为 controller，但是在 Kafka 集群启动后，只有一个 broker 会成为 Controller。第一个启动的broker通过在ZooKeeper里创建一个临时节点 /controller 让自己成为controller，其他broker创建时发现已经存在节点，则注册一个zookeeper的watch对象，如果/controller发生变化，其他broker则收到通知leader副本的leader选举unclean.leader.election.enable参数为false时，在ISR中选择一个作为新的leader，一般leader有一个首选副本ISR为空时，允许从OSR中选择副本作为leader消费者组leader群组协调器是一个能够从消费者群组中收到所有消费者发送心跳消息的 broker第一个加入消费组的消费者即为消费组的leader35.Kafka蓄水池机制Produce的生产主要是一个producer线程和sender线程，通过BatchQueue来获取数据，过程是异步的，因此称为蓄水池。36.Kafka分区分配算法如果指定了partition key，然后根据其hash分区，如果没有指定key，则采用轮询方法，除此之外还可以自定义分区规则。37.Kafka中的数据能彻底删除吗?可以。过程：（1）topic 此时正在生产或消费的话，则这些生产和消费程序需要停止；（避免topic的offset信息一直在broker更新。调用kafka delete命令则无法删除该topic）（2）设置 auto.create.topics.enable = false；（该值为true时，produce或者fetch不存在的topic会自动创建这个topic。）（3）server.properties 设置 delete.topic.enable=true；（如果没有设置，则调用kafka 的delete命令无法真正将topic删除，而是显示（marked for deletion））（4）调用命令删除topic：./bin/kafka-topics  --delete --zookeeper 【zookeeper server:port】  --topic 【topic name】（5）删除kafka存储目录（server.properties文件log.dirs配置，默认为"/data/kafka-logs"）相关topic的数据目录。（6）如果还未删除干净在zk节点登录zk shell，找到topic所在目录rmr /brokers/topics/【topic name】（7） 完成后使用命令./bin/kafka-topics.sh --list --zookeeper 【zookeeper server:port】查看如果还可以看到，重启kafka和zk即可38.Kafka监控实现工具：（1）JMX实现可通过JConsole、VisualVM 等查看Broker、Topic、Partition、Consumer Group 等的各项指标。（2）Kafka 自带的监控工具（3）日志文件的监控监控方向：消费者：存活告警，消费滞后告警生产者：存活告警，生产者消费上游数据能力告警broker：存活告警，流量告警，isr列表，topic异常告警，control变换告警39.Kafka的一条message中包含了哪些信息?定长的Header：校验码，消息属性，时间戳等变长的Body：数据40.Kafka是如何清理过期文件的?方法：根据已保存时间；根据log设置的max size。过程：定期检查每个log段的最大时间戳/文件大小；达到阈值的添加删除标记；整个log消费完后，在后台进程执行真正的删除操作。41.为什么Kafka不支持读写分离？在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从而实现的是一种主写主读的生产消费模型。不采用读写分离是因为两点原因：（1）数据一致性问题数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间 窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。（2）延时问题类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经 历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节 点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。42.Kafka为什么那么快（1）顺序写（2）PageCache缓存（3）批量以流的形式传输消息，速度可达网络上限（4）Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。（5）零拷贝技术零拷贝技术扩展：平时应用程序读取磁盘数据时，服务器先切换为内核态读取文件，再切为用户态将文件复制到用户缓存，写入Socket时，要再切到内核态发往网卡。零拷贝技术在磁盘数据被读到内核区缓存中时，操作系统将这块缓存直接共享给应用程序（少一次复制），用户程序调用write，直接把数据拷贝到Socket