kafka二三事

kafka是什么？

Apache Kafka 是一个开源的分布式流处理平台，主要用于构建高性能、可扩展的实时数据管道和流式应用程序，广泛应用于消息队列、日志聚合、事件流处理和实时数据分析等场景。

kafka为何如此之快？

Kafka 实现了零拷贝原理来快速移动数据，避免了内核之间的切换。Kafka 可以将数据记录分批发送，从生产者到文件系统（Kafka 主题日志）到消费者，可以端到端的查看这些批次的数据。
批处理能够进行更有效的数据压缩并减少 I/O 延迟，Kafka 采取顺序写入磁盘的方式，避免了随机磁盘寻址的浪费。
总结一下其实就是四个要点，顺序读写，零拷贝，消息压缩，分批发送。

分区越多吞吐越高么？

不是。一旦分区数目超过某个阈值之后，相应的吞吐量也会下降。 如果一定要给一个准则，则建议将分区数设定为集群中broker的倍数，即假定集群中有3个broker节点，可以设定分区数为3、6、9等，至于倍数的选定可以参考预估的吞吐量。

kafka日志是什么？

kafka日志是它存储消息的物理结构，每个分区（partition）对应一个日志文件，消息按顺序追加写入，每条消息在分区中都有的唯一偏移量（offset）。日志文件又被划分为多个分段（Segment），每个分段主要包含一个日志文件.log和两个索引文件.index与.timeindex，.log文件用于存储实际消息数据，.index文件采用稀疏索引设计，用于快速定位消息，.timeindex文件是基于时间戳的索引，用于按时间范围查找消息。
kafka通过顺序写入、分段存储、零拷贝和稀疏索引等机制，实现了高效的数据存储与检索。

• 顺序写入：消息以追加写（Append-Only）的方式写入 .log 文件，避免随机 I/O，充分利用磁盘顺序写入的高性能特性。
• 分段滚动：当日志文件达到一定大小（如 1GB）或时间（如 7 天）时，创建新的分段文件。旧的分段文件会被保留，直到满足删除条件。
• 稀疏索引：索引文件只记录部分消息的偏移量和物理位置，减少索引文件大小。查找消息时，先通过索引定位大致范围，再在 .log 文件中顺序扫描。
• 零拷贝（Zero-Copy）：利用操作系统的 sendfile 系统调用，直接将数据从磁盘传输到网络，避免数据在内核态和用户态之间的拷贝

kafka的最小数据单元是什么？

消息，由键（Key）、值（Value）和时间戳（Timestamp）组成。

kafka的消息是如何保证顺序性的？

Kafka 通过分区（Partition）和偏移量（Offset）来保证消息的顺序性。在同一个分区中，消息是按顺序追加写入的，消费者按顺序读取，每条消息都有唯一的偏移量。通常情况下，按业务键（如用户ID）将消息分配到固定分区，就可以在保持高吞吐的同时保证相关消息的顺序性。

Kafka 中的消息是如何存储的？

Kafka 的消息存储在日志段（Log Segment）中，每个日志段主要包含 .log 文件（存储实际消息）和 .index 文件（稀疏索引）。它通过顺序写入、分段存储、零拷贝和稀疏索引等机制，实现了高效的数据存储和检索。

说一下kafka的分区副本机制

每个分区有多个副本，分布在不同的 Broker 上。当某个 Broker 失败时，其他副本可以继续提供服务。副本之间是一主多从关系，leader 负责写请求，follower同步消息。leader失败后从follower选举 leader 对外服务。

ISR是什么？

ISR的全称是In-Sync Replica，是已与leader同步的副本集合。

Kafka支持的几种消息传递语义有哪些？

Kafka 支持三种消息传递语义：
At-most-once：最多一次，不保证消息重复。
At-least-once：至少一次，可能重复。
Exactly-once：精确一次，确保消息不重复且不丢失

Kafka消费者如何消费消息？

消费者通过 poll() 方法从 Kafka 集群拉取消息。消费者组（Consumer Group）允许多个消费者协同工作，共同消费一个主题中的消息，实现负载均衡。

如何解决kafka消息积压问题？

首先定位出现消息积压的原因是出现在生产端还是消费端，是暂时性的，还是长久性的。
如果只是暂时性的消息积压，可以从以下两个方面解决：
（1）生产者生产消息限流：限制生产者发送消息的速率，避免生产速度超过消费速度
（2）增加消费者消费能力：增加消费者数量、使用多线程或线程池处理消息
如果是长久性的，则还需要扩分区、扩容升配，调整配置参数等。

kafka出现消费阻塞怎么办？

调整偏移量，将offset后移一位；消息补推，针对跳过的消息或某个时间段内的数据进行消息补推；

kafka出现消息丢失怎么办？

首先从以下方面分析，生产端是否成功发送消费？消费端是否成功消费消息？
如果是Producer丢失消息，说明发送逻辑存在bug。
如果是Broker丢失消息，说明要检查集群的健康性。
如果comsumer已成功消费，但未正确返回确认，说明要修改消息确认机制。
如果comsumer未成功消费，说明消费逻辑有bug。
将以上问题解决之后，进行消息补推。

