Kafka的Log Compaction（日志壓縮）是一種獨特的數據保留策略，其核心原理是保留每個key的最新有效記錄。以下是關鍵原理分點說明：

1. 鍵值保留機制

通過掃描所有消息的key，僅保留每個key對應的最新value值。例如：

原始日志: 
(key1, v1) → (key2, v2) → (key1, v3) → (key2, v4)壓縮后日志:
(key1, v3) → (key2, v4)

2. 壓縮觸發條件

Kafka的臟數據比例計算

數學公式

臟數據比例 = （相同key的舊版本記錄總大小） / （當前日志段總大小）

示例場景分析
假設日志段包含4條等體積記錄：

(keyA, v1) → (keyB, v2) → (keyA, v3) → (keyB, v4)

1. 有效數據：v3（keyA最新值）+ v4（keyB最新值）= 2條記錄
2. 臟數據：v1（keyA舊值）+ v2（keyB舊值）= 2條記錄
3. 實際臟數據比例：2/4=50%（達到默認觸發閾值）

特殊場景驗證
當出現以下情況時比例會變化：

• 非均勻分布
  假設段中有6條記錄：3個key各有兩個版本

  (k1,v1)→(k2,v2)→(k3,v3)→(k1,v4)→(k2,v5)→(k3,v6)
  

  臟數據 = v1+v2+v3 = 3條 → 比例3/6=50%

• 跨段分布
  若舊版本分布在多個segment中，則單個segment可能不達閾值

監控驗證方法
通過kafka自帶工具查看具體segment狀態：

# 查看segment元數據
bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.log --print-data-log

輸出示例：

offset: 0 key: keyA payload: v1
offset: 1 key: keyB payload: v2 
offset: 2 key: keyA payload: v3  ← 最新有效值
offset: 3 key: keyB payload: v4  ← 最新有效值

此時該segment的臟數據比例為50%。
臟數據就是指的該數據有多版本數據。

日志段含義（物理分片）

Kafka的日志段大小（Log Segment Size）指的是單個日志文件在磁盤上的物理存儲限制，其核心要點如下：

1. 存儲單元劃分
   每個partition的日志被拆分為多個固定大小的segment文件（默認1GB），文件命名采用base offset數值：

00000000000000000000.log  // 起始offset=0的segment
00000000000005368769.log  // 起始offset=5368769的segment

2. 配置參數
   通過server.properties控制：

# 單個segment最大字節數（默認1GB）
log.segment.bytes=1073741824# 時間維度滾動策略（默認7天）
log.roll.hours=168

3. 滾動觸發機制
   滿足以下任一條件即創建新segment：

• 當前segment大小超過log.segment.bytes
• 當前segment存活時間超過log.roll.ms/log.roll.hours
• 消息最大時間戳與創建時間差超過閾值

4. 物理文件組成
   每個segment包含三個物理文件：

00000000000000000000.log  // 消息數據
00000000000000000000.index // 位移索引
00000000000000000000.timeindex // 時間戳索引

5. 性能影響

• 大segment（如5GB）→ 減少文件數，提高順序IO性能，但增加故障恢復時間
• 小segment（如500MB）→ 加快日志壓縮和消息過期，但增加文件切換開銷

實際查看segment文件示例（Windows路徑）：

# 查看segment文件列表
dir C:\kafka\data\test-topic-0
# 輸出示例：
# 00000000000000000000.log
# 00000000000000000000.index
# 00000000000000000000.timeindex

檢查log.cleaner.backoff.ms

log.cleaner.backoff.ms 配置的檢查間隔主要用于檢查以下內容：

1. 日志段清理條件檢查
   檢查各個分區的日志段是否滿足清理條件：

• Compact策略下消息鍵的最新值是否可合并
• Delete策略下是否超過日志保留時間/大小限制
• 是否有足夠可回收的磁盤空間

2. 清理任務調度檢查
   評估當前系統的負載情況，決定是否啟動新的清理任務：

• 檢查可用的清理線程數
• 判斷當前CPU/IO資源使用率是否允許執行清理
• 驗證待清理分區是否處于可操作狀態

3. 清理進度檢查
   監控正在執行的清理任務：

• 確認當前清理操作是否超時
• 檢查已完成清理的分區是否需要后續處理
• 驗證清理后的日志段索引是否有效

配置建議：

# 當需要更頻繁檢查時（如高吞吐量場景）
log.cleaner.backoff.ms=5000
# 當需要降低資源消耗時（如邊緣設備部署）
log.cleaner.backoff.ms=30000

1 Kafka官方文檔指出，該參數控制清理線程在兩次檢查之間的休眠時間，這個間隔直接影響日志清理的實時性和系統資源消耗的平衡。

當滿足以下條件時觸發壓縮：

• 臟數據比率超過 min.cleanable.dirty.ratio（默認0.5）
• 日志段大小達到 segment.bytes（默認1GB）
• 達到 log.cleaner.backoff.ms 配置的檢查間隔（默認15秒）

3. 墓碑消息機制

當需要刪除某個key時，會寫入value為null的墓碑消息。該消息會保留 delete.retention.ms（默認24小時）后才會被清除。（這是約定的，開發者需要知道并配合kafka的特性來開發，可以依賴該特性進行空間優化。）

4. 物理存儲優化

采用copy-on-write機制：

• 創建新segment文件寫入有效數據
• 完成后原子替換舊文件
• 舊文件異步刪除

5. 應用場景特征

適合需要維護最終狀態的場景：
? 數據庫變更捕獲（CDC）
? 配置信息更新跟蹤
? 實時物化視圖維護
? 不適合審計日志等需要完整歷史記錄的場景

實際配置示例：

cleanup.policy=compact
min.cleanable.dirty.ratio=0.3
delete.retention.ms=86400000  # 24小時
segment.bytes=1073741824      # 1GB

該機制通過空間換時間的方式，在保證最新狀態可查的同時，顯著降低存儲消耗（實測可減少50%-90%存儲空間）。