Kafka删除历史消息的策略

布满荆棘的人生 2021-09-25 01:44 448阅读 0赞

###  1 删除策略 ###

Kafka日志管理器允许定制删除策略。目前的策略是删除修改时间在N天之前的日志（按时间删除），也可以使用另外一个策略：保留最后的N GB数据的策略(按大小删除)。为了避免在删除时阻塞读操作，采用了copy-on-write形式的实现，删除操作进行时，读取操作的二分查找功能实际是在一个静态的快照副本上进行的，这类似于Java的CopyOnWriteArrayList。

Kafka消费日志删除思想：Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7&nbsp; </td> 
 <td> <code>log.cleanup.policy=delete启用删除策略</code> <code>直接删除，删除后的消息不可恢复。可配置以下两个策略：</code> <code>清理超过指定时间清理：&nbsp;</code> <code>log.retention.hours=16</code> <code>超过指定大小后，删除旧的消息：</code> <code>log.retention.bytes=1073741824</code> log.cleaner.enable=false&nbsp; 默认使用<code>log.retention.hours 或&nbsp;log.retention.bytes的配置</code> </td> 
 </tr> 
 </tbody> 
</table>

### 2 压缩策略 ###

将数据压缩，只保留每个key最后一个版本的数据。首先在broker的配置中设置**log.cleaner.enable=true**启用cleaner，这个默认是关闭的。在Topic的配置中设置**log.cleanup.policy=compact**启用压缩策略。  
  压缩策略的细节如下：

![8d4119eed0edd48b5ff52ba4b8552b30.png][]

如上图，在整个数据流中，每个Key都有可能出现多次，压缩时将根据Key将消息聚合，只保留最后一次出现时的数据。这样，无论什么时候消费消息，都能拿到每个Key的最新版本的数据。  
    压缩后的offset可能是不连续的，比如上图中没有5和7，因为这些offset的消息被merge了，当从这些offset消费消息时，将会拿到比这个offset大的offset对应的消息，比如，当试图获取offset为5的消息时，实际上会拿到offset为6的消息，并从这个位置开始消费。  
    这种策略只适合特俗场景，比如**消息的key是用户ID，消息体是用户的资料，通过这种压缩策略，整个消息集里就保存了所有用户最新的资料。  
    压缩策略支持删除，当某个Key的最新版本的消息没有内容时，这个Key将被删除，这也符合以上逻辑。**  
转自：[https://www.cnblogs.com/moonandstar08/p/6146995.html][https_www.cnblogs.com_moonandstar08_p_6146995.html]

> Kafka中用于保存消费者消费位移的主题“\_\_consumer\_offsets”使用的就是Log Compaction策略。

转自：[https://blog.csdn.net/u013256816/article/details/80487758?utm\_medium=distribute.pc\_relevant.none-task-blog-baidujs\_title-10&spm=1001.2101.3001.4242][https_blog.csdn.net_u013256816_article_details_80487758_utm_medium_distribute.pc_relevant.none-task-blog-baidujs_title-10_spm_1001.2101.3001.4242]

cleanup.policy: delete  
segment.bytes: 每个segment的大小，达到这个大小会产生新的segment, 默认是1G  
segment.ms: 配置每隔n ms产生一个新的segment,默认是168h,也就是7天  
retention.bytes: 总的segment的大小限制，达到这个限制后会删除旧的segment,默认值为-1，就是不会删除  
retention.ms: segment的最后写入record的时间-当前时间 > retention.ms 的segment会被删除，默认是168h, 7天

转自：[https://blog.csdn.net/u013200380/article/details/106453013?utm\_medium=distribute.pc\_relevant.none-task-blog-OPENSEARCH-2.control&depth\_1-utm\_source=distribute.pc\_relevant.none-task-blog-OPENSEARCH-2.control][https_blog.csdn.net_u013200380_article_details_106453013_utm_medium_distribute.pc_relevant.none-task-blog-OPENSEARCH-2.control_depth_1-utm_source_distribute.pc_relevant.none-task-blog-OPENSEARCH-2.control]

[8d4119eed0edd48b5ff52ba4b8552b30.png]: /images/20210923/8016a3e17a244a6abbe8415e99387f9e.png
[https_www.cnblogs.com_moonandstar08_p_6146995.html]: https://www.cnblogs.com/moonandstar08/p/6146995.html
[https_blog.csdn.net_u013256816_article_details_80487758_utm_medium_distribute.pc_relevant.none-task-blog-baidujs_title-10_spm_1001.2101.3001.4242]: https://blog.csdn.net/u013256816/article/details/80487758?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_title-10&spm=1001.2101.3001.4242
[https_blog.csdn.net_u013200380_article_details_106453013_utm_medium_distribute.pc_relevant.none-task-blog-OPENSEARCH-2.control_depth_1-utm_source_distribute.pc_relevant.none-task-blog-OPENSEARCH-2.control]: https://blog.csdn.net/u013200380/article/details/106453013?utm_medium=distribute.pc_relevant.none-task-blog-OPENSEARCH-2.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-OPENSEARCH-2.control