如何保证消息消费的幂等性？

（1）利用数据库的唯一约束
将数据库中的多个字段联合，创建一个唯一约束，即使多次操作也能保证表里至多存在一条记录。
（2）设置数据变更的前置条件，如版本号、最后更新时间
如果满足条件就更新数据，否则拒绝更新数据；在更新数据的时候，同时变更前置条件中的数据（版本号+1、更新updateTime）。
（3）记录每条消息的消费状态并检查操作
给每条消息都记录一个全局唯一ID；消费时，先根据这个全局唯一 ID 检查这条消息是否有被消费过；如果没有消费过，则更新数据，并将消费状态置为“已消费”状态。操作过程保持原子性。

在kafka中，怎么避免消费重复数据？

（1）通过设置 enable.idempotence=true，配置幂等性生产者
（2）消费者端去重。消费者可以在处理每条消息时，查询已处理消息的唯一 ID，若已处理则忽略。
（3）在同一分区中，每条消息都有唯一偏移量，并且顺序写入，顺序读取。

Kafka 可以脱离 zookeeper 单独使用吗？为什么？

以后行不行，我不知道，但现在是不可以的。当前，Kafka 依赖 ZooKeeper 来管理集群状态和协调元数据，无法脱离 ZooKeeper 单独使用。

Kafka 有几种数据保留的策略？

3种，基于时间的保留策略、基于大小的保留策略、基于起始位移的保留策略。

Kafka 有几种日志清理的策略？

Kafka 提供了两种日志清理策略：（1）删除策略（delete）：在达到保留期后删除旧数据。（2）压缩策略（compact）：针对具有相同键的记录，只保留最新版本。
通过 log.cleanup.policy 配置项设置清理策略。

Kafka 的分区策略有哪些？

• 1.默认分区策略（DefaultPartitioner）
  默认分区策略是 Kafka 的内置分区器，用于在没有指定自定义分区器时分配消息到分区。它的行为如下：
  有键的消息：根据消息的键（Key）进行哈希计算，将消息均匀分配到不同的分区。
  无键的消息：采用轮询的方式（Round Robin）将消息分配到各个分区。
• 2.自定义分区策略
  Kafka 允许用户实现自定义的分区策略，通过实现 org.apache.kafka.clients.producer.Partitioner 接口来定义分区逻辑。
• 3.固定分区策略
  固定分区策略将消息固定分配到某个分区。这种策略通常用于测试或特定的业务场景。

kafka怎么判断一个节点是否还活着？

（1）心跳机制：Kafka 的每个Broker 会定期向 ZooKeeper 发送心跳信号，以表明自己仍然存活。ZooKeeper 会监控这些心跳消息，如果在一定时间内没有收到某个 Broker 的心跳，就会将其标记为失效。
（2）元数据更新：Kafka的每个Broker会定期更新集群中的元数据，这些元数据包括各个节点的状态信息。如果一个节点长时间没有响应，其他节点会在元数据中将其标记为不可用。

Zookeeper对于Kafka的作用

ZooKeeper 在 Kafka 中扮演着非常重要的角色，主要用于管理Kafka集群的元数据和协调集群操作。具体包括：

• 管理集群元数据：存储 Broker、主题和分区的元数据。
• 协调集群操作：负责 Leader 选举、Broker 加入和离开、消费者组协调等操作。
• 监控集群状态：通过心跳机制和会话超时监控 Broker 的存活状态。
• 元数据同步：确保所有节点获取最新的集群状态和元数据信息。
• 消费者偏移量管理：存储消费者组的偏移量信息，确保消费的连续性。

kafka是一个分布式集群，为什么bootstrap-servers只配置了一个地址就行了？

Kafka 客户端（生产者或消费者）在启动时，会通过 bootstrap-servers 指定的 Broker 地址连接到 Kafka 集群。连接成功后，客户端会从该 Broker 获取整个集群的元数据信息，包括所有 Broker 的地址、主题信息、分区分配等。因此，即使只提供一个 Broker 地址，客户端也能自动发现集群中的其他 Broker。

kafka是怎么实现高可用性的？

Kafka 的高可用机制通过副本机制、Leader 选举、分区自动再平衡、消费者组协调、心跳机制、负载均衡和故障检测与恢复等多方面实现。

副本机制确保数据的高可用性。每个分区（Partition）都有多个副本（Replicas），这些副本分布在不同的 Broker 上。
Kafka 使用 ZooKeeper 进行分布式协调和元数据管理。当 Broker 宕机时，ZooKeeper 负责通知集群其他部分，并触发 Leader 选举过程。
Kafka 支持自动再平衡机制：（1）当集群状态发生变化（如 Broker 加入或离开）时，会重新分配分区，确保负载均衡。（2）当有新的消费者加入或现有消费者离开时，消费者组协调器（Coordinator）会触发再平衡过程，重新分配分区。（3）消费者定期向协调器发送心跳，以表明其仍然存活。如果协调器在指定时间内未收到消费者的心跳，则认为该消费者已经失效，并触发再平衡。