一、Kafka核心架构原理

1. 分布式协调与选举

• Controller选举：Kafka集群中首个在ZooKeeper创建/controller节点的Broker成为Controller（或使用KRaft协议去ZK化）
• Partition Leader选举：Controller监控ISR变化，优先从ISR列表中选举新Leader（默认unclean.leader.election.enable=false确保数据一致性）

2. ISR、OSR与HW机制

• ISR (In-Sync Replicas)：与Leader保持同步的副本集合（包含Leader自身）
• OSR (Out-of-Sync Replicas)：滞后超过replica.lag.time.max.ms的副本
• HW (High Watermark)：所有ISR副本均已复制的最大偏移量，消费者可见的数据分界点
• LEO (Log End Offset)：当前副本最新消息的偏移量

关键公式：HW = min(Leader_LEO, Follower1_LEO, Follower2_LEO, ...)

3. 高性能存储设计

• Segment分片存储：
  • 每个Partition拆分为多个Segment（默认1GB）
  • 文件命名基于基准偏移量（如00000000000036876912.log）
  • 包含.log（数据）、.index（稀疏索引）、.timeindex（时间索引）
• 内存映射优化：通过FileChannel.map()实现零拷贝读取

4. 刷盘机制 (Flush)

• Page Cache优先：消息先写入OS页缓存，由操作系统异步刷盘
• 同步刷盘策略：
  • flush.messages：累计n条消息强制刷盘
  • flush.ms：间隔n毫秒强制刷盘
• 权衡建议：通常采用异步刷盘（log.flush.interval.messages=10000）平衡性能与可靠性

5. 消息压缩算法

算法	压缩比	CPU消耗	适用场景
gzip	最高	高	带宽敏感场景
snappy	中等	低	CPU敏感场景（默认）
lz4	中等	最低	低延迟场景
zstd	高	中等	Kafka 2.1+ 平衡选择

生产者端设置compression.type启用压缩，Broker保持压缩状态存储。

---

二、高可用与消息可靠性保障

1. 数据高可用策略

• Replica同步流程：
  1. Producer发送消息至Leader
  2. Leader持久化消息并更新LEO
  3. Followers从Leader拉取消息（PULL模式）
  4. Follower持久化后返回ACK
  5. Leader更新HW并通知Followers
• ACK确认机制：
  • acks=0：不等待确认（可能丢失数据）
  • acks=1：Leader落盘即确认（默认）
  • acks=all：所有ISR副本落盘确认（最强保障）

2. 消息丢失场景与规避

场景	解决方案
Producer端丢失	设置acks=all + retries=N
Broker端丢失	min.insync.replicas=2
Consumer端丢失	关闭自动提交，处理完手动提交

3. 顺序消费保证

• 关键条件：单分区内消息天然有序
• 消费端策略：
  • 使用单线程消费分区
  • 对Key做哈希路由，相同Key的消息发往同一分区
  • 避免分区重平衡导致乱序（max.poll.interval.ms调优）

---

三、Kafka高频面试题精析

1. HW截断机制是什么？

当Leader切换时，新Leader会将其HW设置为当前LEO，Follower比较自身HW与Leader的HW，将本地日志截断到HW位置，确保数据一致。

2. Kafka为什么快？

• 零拷贝技术（sendfile系统调用）
• 顺序磁盘I/O（Segment追加写入）
• 页缓存（Page Cache）加速读写
• 批量处理（Producer/Broker/Consumer）

3. 如何避免重复消费？

• 幂等Producer：启用enable.idempotence=true，自动去重
• 事务消息：跨会话精确一次语义（EOS）
• 消费端：保证处理逻辑幂等性（如数据库唯一键）

4. Rebalance触发的条件？

• 消费者组新增/退出实例
• 订阅Topic分区数变化
• 消费者超过session.timeout.ms未发送心跳

5. Kafka如何实现高吞吐？