目录
24、kafka中数据挤压太多，怎么办？（提高消费者的效率）
25、Kafka中的数据在消费过程中，有漏消费和重复消费的情况，怎么办？
26、kafka中的数据已经消费过的数据，是否可以再次消费？怎么做？
前15问博客链接：大数据面试题--kafka夺命连环问-CSDN博客
16、kafka是如何做到高效读写？
Kafka 实现高效读写主要依赖于以下几个关键机制：
（一）分区技术与并行处理
Kafka 作为分布式集群，采用分区技术将主题划分为多个分区。每个分区可分布在不同节点，生产者能并行向各分区写入数据，消费者组内多个消费者也可同时从不同分区读取数据，极大提升了系统的并行度和吞吐量。例如，一个主题有多个分区，不同的生产者线程或进程可针对不同分区独立发送消息，而多个消费者可并行处理不同分区的数据，避免了单点瓶颈，充分利用了集群资源。
（二）稀疏索引与快速定位
在数据存储方面，Kafka 使用稀疏索引。这种索引并非对每条数据都建立索引项，而是按照一定间隔建立，从而在减少索引存储空间的同时，仍能快速定位数据大致范围。当需要读取特定 offset 的数据时，先通过稀疏索引确定数据所在的 segment 范围，然后在该 segment 内进一步查找，显著提高了数据定位速度，相比全量索引方式，大大减少了索引维护成本和查找时间开销。
（三）顺序写磁盘优化
Kafka 的生产者写入数据到 log 文件时采用顺序写机制，即数据始终追加到文件末尾。由于磁盘的物理特性，顺序写相较于随机写可省去大量磁头寻址时间。实验数据表明，相同磁盘上顺序写速度可达 600M/s，而随机写仅约 100K/s。这种顺序写方式充分利用了磁盘的顺序读写性能优势，使得 Kafka 在数据写入方面表现卓越，即使面对高并发写入场景，也能高效处理。
（四）页缓存与零拷贝技术协同
零拷贝原理与优势：Kafka 利用零拷贝技术，将数据在网络传输过程中的拷贝次数和上下文切换次数降至最低。数据无需在应用层进行多次不必要的拷贝，而是直接在内核缓冲区之间进行传输，从磁盘读取的数据可直接通过网络接口发送给消费者，减少了 CPU 和内存资源的消耗，提高了数据传输效率。
PageCache页缓存机制与作用：Kafka 重度依赖操作系统的页缓存功能。当数据写入时，操作系统首先将数据写入页缓存，而非立即写入磁盘。读取数据时，优先从页缓存中查找，如果命中则直接返回数据，避免了磁盘 I/O 操作。只有当页缓存中的数据达到一定阈值或需要持久化时，才会将数据同步到磁盘。这种机制将内存作为磁盘缓存使用，充分发挥了内存的高速读写特性，进一步提升了数据读写性能，类似于 MySQL 中的 buffer pool 机制，有效减少了磁盘访问次数，提高了整体系统性能。
17、Kafka集群中数据的存储是按照什么方式存储的？
Kafka 数据存储基于 Topic 和 Partition 概念展开：
（一）基于 Topic 和 Partition 的存储结构
Topic 是逻辑上对消息的分类，而 Partition 是物理存储单元。每个 Partition 对应一个 log 文件，生产者生成的数据会被顺序追加到所属 Partition 的 log 文件末端。例如，对于名为 "first" 的 Topic，可能存在 "first - 0"、"first - 1" 等多个分区，每个分区文件夹下包含了与该分区相关的多种文件，如 ".index" 索引文件、".log" 日志文件以及 ".timeindex" 时间索引文件等。这些文件共同构成了分区的数据存储体系，确保数据的有序存储和高效检索。
（二）分片和索引机制详解
为应对 log 文件可能过大导致的数据定位效率低下问题，Kafka 引入了分片和索引机制。每个 Partition 被划分为多个 segment，每个 segment 包含上述提到的各类文件。其中，索引文件起到了关键作用，它通过建立数据偏移量与物理存储位置的映射关系，使得在读取数据时能够快速定位到指定 offset 的数据在日志文件中的位置。例如，当需要读取某个 offset 的数据时，可先通过索引文件快速确定其所在的 segment，然后在该 segment 的日志文件中准确获取数据，无需对整个 log 文件进行顺序扫描，极大提高了数据读取效率，尤其在处理大规模数据时优势更为明显。
18、kafka中是如何快速定位到一个offset的。
Kafka 主要通过稀疏索引机制来快速定位 offset：
（一）稀疏索引原理
Kafka 存储数据时采用稀疏索引方式，并非对每条数据都建立索引，而是按照特定间隔建立索引项。这样在查找 offset 时，首先根据索引项快速定位到数据所在的大致 segment 范围。例如，索引可能每隔一定数量的消息记录建立一个索引项，当查询特定 offset 时，通过比较 offset 与索引项的大小关系，能够迅速确定目标数据所在的 segment。
（二）使用工具查看索引和日志信息辅助定位
Kafka 提供了kafka - run - class.sh kafka.tools.DumpLogSegments工具，可用于查看.index和.log信息。通过该工具，可以深入了解索引文件中索引项与日志文件中数据的对应关系，进一步辅助确定特定 offset 数据的精确位置。例如，在排查数据问题或进行数据恢复时，可利用该工具详细分析索引和日志内容，准确找到所需 offset 对应的消息数据，从而实现对数据的精准定位和处理。
19、简述kafka中的数据清理策略。
Kafka 提供了两种主要的数据清理策略：
（一）delete 日志删除策略
基于时间的删除机制：Kafka 默认开启基于时间的 delete 策略。它以 segment 中所有记录的最大时间戳作为该文件的时间戳判断依据。当该时间戳超过设定的日志保存时间时，该 segment 将被删除。可以通过调整参数log.retention.hours（最低优先级小时，默认 7 天）、log.retention.minutes（分钟，如果设置则小时设置不起作用）、log.retention.ms（最高优先级毫秒，如果设置则分钟设置不起作用）来灵活修改日志保存时间，同时log.retention.check.interval.ms参数负责设置检查周期，默认 5 分钟，确保系统能够及时发现并清理过期的 segment。
基于大小的删除机制：基于大小的 delete 策略默认关闭。当 Kafka 集群中所有日志的总大小超过设定值时，会删除最早的 segment。通过log.retention.bytes参数可以设置日志总大小的阈值，默认值为 - 1，表示无穷大。在实际应用中，如果一个 segment 中有部分数据过期，部分未过期，在基于时间的删除策略下，当整个 segment 的时间戳超过阈值时，该 segment 会被整体删除，这是因为 Kafka 的 segment 设计是基于时间和大小的综合考量，以确保数据清理的高效性和一致性。
（二）compact 日志压缩策略
compact 日志压缩策略适用于特定业务场景，如消息的 key 具有明确业务意义（如用户 ID），value 是与 key 相关的信息（如用户资料）。在这种策略下，对于相同 key 的不同 value 值，只保留最后一个版本。例如，对于用户资料的更新，Kafka 会在压缩过程中只保留最新的用户资料信息。经过压缩后，offset 可能不连续，当从这些 offset 消费消息时，会获取到比指定 offset 大的 offset 对应的消息，即获取最新的消息内容。这种策略有助于减少存储冗余，同时确保在特定业务场景下能够快速获取最新的关键信息，提高数据存储和查询的效率。
20、消费者组和分区数之间的关系是怎样的？
消费者组与分区数之间存在紧密的分配关系：
（一）分区分配原则
在 Kafka 中，一个消费者组中的多个消费者共同协作消费一个或多个主题的数据，遵循特定的分配原则。即一个分区只能由一个消费者组内的一个消费者消费，消费者组内的消费者负责消费不同的分区，以此确保数据不会被重复消费。例如，若一个主题有 5 个分区，一个消费者组中有 3 个消费者，那么可能会出现一个消费者消费 2 个分区，另外两个消费者分别消费 1 个分区的情况，具体的分配方式取决于所采用的分区分配策略。这种分配原则旨在充分利用消费者资源，实现数据的高效并行处理，同时保证数据消费的准确性和一致性。
（二）分区分配策略影响
不同的分区分配策略（如 Range、RoundRobin、Sticky、CooperativeSticky）对消费者组和分区数的分配关系有着不同的处理方式。例如，Range 策略会按主题为基础计算分区与消费者数量的比例进行分配；RoundRobin 策略则以轮询方式将分区均匀分配给消费者；Sticky 策略会在尽量均衡分配分区的同时，保持原有分配的稳定性；CooperativeSticky 策略在消费过程中根据消费偏移量情况动态调整分配。当分区数或消费者数发生变化（如消费者加入或离开）时，这些策略会根据各自的规则进行再平衡操作，重新确定每个消费者负责的分区，以适应系统的动态变化，确保数据消费的负载均衡和高效性。
21、kafka如何知道哪个消费者消费哪个分区？
Kafka 通过以下机制确定消费者与分区的消费关系：
（一）消费者组初始化流程
当生产者将数据发送到各个分区后，每个 broker 节点都有一个 coordinator（协调器）。消费者组在对分区进行消费时，首先通过 groupId 对 50 取模确定分区节点，该分区的协调器将成为本次消费者组的 "协调者"。消费者向协调器注册，协调器从中随机选择一个消费者作为 Leader，Leader 根据分区情况制定消费计划（即哪个消费者消费哪个分区），然后将计划发送给协调器，协调器再将计划群发至组内所有消费者，消费者按照计划进行消费。例如，在一个具有多个分区和多个消费者的场景中，通过这种取模和协调机制，能够有条不紊地确定每个消费者的消费任务，确保消费过程的有序进行。
（二）分区分配策略作用
Kafka 提供了多种分区分配策略（如 Range、RoundRobin、Sticky、CooperativeSticky）来具体确定每个消费者消费的分区。Range 策略根据主题分区数与消费者数量的比例分配；RoundRobin 策略以轮询方式分配，确保公平性；Sticky 策略在均衡分配的同时尽量保持原有分配稳定；CooperativeSticky 策略则在消费过程中动态调整。这些策略在不同的场景下发挥作用，例如当消费者数量或分区数量发生变化时，通过相应的策略进行再平衡操作，重新分配分区给消费者，以适应系统的动态变化，保证数据消费的高效性和准确性。
22、kafka消费者的消费分区策略有哪些，默认是个？
Kafka 消费者的消费分区策略主要有以下几种：
（一）分区分配策略
Range 策略：按主题为基础进行分区分配。先计算每个主题的分区数与消费者数量的比值，然后按顺序依次将分区分配给消费者。例如，有两个主题，主题 A 有 4 个分区，主题 B 有 3 个分区，消费者组中有 2 个消费者。对于主题 A，消费者 1 可能会分配到分区 0 和 1，消费者 2 分配到分区 2 和 3；对于主题 B，消费者 1 分配到分区 0，消费者 2 分配到分区 1 和 2。这种策略在分区和消费者数量相对固定且已知的情况下，能够较为简单直接地进行分区分配，但在消费者数量变化时可能导致分区分配不均衡。
RoundRobin 策略：以轮询的方式将分区分配给消费者。依次将每个分区分配给下一个可用的消费者，确保每个消费者尽可能均衡地获取分区。例如，有 3 个消费者和 6 个分区，那么分区 0 可能分配给消费者 1，分区 1 分配给消费者 2，分区 2 分配给消费者 3，分区 3 又分配给消费者 1，以此类推。该策略在消费者和分区数量相对均衡时，能较好地实现负载均衡，使每个消费者处理的分区数据量大致相同。
Sticky 策略：会尽量均衡地放置分区到消费者上，并在出现同一消费者组内消费者出现问题时，优先保持原有分配的分区不变化。例如，对于 7 个分区和 3 个消费者的情况，初始分配可能是消费者 1 消费 3 个分区，消费者 2 和 3 分别消费 2 个分区，且消费者 1 消费的分区是随机分配的。当某个消费者出现故障时，在重新分配过程中，会尽量维持其他消费者已有的分区分配情况，仅对故障消费者的分区进行重新分配，从而减少不必要的分区迁移和数据重新分配带来的开销，提高系统的稳定性和效率。
CooperativeSticky 策略：在消费过程中根据消费偏移量情况进行重新再平衡。它在运行过程中会根据消费的实际情况动态地重新分配消费者，以实现负载均衡，但这种动态平衡可能会因为多次重新分配而消耗一定的性能资源。这种策略适用于对消费负载均衡要求较高且能够容忍一定性能开销的场景，例如在大规模数据实时处理且消费者处理能力动态变化的情况下，能够较好地调整消费分配，确保整体系统的稳定运行。
（二）默认策略
Kafka 的默认策略是 Range + CooperativeSticky。可以通过配置参数partition.assignment.strategy来修改分区的分配策略，例如，如果想要使用 RoundRobin 策略，可以将该参数设置为 "org.apache.kafka.clients.consumer.RoundRobinAssignor"。在实际应用中，可根据业务需求和系统特点选择合适的分区分配策略，以优化数据消费的效率和均衡性。
23、kafka中的消费者，他们的偏移量存储在哪里？
Kafka 消费者的偏移量存储位置在不同版本有所变化：
（一）0.9 版本前后的变化
在 Kafka 0.9 版本之前，消费者的偏移量默认存储在 Zookeeper 中。然而，随着 Kafka 版本的演进，从 0.9 版本开始，consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，即__consumer_offsets。这种变化主要是为了避免消费者频繁与 Zookeeper 进行通信，减轻 Zookeeper 的负担，同时提高偏移量管理的效率和可靠性。
（二）__consumer_offsets主题存储结构与原理
__consumer_offsets主题采用 key 和 value 的方式存储数据，其中 key 是group.id + topic + 分区号，通过这种方式可以唯一标识一个消费者组在某个主题的某个分区上的偏移量信息。value 则是当前 offset 的值。Kafka 内部会定期对这个 topic 进行 compact（压缩）操作，确保每个group.id + topic + 分区号只保留最新的 offset 数据，这样既节省了存储空间，又便于快速获取最新的消费位置信息。例如，在一个具有多个消费者组、多个主题和多个分区的复杂 Kafka 集群环境中，通过这种存储结构和压缩机制，能够高效地管理和查询消费者的偏移量，为数据消费的准确性和连续性提供了有力保障。
24、kafka中数据挤压太多，怎么办？（提高消费者的效率）
当 Kafka 中出现数据积压过多的情况，可以考虑以下策略来提高消费者效率：
（一）增加消费者数量
如果分区数量允许，可以适当增加消费者组中的消费者数量。因为一个分区只能由一个消费者组内的一个消费者消费，增加消费者数量可使更多的消费者并行处理数据，从而提高整体消费能力。例如，若原本有 3 个消费者处理 6 个分区的数据，当数据积压时，可增加到 6 个消费者，每个消费者负责一个分区，加快数据处理速度。但需注意，消费者数量不能超过分区数量，否则会有部分消费者处于空闲状态，无法充分利用资源。
（二）优化消费者处理逻辑
深入检查消费者的代码逻辑，寻找可能存在的优化点。例如，减少不必要的计算、优化数据存储操作、避免阻塞式等待等。若消费者在处理消息时涉及复杂的业务计算或数据库操作，可考虑对这些操作进行异步处理或批量处理，以缩短单个消息的处理时间，从而提高整体消费速度。例如，将多次小批量的数据库插入操作合并为一次大批次插入，减少数据库事务开销和网络通信次数。
（三）调整分区分配策略
根据数据的特点和消费者的处理能力，尝试调整分区分配策略。不同的分区分配策略对消费者的负载均衡效果不同。例如，如果某些分区的数据量较大且处理耗时较长，可以将这些分区分配给处理能力较强的消费者，采用 Sticky 策略或手动指定分区分配，避免部分消费者负载过重，部分消费者闲置的情况，使分区分配更加合理，提高整体消费效率。
25、Kafka中的数据在消费过程中，有漏消费和重复消费的情况，怎么办？
（一）漏消费原因与解决方案
漏消费通常是由于先提交 offset 后消费数据导致的。为避免这种情况，可以将消费过程和提交 offset 过程做原子绑定。一种可行的方法是将 Kafka 的 offset 保存到支持事务的自定义介质（如 MySQL）中，通过事务的原子性确保消费和提交 offset 要么同时成功，要么同时失败，从而实现精准一次性消费。例如，在消费一条消息后，先将消费结果和 offset 更新操作封装在一个数据库事务中，只有当消费处理成功且 offset 更新成功时，事务才提交；若消费过程中出现异常，事务回滚，offset 也不会更新，保证数据不会被漏消费。这种方式在对数据准确性要求极高的场景下尤为重要，如金融交易数据处理等。
（二）重复消费原因与解决方案
重复消费一般是因为已经消费了数据，但 offset 未及时提交。为避免重复消费，可以合理设置 offset 提交方式。Kafka 提供了手动提交 offset 的两种方法：commitSync（同步提交）和commitAsync（异步提交）。
commitSync会阻塞当前线程，一直到提交成功，并具有自动失败重试机制。这意味着它会等待 offset 成功提交到 Kafka 或重试一定次数后才继续后续操作，能确保 offset 提交的可靠性。例如，在一些对数据准确性要求极高且不允许出现重复消费的场景，如订单处理系统中，使用commitSync可有效避免因 offset 未提交而导致的重复消费问题。但由于其阻塞特性，会在一定程度上影响系统的吞吐量。
commitAsync则在发送完提交 offset 请求后就开始消费下一批数据，没有失败重试机制。这种方式能显著提高消费的吞吐量，适用于对数据准确性要求相对不那么严格，但对处理速度有较高要求的场景，如日志收集系统。不过，由于缺乏自动重试，如果提交过程中出现网络波动等异常情况，可能导致 offset 提交失败而产生重复消费。为了弥补这一缺陷，可以在合适的时机进行补偿性提交，例如定期检查未成功提交的 offset 并进行重新提交，或者在消费者重启时对之前未确认的 offset 进行处理，以减少重复消费带来的影响。同时，也可以结合业务逻辑，在消费数据时对数据的重复性进行判断和处理，例如通过消息的唯一标识或业务主键来判断是否已经处理过该消息，若已处理则直接忽略，从而进一步降低重复消费对业务的影响。
26、kafka中的数据已经消费过的数据，是否可以再次消费？怎么做？
（一）可再次消费的情况及通过auto.offset.reset参数实现的方式
在 Kafka 中，已经消费过的数据是可以再次进行消费的，这可以通过设置auto.offset.reset参数来灵活控制，该参数提供了以下三个选项：
earliest 选项：
当选择earliest时，Kafka 会自动将偏移量重置为最早的偏移量（等同于使用--from - beginning参数）。这种设置适用于需要对某个主题的全部数据进行重新处理的场景，比如在数据完整性检查或者重新分析历史数据的情况下。例如，当我们发现之前对某主题数据的处理逻辑存在缺陷，需要重新从数据产生的最初时刻开始完整地重新消费数据时，就可以将auto.offset.reset设置为earliest。如此一来，消费者在启动后，会从该主题对应的每个分区的最早偏移量位置开始重新获取并消费数据，确保不会遗漏任何一条历史记录，从而实现对所有已消费过的数据进行再次消费。
latest 选项（默认值）：
latest是auto.offset.reset参数的默认设置。在这种情况下，Kafka 会自动将偏移量重置为最新偏移量，这意味着消费者将从最新产生的数据开始消费。此选项适用于那些只关注新产生的数据，而对已经消费过的历史数据无需再次处理的实时数据处理场景。比如在实时监控系统中，消费者持续关注的是当前时刻新产生的监控指标数据，之前的旧数据已经经过相应处理且不再有重新处理的必要，此时保持auto.offset.reset的默认值latest即可。当消费者因某些原因（如重启）重新启动后，它会自动从每个分区的最新偏移量位置开始获取并消费新产生的数据，跳过之前已经消费过的部分。
none 选项：
若设置为none，当 Kafka 未找到消费者组的先前偏移量时，就会向消费者抛出异常。这个选项适用于对消费位置有严格准确性要求的场景，例如在金融交易数据处理系统中，每一笔交易数据的消费和处理都必须严格按照顺序且在准确的偏移量位置进行，任何偏差都可能导致严重的业务问题。当出现如系统故障或其他原因导致消费者组重新启动，并且无法找到之前的偏移量位置时，设置auto.offset.reset为none会触发异常抛出。开发人员可依据此异常及时介入排查问题，并采取相应措施（如从备份数据中恢复偏移量或者重新初始化消费流程等），以确保交易数据的处理准确性和完整性。在此场景下，只有当能明确找到准确的偏移量位置时，才会按照该位置进行数据消费，避免了因偏移量不准确而可能导致的错误消费情况。
（二）通过seek方法实现重新消费指定位置数据的方式及注意事项
除了通过设置auto.offset.reset参数来控制重新消费的起始位置外，还可以使用seek方法来实现更精确地从分区的固定位置开始消费数据，从而达到重新消费指定位置数据的目的。具体操作如下：
seek 方法的基本操作步骤：
首先，创建并配置一个KafkaConsumer对象。
订阅要消费的主题。
获取当前消费者分配到的分区信息。
针对每个分配到的分区，使用seek方法设置要开始消费的偏移量位置。
最后，通过循环调用consumer.poll方法来持续获取并消费从指定偏移量位置开始的数据。
使用 seek 方法的注意事项：
消费者组名修改：每次使用seek方法重新定位消费位置后，可能需要对消费者组名进行修改等相关操作，以确保能够达到预期的消费效果。这是因为 Kafka 在处理数据消费时，会依据消费者组的相关配置和历史消费记录来进行操作。如果不修改消费者组名，可能会出现与之前消费逻辑混淆的情况，导致无法按照我们期望的新位置进行消费。例如，假设之前已经有一个消费者组在消费某个主题的数据，现在想要从不同的偏移量位置重新消费，若不修改消费者组名，很可能会出现与之前消费流程相互干扰的情况，所以通常建议在这种情况下修改消费者组名，以保证新的消费流程能够独立、准确地按照我们设定的位置进行。
数据一致性与顺序性：在使用seek方法重新开始消费数据时，需要特别关注数据的一致性和顺序性问题。尤其是在涉及到有业务逻辑依赖于数据消费顺序的场景中，比如在处理具有时间序列关系的数据分析任务或者事务处理系统中，数据的消费顺序至关重要。如果随意更改消费位置，可能会破坏数据原本的顺序，进而导致业务逻辑处理出现错误。因此，在使用seek方法时，要充分考虑业务需求和数据的内在逻辑关系，确保重新消费数据的操作不会对业务产生负面影响。
偏移量有效性检查：在指定seek方法的偏移量参数时，要确保所指定的偏移量是有效的。如果指定的偏移量超出了分区实际存在的偏移量范围，可能会导致消费异常。例如，如果一个分区目前的有效偏移量范围是从 "0" 到 "1000"，而我们错误地指定了偏移量 "1500"，那么在消费过程中就会遇到找不到对应数据的问题。所以在使用seek方法之前，最好对要指定的偏移量进行适当的检查和验证，确保其在合理的范围内，这样才能保证消费过程的顺利进行。
通过上述两种方式，即通过设置auto.offset.reset参数以及使用seek方法，我们可以根据具体的业务需求和场景灵活地实现对 Kafka 中已经消费过的数据进行再次消费的操作，同时注意相关的操作细节和注意事项，以确保数据消费的准确性和业务逻辑的正常运行。