1、kafka消息发送的流程？

• Producer 创建并配置。
• 发送消息，消息被序列化，并通过配置的分区规则决定发送的分区。
• Producer 发送请求，通过网络将消息发送到相应的 Broker。
• Broker 存储消息，将消息写入分区日志。
• Producer 等待 ACK 确认，根据 acks 配置等待响应。
• 成功或失败，根据结果执行回调，消息成功则继续发送，失败则重试。

2、Kafka 的设计架构你知道吗？

• Kafka 的设计架构以高吞吐量、高可用性和可扩展性为目标，采用分布式的方式通过分区、复制和消费者组等机制实现了这些目标。它通过结合 Producer、Broker、Consumer、ZooKeeper 等组件的协作，提供了一个强大的消息流处理平台。

3、Kafka 分区的目的？

• 并行处理：通过分区实现多个生产者和消费者的并行工作，提高吞吐量。
• 水平扩展：分区允许 Kafka 集群通过增加 Broker 来横向扩展，支持更多的存储和更高的处理能力。
• 消息顺序保证：保证单个分区内的消息顺序，适用于有序数据处理场景。
• 容错和高可用性：通过分区和副本机制保证数据在故障情况下的可用性。
• 负载均衡：通过消费者组和分区的分配，实现负载均衡，防止资源浪费。
• 存储管理：通过分区的存储策略灵活地管理消息的生命周期。

4、你知道 Kafka 是如何做到消息的有序性？

• Kafka 的消息顺序性是 在分区内保证顺序 的，通过顺序写入、偏移量管理和领导者-追随者模式来确保每个分区内消息的顺序性。而 跨分区的顺序性 并没有保证，生产者可以通过合理的分区设计（例如使用消息键）来间接实现顺序控制。通过这种设计，Kafka 能在保证高吞吐量和高并发的同时，也确保了消息的有序性，尤其是在分区级别。

5、ISR、OSR、AR 是什么？

• ISR（In-Sync Replicas）：同步副本，它们与 Leader 副本保持数据一致并能参与 Leader 选举。
• OSR（Out-of-Sync Replicas）：非同步副本，它们的数据落后于 Leader 副本，不能参与数据一致性的保证。
• AR（Available Replicas）：可用副本，包括 Leader 副本和其他可以响应请求的副本，不论它们是否同步。

6、Kafka 在什么情况下会出现消息丢失

• Producer 配置不当（acks=0 或 acks=1 配置）。
• 消息未成功写入磁盘（磁盘故障或 Broker 崩溃）。
• Leader 副本丢失，尤其是当副本未能及时同步数据。
• 日志保留策略导致消息丢失（日志过期或覆盖）。
• Broker 节点崩溃，尤其是当没有足够副本时。
• 网络分区，导致副本不同步或 Leader 无法选举。
• 生产者重试逻辑问题，导致消息未被成功发送。

7、怎么尽可能保证 Kafka 的可靠性

• 生产者配置：确保 acks=all，配置合适的重试和超时策略。
• Broker 配置：确保副本数设置为 3，使用 min.insync.replicas 配置保证至少有足够的副本同步数据。
• 消费者配置：手动提交偏移量，禁用自动提交，配置合理的 max.poll.records 等。
• 日志保留和写入策略：合理配置日志保留时间和写入刷新频率。
• 硬件和网络：使用可靠的存储和网络系统，避免资源瓶颈和网络延迟。
• 监控和自动故障转移：及时监控集群健康，自动化故障转移，确保服务可用性。

8、Kafka中如何做到数据唯一，即数据去重？

• 启用生产者的 幂等性（enable.idempotence=true），保证即使在重试时，也不会出现重复消息。
• 使用 事务，确保一批消息的原子性。
• 使用 手动提交偏移量，避免因消费者失败导致重复消费。
• 设计 幂等消费：通过唯一消息 ID 记录已处理的

9、生产者如何提高吞吐量？

• 批量发送：配置 batch.size 和 linger.ms，将消息批量发送。
• 消息压缩：使用合适的压缩算法（如 snappy）减少网络带宽消耗。
• 配置生产者的 acks：设置为 1 或 0 来提高吞吐量，但要考虑数据丢失的风险。
• 调整生产者线程数和并行度：增加并发请求的数量（max.in.flight.requests.per.connection）。
• 优化网络和硬件资源：确保网络带宽和磁盘 I/O 性能足够。
• 高效的序列化方式：使用更高效的序列化格式（如 Avro 或 Protobuf

10、zk在kafka集群中有何作用

• 在传统的 Kafka 集群架构中，Zookeeper 扮演着集群协调器的角色，负责管理 Kafka 集群的元数据、执行 Leader 选举、消费者组管理、配置管理以及分区副本同步等任务。Zookeeper 为 Kafka 集群提供了可靠的协调机制，确保了 Kafka 集群的高可用性和一致性。
• 然而，随着 KRaft 模式（Kafka Raft）引入，Kafka 正在逐步减少对 Zookeeper 的依赖，并试图实现完全通过 Kafka 自身的协议进行协调管理。这一变化将进一步简化 Kafka 的架构并提高其可扩展性。

11、简述kafka集群中的Leader选举机制

• Leader选举是Kafka保证数据一致性和高可用性的重要机制，Zookeeper协调每个分区的Leader选举，并通过副本同步保证数据的可靠性。通过这种机制，即使某个Broker故障，Kafka集群也能继续工作，并能快速恢复。

12、kafka是如何处理数据乱序问题的。

• 保证同一分区内消息顺序。
• 通过消息键来保证相同键的消息在同一分区内，保证顺序。
• 通过生产者的幂等性和事务机制保证消息发送的一致性。
• 在消费者端通过控制并发和分区来减少乱序。

13、kafka中节点如何服役和退役

• Kafka集群中的节点服役和退役是通过Zookeeper和Kafka内部的控制器来协调和管理的。服役时，新节点通过Zookeeper注册并进行分区迁移，确保数据高可用性；退役时，节点会停止服务并触发分区副本迁移，确保集群的健康运行。在整个过程中，Kafka致力于最小化对集群性能的影响，并保证数据的安全和一致性

14、Kafka中Leader挂了，Follower挂了，然后再启动，数据如何同步？

• Leader选举：当Leader挂掉时，Kafka会通过Zookeeper和控制器选举新的Leader，确保集群继续运行。
• ISR（In-Sync Replicas）：Kafka通过ISR列表确保只有同步的副本才会被选为Leader或提供服务。副本同步滞后太多时会被临时移除ISR列表。
• 数据恢复与同步：恢复的Leader或Follower会从当前的Leader节点同步数据，直到其数据一致。
• 副本数量：通过合理配置副本数量（通常为3个），可以提高集群的容错能力，减少数据丢失的风险。

15、kafka中初始化的时候Leader选举有一定的规律，如何打破这个规律呢？

• 修改 auto.leader.rebalance.enable 和 preferred.leader.election.enable 配置，控制是否自动重新平衡 Leader。
• 手动触发 Leader 选举，使用 kafka-leader-election.sh 工具。
• 调整分区副本分配策略，通过自定义分区器改变副本的分配方式。
• 改变 Broker 优先级，调整集群中不同 Broker 的优先级。
• 使用自定义的控制器逻辑，但这种方式较为复杂。