kafka--compact分析

Kafka是一个基于日志的流处理平台，一个topic可以有多个分区（partition），分区是复制的基本单元，在单节点上，一个分区的数据文件可以存储在多个磁盘目录中，每个分区的日志文件存储的时候又会分成一个个的segment，默认日志段（segment）的大小是1GB，segment是日志清理的基本单元，当前正在使用的segment是不会被清理的。对于每一个kafka partition的日志，以segment为单位，都会被分为两部分，已清理和未清理的部分。同时，未清理的那部分又分为可以清理的和不可清理的。

日志压缩是一种机制,可以提供细粒度的记录保留,而不是基于粗粒度的基于时间的保留。这个想法是选择性地删除记录,在这里我们有一个最新的更新和相同的主键。这样,日志保证至少在每个键上至少有最后一个状态。

这个保留策略可以设置每个主题,因此一个单个集群可以有一些主题,在这些主题中,保留由大小或时间和其他主题执行,在那里保留由压缩执行。

压缩还允许删除。带有键和空有效负载的消息将被视为从日志中删除。这个删除标记将导致删除任何先前带有该键的消息(与任何带有该键的新消息一样)，但是删除标记的特殊之处在于，它们将在一段时间后从日志中清除，以释放空间。删除不再保留的时间点在上图中被标记为“删除保留点”。

注意Log Compaction是针对key的，所以在使用时应注意每个消息的key值不为null。

压缩是在后台通过周期性地重新打开日志段来完成的。清洗不会阻塞读取，并且可以进行节流，最多使用可配置的I/O吞吐量，以避免影响生产者和消费者。压缩日志段的实际过程是这样的：

日志压缩保证了以下内容:
1、任何保持在日志头部以内的使用者都将看到所写的每条消息;这些消息将具有顺序偏移量。可以使用主题的min.compact .lag.ms来保证消息在被压缩之前必须经过的最短时间。也就是说，它为每个消息在(未压缩的)头部中停留的时间提供了一个下限。可以使用主题的max.compact .lag.ms来保证从编写消息到消息符合压缩条件之间的最大延迟。
2、始终保持消息的顺序。压缩永远不会重新排序消息，只是删除一些。
3、消息的偏移量永远不会更改。它是日志中位置的永久标识符。
4、从日志开始的任何使用者将至少看到所有记录的最终状态，按记录的写入顺序排列。此外，如果使用者在比主题的delete.retention短的时间内到达日志的头部，则会看到已删除记录的所有delete标记。ms设置(默认为24小时)。换句话说:由于删除标记与读取同时发生，所以如果删除标记的延迟超过delete. retain .ms。

日志压实细节：
日志清理器处理日志压缩，这是一个后台线程池，用于重新复制日志段文件，删除其键出现在日志头部的记录。每个压实器线程的工作原理如下：
1、它选择log head与log tail比率最高的log。
2、它为日志头部的每个键创建了最后偏移量的简要摘要。
3、它从头到尾重写日志，删除日志中稍后出现的键。新的、干净的段立即被交换到日志中，因此所需的额外磁盘空间只是一个额外的日志段(不是日志的完整副本)。
4、日志头的摘要本质上只是一个空间紧凑的哈希表。每个条目只使用24个字节。因此，使用8GB的清理缓冲区，一次清理迭代可以清理大约366GB的日志头(假设是1k消息)。

配置日志清理器：
默认情况下启用日志清理器。这将启动干净线程池。若要启用特定主题的日志清理，请添加特定于日志的属性：
1、log.cleanup.policy=compact
log.cleanup.policy策略属性是在代理服务器中定义的代理配置设置。属性文件;它影响集群中所有没有配置覆盖的主题，如本文所述。可以将日志清理器配置为保留日志的未压缩“头”的最小数量。这是通过设置压缩时间延迟来启用的。
2、log.cleaner.min.compaction.lag.ms
这可以用来防止对更新超过最小消息年龄的消息进行压缩。如果没有设置，除最后一个段(即当前写入的段)外，所有日志段都有资格进行压缩。即使活动段的所有消息都超过最小压缩时间延迟，也不会压缩活动段。可以配置日志清理器以确保最大延迟，在此之后，未压缩的日志“头”才有资格进行日志压缩。
3、log.cleaner.max.compaction.lag.ms
这可以用来防止低生产速率的日志在无限制的时间内不适合压缩。如果没有设置，日志不超过min.clean .dirty。比例未压实。注意，这个压缩截止日期并不是硬保证，因为它仍然受到日志清理线程可用性和实际压缩时间的限制。您将需要监视不可清理分区计数、最大清理时间秒和最大压缩延迟秒指标。

4. log.cleaner.delete.retention.ms 对于压缩日志保留的最长时间，也是客户端消费消息的最长时间(log.retention.ms是针对未compact的日志提供的删除时间, 而且仅针对非活动日志段, 如果一个过期段有一部分过期,那删还是不删???)

---

日志保存清理策略

属性名	含义	默认值
log.cleanup.polict	日志清理保存的策略只有delete和compact两种	delete
log.retention.hours	日志保存的时间，可以选择hours,minutes和ms	168(7day)
log.retention.bytes	删除前日志文件允许保存的最大值	-1
log.segment.delete.delay.ms	日志文件被真正删除前的保留时间	60000
log.cleanup.interval.mins	每隔一段时间多久调用一次清理的步骤	10
log.retention.check.interval.ms	周期性检查是否有日志符合删除的条件（新版本使用）	300000

这里特别说明一下，日志的真正清楚时间。当删除的条件满足以后，日志将被“删除”，但是这里的删除其实只是将该日志进行了“delete”标注，文件只是无法被索引到了而已。但是文件本身，仍然是存在的，只有当过了log.segment.delete.delay.ms 这个时间以后，文件才会被真正的从文件系统中删除。