kafka日志存储

前言

    kafka的主题(topic)可以对应多个分区(partition)，而每个分区(partition)可以有多个副本(replica)，我们提生产工单创建topic的时候也是要预设这些参数的。但是它究竟是如何存储的呢？

    我们在使用kafka发送消息时，实际表现是提交日志，日志记录会一个接一个地追加到日志的末尾，同时为了避免单一日志文件过大无线膨胀，kafka采用了日志分段(LogSegment)的形式进行存储。所谓日志分段，就是当一个日志文件大小到达一定条件之后，就新建一个新的日志分段，然后在新的日志分段写入数据。每个日志段对象会在磁盘上创建一组文件，包括消息日志文件（.log）、位移索引文件（.index）、时间戳索引文件 （.timeindex），也就是说日志段才是kafka真正的日志文件存储基础单元。

    整个主题、分区、副本、日志关系如下：

    以__consumer_offsets这个topic为例，每一个目录对应一个分区，说明dev环境下这个topic有50个分区，每个子目录下存在多组日志段，也就是多组.log、.index、.timeindex 文件组合。

    进入/tmp/kafka-logs/__consumer_offset-49目录，下图中文件名的一串数字0是该日志段的起始位移值（Base Offset），也就是该日志段中所存的第一条消息的位移值，由此也可以推测出0000000000000000000.log中共有20条日志记录

配置

    前面是从生产配置和kafka目录的文件直观看到消息相关的内容，下面引入几个kafka消息相关的配置。

日志清理策略

  kafka log的清理策略有两种：delete,compact，默认是delete

• delete：一般是使用按照时间保留的策略，当不活跃的segment的时间戳是大于设置的时间的时候，当前segment就会被删除
• compact: 日志不会被删除，会被去重清理，这种模式要求每个record都必须有key，然后kafka会按照一定的时机清理segment中的key，对于同一个key只保留最新的那个key。同样的，compact也只针对不活跃的segment
  对应的配置是log.cleanup.policy: delete，对应topic级别的配置是cleanup.policy

消息保存时长

    Kafka 支持服务器级保留策略，我们可以通过配置三个基于时间的配置属性之一来调整该策略：

• log.retention.hours

• log.retention.minutes

• log.retention.ms
  其默认配置是log.retention.hours=168，即默认保留7天， Kafka自身会用较高精度值覆盖较低精度值。因此，如果在配置中新增log.retention.minutes=10，消息的保留时间将会变更位10分钟

   上面这个配置是服务器级别的，配置在server.properties中，每次新增创建topic时，如果不指定topic的日志保留时间，以上述配置为例，消息的保留时长就是7天，如果配置retention.ms=600000，这是从log.retention.minutes派生而来的，这个参数是topic级别的，配置了这个值，就会以这个值为准，创建topic之后，仍然可以单独调整retention.ms，来调整topic的保留时间
  

segment相关配置

    segment有两个很重要的配置

• log.segment.bytes

• log.roll.hours
  目前