Kafka面试典型问题及详细回应

Kafka面试典型问题及详细回应考试时间：______分钟总分：______分姓名：______一、基础概念与架构1.请简述Kafka的核心组件及其主要功能。2.解释Kafka中Topic、Partition和Offset的关系与作用。3.描述Broker在Kafka集群中扮演的角色。二、核心工作原理4.Kafka如何通过其设计实现高吞吐量的？请列举并简述至少三种关键技术机制。5.ZooKeeper在Kafka集群的启动、元数据管理和Broker监控中具体负责哪些任务？6.Kafka默认是如何保证同一生产者发送到特定Partition的消息顺序性的？如果需要跨Partition保证消息顺序，应该怎么做？7.请解释Kafka消息持久化的基本原理，以及它与磁盘I/O操作的关系。8.描述ConsumerGroup在Kafka中的工作机制，以及如何通过GroupID实现消息的广播和订阅模式。三、生产者9.生产者（Producer）的`acks`参数有哪些可选值？（请列出所有值）并简述每个值代表的含义和适用场景。10.当生产者（Producer）配置`enable.idempotence=true`时，Kafka会采取什么机制来保证消息发送的幂等性？这与`retries`参数的配置有何关联？11.消费者（Consumer）的`group.id`参数有什么作用？如果设置为空字符串或`null`，Consumer会以何种方式运行？12.简述KafkaConsumerGroup进行Rebalance的触发条件。当一个Group内的Consumer数量发生变化时，Rebalance过程大致是怎样的？13.消费者（Consumer）提交Offset有两种方式：同步（Sync）和异步（Async）。请比较这两种方式的优缺点。四、数据一致性与可靠性14.为了确保生产者（Producer）端发送的消息不丢失，可以采取哪些配置或机制？（请至少列举三种）15.为了确保消费者（Consumer）端消费的消息不丢失，可以采取哪些配置或机制？（请至少列举三种）16.Kafka默认提供的是哪种消息传递语义（At-Least-Once,At-Most-Once,Exactly-Once）？在什么情况下可能会出现消息重复消费的问题？17.实现Kafka消费端幂等性有哪些常用方法？请至少列举两种。18.Broker端的`replication.factor`参数和`min.insync.replicas`参数分别有什么作用？它们之间有何关系？如何通过这两个参数来提高Kafka的数据可靠性和可用性？五、性能优化与调优19.请列举至少三个可以调整的Broker端参数，用以优化Kafka的消费端性能，并简述调整这些参数的目的。20.如果发现Kafka消息积压严重，导致延迟增大，可以从生产者（Producer）、Broker和消费者（Consumer）三个层面分析可能的原因，并提出相应的优化建议。21.描述`socket.send.buffer.bytes`和`socket.receive.buffer.bytes`这两个参数的作用。增大它们通常会对Kafka的性能产生什么影响？六、故障排查与高可用22.当Kafka集群中的某个Broker宕机时，其负责的Partition会发生什么情况？Kafka如何处理这种故障以保障服务的可用性？23.ConsumerGroupRebalance过程可能会导致哪些问题？如何监控Rebalance的状态并处理Rebalance延迟或失败的情况？24.如果怀疑Kafka系统中存在消息丢失或重复消费的问题，通常会从哪些方面进行排查？（请至少列举三个排查方向）25.请列举至少三种常用的监控Kafka性能和健康状态的关键指标。试卷答案一、基础概念与架构1.答案：Kafka的核心组件包括：*Broker：负责存储消息、处理客户端请求（生产者和消费者），是Kafka集群的基本单元。*Topic：消息的分类主题，生产者发布消息到Topic，消费者订阅Topic。*Partition：Topic内部的分区，用于并行处理和存储消息，提高吞吐量。每个Partition内的消息是有序的。*Offset：每个Partition内消息的唯一标识符，记录了消费者消费到的位置。*Producer：负责生产（发送）消息到Kafka集群。*Consumer：负责从Kafka集群消费（读取）消息。*ZooKeeper（或KRaft模式中的Controller）：负责存储集群元数据（如Topic配置、PartitionLeader信息）、Broker状态、ConsumerGroup信息以及协调Rebalance等任务。*Connect：（虽然题目未明确提及，但属重要组件）用于在Kafka和其他系统（如数据库、存储）之间传输数据，实现数据集成。*SchemaRegistry：（虽然题目未明确提及，但属重要组件，尤其在KSQL或Flink等场景下）用于管理和存储数据模式（Schema）。解析思路：此题考察对Kafka整体架构和核心组件的掌握。需要准确列出所有关键组件，并简要说明每个组件的主要职责。遗漏核心组件（如Broker,Topic,Partition,Offset,Producer,Consumer,ZooKeeper）会失分。2.答案：Topic是消息的逻辑分类，生产者将消息发布到特定的Topic，消费者从特定的Topic订阅消息。Partition是Topic的物理分区，Topic中的消息被分散存储在不同的Partition中。Offset是每个Partition内消息的序号，唯一标识该消息在Partition中的位置。它们的关系是：一个Topic可以包含多个Partition，每个Partition内的消息按顺序编号（Offset）；生产者发送的消息会被追加到指定Topic的某个Partition的末尾；消费者通过指定Topic和Offset来读取Partition中的消息。解析思路：此题考察对Topic、Partition、Offset三者关系的理解。需要清晰阐述它们各自的定义，以及它们如何组合起来实现消息的存储和有序性（在Partition内）。混淆它们的概念或无法说明它们之间的关联会失分。3.答案：Broker是Kafka集群中的节点实例，负责管理一部分Topic和Partition，存储消息数据，并处理来自生产者和消费者的请求。多个Broker组成一个Kafka集群，共同提供高可用性和可伸缩性。Broker承担了数据存储、网络通信、请求处理等核心任务。解析思路：此题考察对Broker在集群中角色的理解。需要说明Broker是集群的基本单元，承担数据存储和处理请求的核心职责，以及Broker集群的概念。二、核心工作原理4.答案：Kafka通过以下机制实现高吞吐量：*批处理（Batching）：生产者可以将多个消息合并成一个批次发送，Broker端也可以合并多个来自同一生产者的请求进行一次磁盘写入，减少了网络和磁盘I/O次数。*零拷贝（Zero-Copy）：在某些情况下（如数据从内核空间直接传送到用户空间，再发送到网络），Kafka利用零拷贝技术减少了数据复制次数，提高了数据传输效率。*顺序写入磁盘：Kafka将消息追加到日志文件末尾，这种顺序写磁盘的方式利用了操作系统的页缓存，效率很高。*多副本复制：数据在多个Broker上复制，提高了读取性能（可以从任意一个LeaderBroker读取）和容错性。*基于日志的架构：顺序读写、索引机制使得Kafka在处理海量数据时效率很高。解析思路：此题考察对Kafka高吞吐量关键技术的理解。需要列举至少三种机制，并简述其原理或作用。只列举一种或描述不清会失分。5.答案：ZooKeeper在Kafka中主要负责：*集群成员管理：维护Broker的列表和状态。*元数据管理：存储Topic、Partition、Replica的配置信息。*Leader选举：选举每个Partition的LeaderBroker。*ConsumerGroup状态管理：存储ConsumerGroup的成员信息和Offset位移。*配置中心：某些Broker端的配置信息也可能由ZooKeeper管理。解析思路：此题考察ZooKeeper在Kafka中的具体作用。需要准确列出其在元数据管理、Leader选举、ConsumerGroup管理等关键任务中的作用。遗漏主要职责或描述不准确会失分。（注意：在KRaft模式下，ZooKeeper不再作为控制器，但此题通常默认指传统模式）6.答案：Kafka默认保证同一生产者发送到特定Partition的消息顺序性，是因为生产者发送到指定Partition的所有消息都会被追加到该Partition对应日志文件的一端，并按顺序赋予Offset。Kafka保证的是*单个Partition内*的消息有序。要跨Partition保证消息顺序，通常的做法是将需要有序处理的消息分散到同一个ConsumerGroup内，并且这些消息需要被发送到同一个Topic下多个Partition中。这样，同一个Group中的Consumer只会消费其中一个Partition的消息，从而间接保证了整个业务流程中相关消息的顺序。解析思路：此题考察Kafka顺序性的保证范围和实现方式。首先要说明默认保证的是Partition内有序。然后要能解释如何实现跨Partition的顺序性，即通过ConsumerGroup和Topic的结合，确保相关消息落在同一个Group且分发给同一个Partition。7.答案：Kafka消息持久化的基本原理是顺序写入日志文件。生产者发送的消息会被追加到指定Partition的日志文件末尾。Kafka使用页缓存（PageCache）来提高写入性能，消息首先写入页缓存，当页缓存填满或达到一定时间后，操作系统会将这些数据顺序写入到磁盘的特定位置。为了进一步保证持久性，Kafka会根据`acks`参数配置将写入操作同步或异步刷写到磁盘。Offset信息也存储在内存和/或磁盘上（取决于配置），记录了每个Partition的消息边界。解析思路：此题考察对Kafka持久性原理的理解。需要说明消息是顺序写入日志文件，利用页缓存，以及涉及磁盘同步的机制（`acks`参数）。解释不清写入过程或与`acks`的关系会失分。8.答案：ConsumerGroup的工作机制是：多个消费者可以组成一个Group来共同消费一个或多个Topic的消息。Kafka通过`group.id`参数来区分不同的ConsumerGroup。当GroupID相同时，订阅了相同Topic的消息会被分发给Group内的Consumer（根据Partition数量和Consumer数量进行负载均衡）。如果GroupID为空或`null`，则该Consumer会以独立消费者的模式运行，它只会消费自己订阅的Topic中，那些尚未被任何Group消费过的消息。解析思路：此题考察ConsumerGroup的核心概念和工作方式。需要解释GroupID的作用，Group内的消息分发机制（负载均衡），以及独立消费者模式的行为。概念混淆或描述不准确会失分。三、生产者9.答案：`acks`参数的可选值为：*`0`：生产者发送消息后不等待Broker的任何确认，性能最高，但可靠性最低，可能丢消息。*`1`：生产者等待LeaderBroker确认收到消息即可，不等待所有FollowerBroker，提供了一定的可靠性（Leader宕机可能丢消息），性能较好。*`-1`（或`all`）：生产者等待Leader和所有ISR（In-SyncReplicas）中的FollowerBroker都确认收到消息后才认为发送成功，可靠性最高，但性能最低。解析思路：此题考察对`acks`参数的理解。需要列出所有三个可选值，并准确解释每个值代表的确认级别和对应的可靠性、性能特点。遗漏值或解释错误会失分。10.答案：当`enable.idempotence=true`时，Kafka会自动为生产者启用幂等性机制。其核心是：Kafka为每个生产者会话（Session）分配一个唯一的序列号（SequenceNumber），并存储在Broker端。对于生产者发送的每条消息，Kafka会为其分配一个单调递增的序列号。生产者会缓存最近发送的消息及其序列号。Broker端会检查接收到的消息的序列号，如果发现序列号比之前收到的某个序列号小或等于，则会拒绝该消息（认为是重复消息），保证消息只被处理一次。这与`retries`参数配合使用：即使消息因为网络等原因重试发送，只要序列号连续，Broker就能识别并丢弃重复的消息，从而实现幂等性。解析思路：此题考察幂等性机制的原理。需要解释序列号的作用、生产者和Broker如何利用序列号来检测重复消息，以及与`retries`参数的协同工作方式。解释不清序列号机制或与`retries`关系会失分。11.答案：`group.id`参数的作用是标识一个Consumer实例所属的ConsumerGroup。如果`group.id`设置为空字符串（`""`）或`null`，则该Consumer不会加入任何Group，它会成为一个独立消费者（IndependentConsumer或SoloConsumer）。独立消费者独立消费消息，它只会消费那些尚未被任何Group消费过的消息（即Offset尚未提交过的消息）。如果多个独立消费者同时存在并订阅同一个Topic，它们会竞争消费该Topic的消息。解析思路：此题考察`group.id`参数的作用和独立消费者模式。需要准确说明`group.id`的作用，解释独立消费者如何运行（消费未消费过的消息），以及其与Group消费模式的不同。12.答案：ConsumerGroup进行Rebalance的触发条件主要包括：*Group内的Consumer数量发生变化（新增、删除、下线）。*Group中的某个Consumer主动`leave`或`subscribe`/`unsubscribe`了一个新的Topic（如果开启了动态订阅）。*Broker端的`group.instance.id`发生变化（通常在Consumer重启后）。*人工触发（例如，使用`kafka-consumer-groups.sh`命令手动触发Rebalance）。Rebalance过程大致是：ControllerBroker收到触发Rebalance的请求后，计算新的Partition分配方案，通知Group中的所有Consumer完成当前消费的Offset，停止旧分配下的消费，根据新分配方案重新开始消费指定Partition的消息，并提交新的Offset。解析思路：此题考察Rebalance的触发条件和过程。需要列举主要的触发条件，并能大致描述Rebalance的流程步骤。遗漏触发条件或过程描述不清会失分。13.答案：同步提交（SyncCommit）是指Consumer在消费完一条消息后，立即等待Broker确认收到Offset提交请求才继续消费下一条消息。优点是Offset提交可靠，几乎不会丢失Offset导致消息重复消费。缺点是阻塞Consumer，降低消费吞吐量，Consumer性能受Broker响应影响。异步提交（AsyncCommit）是指Consumer在消费完一条或一批消息后，不等待Broker确认，就立即提交Offset，然后继续消费下一条消息。优点是不阻塞Consumer，提高了消费吞吐量。缺点是如果Consumer或Broker在提交Offset之前发生故障，可能会导致部分消息丢失（Offset未提交，消息已消费但未记录Offset）或消息重复消费（Offset提交了，但消息丢失了）。解析思路：此题考察同步和异步Offset提交的区别。需要分别说明两种方式的操作流程、优点和缺点，并能进行比较。四、数据一致性与可靠性14.答案：确保生产者端消息不丢失的配置或机制包括：*设置合适的`acks`参数：使用`acks=-1`（`all`）确保消息被所有ISRBroker确认。*配置生产者幂等性：设置`enable.idempotence=true`，防止消息重试导致的重复处理。*配置生产者事务性：启用事务性（需要Broker和Consumer都支持事务），通过事务保证发送消息和提交Offset的原子性。*保证Broker可用性和副本数量：确保Broker数量足够，并且Topic的`replication.factor`设置合理（通常大于等于3），`min.insync.replicas`设置适当（大于1），这样即使部分Broker宕机，消息仍然有副本可用，且写入需要一定数量的副本确认。解析思路：此题考察生产者端保证消息不丢失的方法。需要列举至少三种，涵盖生产者端配置（`acks`,幂等性,事务）和集群配置（副本数,`min.insync.replicas`）。只列举一种或方法不当会失分。15.答案：确保消费者端消息不丢失（即不丢失消费过的消息的处理结果）的配置或机制包括：*Consumer幂等性：对于需要保证业务幂等性的场景，配置Consumer幂等性（通过设置`mit=true`并利用Kafka的幂等性机制，或自行实现幂等逻辑）。*Consumer事务性：如果Consumer也需要支持事务（例如，与数据库操作结合），需要启用Consumer事务，确保消费消息和更新本地状态（如Offset或业务状态）的原子性。*正确提交Offset：确保消费完消息后，Offset能够正确提交。对于关键业务，避免使用`mit.enable=true`，改为手动提交（`mit.enable=false`），并在确认业务处理成功后再提交Offset。*保证消费者稳定：确保Consumer应用稳定运行，避免频繁崩溃或网络中断，否则可能导致Offset提交失败，造成消息重复消费（如果处理逻辑非幂等）。解析思路：此题考察消费者端保证消息不丢失（指业务处理结果不丢失）的方法。需要区分是防止消息丢失还是防止因消费导致业务状态不一致。需要列举至少三种方法，涵盖Consumer端配置（幂等性,事务,手动提交Offset）和Consumer应用稳定性。混淆概念或方法不当会失分。16.答案：Kafka默认提供的是At-Least-Once消息传递语义。在这种语义下，Kafka保证至少将消息成功交付给消费者一次，但可能会重复交付。出现消息重复消费的原因主要是生产者重试机制。当生产者发送消息后，如果因为没有收到Broker的确认（`acks`设置不够高）或者网络问题而认为发送失败，它会自动进行重试。如果消费者在第一次消费并处理了消息后崩溃，或者Offset提交失败，当生产者重试发送相同的消息时，Consumer再次消费到这条消息，就导致了重复消费。解析思路：此题考察Kafka默认的传递语义及其产生重复的原因。需要首先说明默认是At-Least-Once。然后要能解释为什么会产生重复，即生产者重试与消费者状态管理（崩溃或Offset提交失败）结合的结果。17.答案：实现Kafka消费端幂等性的常用方法有：*利用KafkaConsumer幂等性机制：当`enable.idempotence=true`时，Kafka会自动为生产者启用幂等性，Consumer端无需额外配置，即可在一定程度上防止因生产者重试导致的重复消费（Broker会拒绝重复序列号的消息）。*在Consumer端实现幂等逻辑：对于不支持幂等性机制的Consumer或需要更细粒度控制的情况，可以在Consumer端实现幂等逻辑。例如，使用数据库唯一约束、分布式锁、Redis等存储已处理的消息ID或业务key，在消费消息前检查是否已处理过。解析思路：此题考察Consumer端幂等性的实现方式。需要列举至少两种方法，一种是Kafka提供的内置机制，另一种是常见的应用层解决方案。只列举一种或方法不正确会失分。18.答案：`replication.factor`参数指定一个Topic的副本数量。它决定了数据的冗余程度和可用性。`min.insync.replicas`参数指定生产者发送消息时，Broker必须确认至少多少个副本（包括Leader和ISR中的Follower）成功写入消息，才认为发送成功。设置这两个参数可以提高数据可靠性：*`replication.factor`：数值越高，数据冗余越多，即使部分Broker宕机，数据仍然可用（由其他副本提供），但会降低写入性能（需要同步到更多副本）。通常设置大于等于3。*`min.insync.replicas`：数值越高，数据写入的可靠性越高（防止Leader挂掉后数据丢失），但对写入性能影响越大（需要等待更多副本确认）。通常设置大于1（例如2或3），结合`replication.factor`来配置。解析思路：此题考察`replication.factor`和`min.insync.replicas`的作用及关系。需要分别解释两个参数的含义和作用，并说明它们如何协同工作来提高可靠性和可用性。解释不清或关系描述错误会失分。五、性能优化与调优19.答案：可以调整的Broker端参数优化消费端性能的有：*`fetch.min.bytes`：指定Consumer端拉取数据时，Broker端至少需要积累这么多字节数据才触发一次拉取。设置较大的值可以减少Consumer的请求频率，但会增加Consumer的延迟。*`fetch.max.wait.ms`：指定Consumer端拉取数据时，Broker端最多等待这么长时间才发送数据给Consumer。增大此值可以在网络状况不佳或数据较少时，减少Consumer的请求频率，但同样会增加延迟。*`fetch.max.bytes`：限制单次拉取请求最多返回的数据量。合理设置可以避免Consumer端内存溢出，并根据Consumer处理能力调整单次拉取量。*调整网络参数：如`socket.receive.buffer.bytes`,`socket.send.buffer.bytes`，增大这些值可以提高网络传输效率。解析思路：此题考察Broker端可调参数对消费性能的影响。需要列举至少三个相关的参数，并说明调整它们的目的（通常是为了平衡延迟和吞吐量，或与Consumer端参数配合）。遗漏参数或目的描述不清会失分。20.答案：Kafka消息积压导致延迟增大的原因及优化建议：*原因分析：*消费端处理能力不足：Consumer的处理速度跟不上生产者发送的速度。*Broker端资源不足：Broker的CPU、内存、磁盘I/O或网络带宽瓶颈。*Topic分区数不足：消费端并行度不够，所有消息集中在少数几个Partition上。*单个Partition数据量过大：消费端拉取数据量过大，处理时间过长。*网络问题：生产者或消费者与Broker之间的网络延迟或丢包。*配置不当：如Consumer的`fetch.min.bytes`或`fetch.max.wait.ms`设置过小，导致拉取过于频繁；生产者批处理大小设置过小。*优化建议：*提升消费端处理能力：优化Consumer代码，增加Consumer实例数量（在Topic分区足够的情况下），使用更强大的硬件。*提升Broker端资源：增加Broker的数量，提高单个Broker的硬件配置（CPU、内存、磁盘、网卡）。*增加Topic分区数：将Topic划分更多Partition，提高并行度，让更多Consumer并行消费。*调整Consumer拉取配置：合理设置`fetch.min.bytes`和`fetch.max.wait.ms`，避免过于频繁的拉取。*调整生产者配置：增大生产者批处理大小（`linger.ms`,`batch.size`），减少网络请求次数。*优化网络：保证生产者与Broker、Consumer与Broker之间的网络质量。*监控关键指标：监控Broker的队列大小（`log.dirsunderfilesystem.max.file.descriptors`）、Consumer的延迟、网络吞吐量等。解析思路：此题考察对消息积压问题的分析和解决能力。需要从生产者、Broker、Consumer、网络、配置等多个角度分析原因，并提出针对性的优化建议。分析不全面或建议无效会失分。21.答案：`socket.send.buffer.bytes`和`socket.receive.buffer.bytes`是JavaSocket的选项，用于设置Socket的发送和接收缓冲区大小。*`socket.send.buffer.bytes`：设置Socket发送缓存区的大小。增大此值可以提高数据从应用程序内核空间发送到网络协议栈的效率，特别是在发送大数据块时，可以减少系统调用的次数。对于Kafka生产者发送消息到Broker的网络传输有帮助。*`socket.receive.buffer.bytes`：设置Socket接收缓存区的大小。增大此值可以提高数据从网络协议栈接收到的应用程序内核空间的效率，特别是在Broker接收来自生产者的消息或向消费者发送拉取的数据时，可以减少网络接收中断的次数，提高吞吐量。*影响：增大这两个值通常会提高网络传输的吞吐量，但也会占用更多的系统内存资源。需要根据网络带宽、消息大小和系统资源情况合理调整。过小可能导致网络传输效率低下，过大可能耗尽系统内存。解析思路：此题考察JavaSocket缓冲区参数的作用。需要分别解释两个参数的含义和作用，并说明增大它们对Kafka网络传输性能的影响以及需要考虑的因素（内存占用）。解释不清或作用描述错误会失分。六、故障排查与高可用22.答案：当Kafka集群中的某个Broker宕机时：*该Broker负责的Partition（如果它曾是Leader）会发生Leader选举。ZooKeeper会负责选举新的LeaderBroker（通常从原Follower中选举）。*新的LeaderBroker会接管该Partition的读写请求。*其他原FollowerBroker会与新Leader建立连接，并开始同步该Partition的数据。*如果原宕机Broker在一段时间后恢复，它会重新加入集群，并成为该Partition的Follower，继续同步数据。*整个过程由Kafka内部的副本管理机制和ZooKeeper协调完成，目的是保证Partition的可用性和数据的冗余存储，从而保障了整个服务的可用性（至少对于该Partition）。解析思路：此题考察Broker宕机时的处理机制。需要描述Leader选举、数据同步、Broker恢复等关键步骤，以及这些步骤如何保证Partition的可用性和数据冗余。描述不清或遗漏关键环节会失分。23.答案：ConsumerGroupRebalance可能导致的问题：*消费延迟增加：在Rebalance过程中，Consumer需要停止旧Partition的消费、等待新的分配、重新连接Broker并从新的Offset开始消费，这期间会有消费延迟。*短暂消费中断：Consumer在等待新分配或重新启动后，可能会经历短暂的消费中断。*消息重复或丢失（如果处理不当）：如果Rebalance过程中Consumer没有正确处理Offset提交，或者应用逻辑不能处理短时间内重复消费的消息，可能导致消息丢失或重复。*资源压力：Rebalance过程需要ZooKeeper和Broker端进行大量的协调和通信，对集群资源有一定压力。*触发条件不当：如果Rebalance被频繁触发或不必要的触发，会增加系统开销和消费延迟。处理Rebalance状态和问题：*监控：监控Rebalance相关的指标（如`rebalance.partitions`,`rebalance.inprogress.partitions`），以及Consumer端的延迟和状态。*优化Rebalance触发条件：避免不必要的Rebalance，例如，对于稳定的ConsumerGroup，可以禁用动态订阅。*优化Rebalance过程：调整Rebalance策略参数（如`group.instance.id`），优化Consumer端代码以快速完成Rebalance过程。*Consumer端处理：确保Consumer代码能够妥善处理Rebalance过程中的Offset提交和消费逻辑。解析思路：此题考察Rebalance的副作用及处理方法。需要先列举Rebalance可能导致的问题，然后针对问题提出监控、优化触发条件、优化过程和Consumer端处理等建议。问题列举不全或建议无效会失分。24.答案：如果怀疑Kafka系统中存在消息丢失或重复消费问题，可以从以下方面排查：*检查副本状态和配置：验证Topic的副本数(`replication.factor`)是否足够，`min.insync.replicas`是否设置合理，Broker的ISR列表是否正常，以及副本同步延迟(`replica.lag.time.max.ms`)是否过高。*检查生产者配置：查看`acks`参数设置，确认生产者是否启用了幂等性(`enable.ide