一、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如何實現高吞吐？