### --- 概念~~~     日志压缩是Kafka的一种机制，可以提供较为细粒度的记录保留，
~~~     而不是基于粗粒度的基于时间的保留。
~~~     对于具有相同的Key，而数据不同，只保留最后一条数据，前面的数据在合适的情况下删除。

### --- 应用场景~~~     日志压缩特性，就实时计算来说，可以在异常容灾方面有很好的应用途径。
~~~     比如，我们在Spark、Flink中做实时计算时，需要长期在内存里面维护一些数据，
~~~     这些数据可能是通过聚合了一天或者一周的日志得到的，
~~~     这些数据一旦由于异常因素(内存、网络、磁盘等)崩溃了，从头开始计算需要很长的时间。
~~~     一个比较有效可行的方式就是定时将内存里的数据备份到外部存储介质中，当崩溃出现时，
~~~     再从外部存储介质中恢复并继续计算。
~~~     使用日志压缩来替代这些外部存储有哪些优势及好处呢？

### --- 这里为大家列举并总结了几点：~~~     Kafka即是数据源又是存储工具，可以简化技术栈，降低维护成本
~~~     使用外部存储介质的话，需要将存储的Key记录下来，恢复的时候再使用这些Key将数据取回，
~~~     实现起来有一定的工程难度和复杂度。
~~~     使用Kafka的日志压缩特性，只需要把数据写进Kafka，
~~~     等异常出现恢复任务时再读回到内存就可以了
~~~     Kafka对于磁盘的读写做了大量的优化工作，比如磁盘顺序读写。
~~~     相对于外部存储介质没有索引查询等工作量的负担，可以实现高性能。
~~~     同时，Kafka的日志压缩机制可以充分利用廉价的磁盘，不用依赖昂贵的内存来处理，
~~~     在性能相似的情况下，实现非常高的性价比(这个观点仅仅针对于异常处理和容灾的场景来说)

### --- 日志压缩方式的实现细节~~~     # 主题的cleanup.policy 需要设置为compact。
~~~     # Kafka的后台线程会定时将Topic遍历两次：
~~~     记录每个key的hash值最后一次出现的偏移量
~~~     第二次检查每个offset对应的Key是否在后面的日志中出现过，如果出现了就删除对应的日志。
~~~     日志压缩允许删除，除最后一个key之外，删除先前出现的所有该key对应的记录。
~~~     在一段时间后从日志中清理，以释放空间。
~~~     # 注意：日志压缩与key有关，确保每个消息的key不为null。
~~~     # 压缩是在Kafka后台通过定时重新打开Segment来完成的，Segment的压缩细节如下图所示：

### --- 日志压缩可以确保~~~     任何保持在日志头部以内的使用者都将看到所写的每条消息，这些消息将具有顺序偏移量。
~~~     可以使用Topic的min.compaction.lag.ms属性来保证消息在被压缩之前必须经过的最短时间。
~~~     也就是说，它为每个消息在(未压缩)头部停留的时间提供了一个下限。
~~~     可以使用Topic的max.compaction.lag.ms属性来保证从收到消息到消息符合压缩条件之间的最大延时
~~~     消息始终保持顺序，压缩永远不会重新排序消息，只是删除一些而已
~~~     消息的偏移量永远不会改变，它是日志中位置的永久标识符
~~~     从日志开始的任何使用者将至少看到所有记录的最终状态，按记录的顺序写入。
~~~     另外，如果使用者在比Topic的log.cleaner.delete.retention.ms短的时间内到达日志的头部，
~~~     则会看到已删除记录的所有delete标记。保留时间默认是24小时。

### --- 默认情况下，启动日志清理器，若需要启动特定Topic的日志清理，请添加特定的属性。~~~     配置日志清理器，这里为大家总结了以下几点：
~~~     log.cleanup.policy 设置为compact ，Broker的配置，影响集群中所有的Topic。
~~~     log.cleaner.min.compaction.lag.ms ，用于防止对更新超过最小消息进行压缩，
~~~     如果没有设置，除最后一个Segment之外，所有Segment都有资格进行压缩
~~~     log.cleaner.max.compaction.lag.ms ，用于防止低生产速率的日志在无限制的时间内不压缩。
~~~     Kafka的日志压缩原理并不复杂，就是定时把所有的日志读取两遍，写一遍，
~~~     而CPU的速度超过磁盘完全不是问题，
~~~     只要日志的量对应的读取两遍和写入一遍的时间在可接受的范围内，那么它的性能就是可以接受的。