kafka 0.9.0.0 __consumer_offsets日誌清理問題？

最近發現生產環境__consumer_offsets下的segment容量高達幾十個G，server.properties使用的是默認配置，其它topic的容量都是正常的，並沒有發現堆積，應該是正常刪除了的，請問是__consumer_offsets這個topic下的清理策略和自建的topic不一樣嗎？我現在該怎麼清理呢？還有就是log.cleaner.enable這個配置是控制delete和compact還是只控制compact的？cleaner.delete.retention.ms和log.segment.delete.delay.ms有啥區別？謝謝！

謝邀

1. __consumer_offsets的確與普通topic在清理策略上不同，也就是參數cleanup.policy上compact和delete的區別。compact策略會對消息按照key進行壓實操作(compact)，你可以簡單地理解為每個key上只保存最新的一個value。__consumer_offsets topic就是這樣的清理策略。

在你使用的0.9版本中，這個策略兩者必選其一，即要麼delete要麼compact。的確有可能出現這個topic數據量很大的情況。也正是這個原因，之後的版本中允許同時指定兩種策略，即delete,compact，這樣你既可以「享受」普通topic的刪除策略也能實現compact的效果。因此你可以嘗試升級kafka的版本，另外嘗試減少offsets.retention.minutes值通常會加速這個topic過期消息刪除的速度。個人不建議手動清理該topic，畢竟有可能造成group數據的丟失。不過，國外有個用戶的確是把該topic的策略設置成了delete（參見[Kafka-users] Consumer Offsets Topic cleanup.policy 注意：請確保完全理解了這個帖子中所說的使用場景之後再這麼做！另外比起這種「另類」的使用方法，升級到新版本Kafka並設置cleanup.policy=delete,compact似乎更加穩妥。)

2. log.cleaner.enable參數就是清除compact型topic的開關，默認就是true，不建議調整此參數。

3. 當前刪除日誌段是一個非同步過程，log.segment.delete.delay.ms參數控制了等待多少秒後再開始刪除操作。默認是1分鐘，表示Kafka發起刪除操作後，等1分鐘才會開始刪除底層的物理文件。至於cleaner.delete.retention.ms參數，Kafka會定期清理過期consumer group的元數據信息，一旦發現dead group，會往__consumer_offsets對應分區寫入一個特殊消息，這種消息被稱為tombstone消息或delete消息。Log cleaner在清理日誌段時會根據cleaner.delete.retention.ms參數來計算一個時間點。位於該時間點之前的所有delete消息都會被清理掉。

這就是這兩個參數的區別，希望我解釋清楚了:)