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 的优先级。
- 使用自定义的控制器逻辑，但这种方式较为复杂。