Kafka系列（16）揭开位移的神秘面纱

Kafka中内部主题_consumer_offsets

Offsets Topic 

老版本的位移管理是依托于Apache Zookeeper,它会自动或者手动将位移数据提交到zookeeper中保存。

当Consumer重启后，它能自动从zookeeper中读取位移数据，从而在上次消费截至的地方继续消费。这种设计使得Kafka Broker不要保存位移数据，减少Broker端持有的状态空间，因而有利于实现高伸缩性。

但是，Zookeeper其实不适合用于这种高频的写操作。

Kafka社区自0.8.2.x版本，开始酝酿修改这种设计，并最终在新版本Consumer中正式推出全新的位移管理机制，自然也包括这个新的位移主题。

将Consumer的位移数据作为一条条普通的Kafka消息，提交到_consumer_offsets中。可以这么说 _consumer_offsets的主要作用是保存Kafka消费者的位移消息。要求过程不仅要实现高持久性，还要支持高频的写操作。

它的消息格式是Kafka自定义的，用户不能修改，一旦你写入的消息不满足Kafka规定的格式，那么Kafka内部无法成功解析，就会造成Broker的奔溃。事实上，Kafka Consumer有Api帮你提交位移，也就是向位移主题写消息。你千万不要自己写个Producer随意向该主题发送消息。

 

所谓消息格式，简单理解为一个kv对。Key 和Value 分别表示消息的键值和消息体。

位移主题的Key中应该保存3部分内容：

位移主题的Key 三种格式：

 1消息体保存了位移值

 2用于保存Consumer Group 信息的消息（tombstone消息，即墓碑消息 delete mark）

    何时写入这类消息，一旦某个Consumer Group下的所有Consumer实例都停止了，而且它们的位移数据也都被删除时，Kafka会向位移主题的对应分区写入tombstone消息，表明要彻底删除这个Group的消息。

 

 3用于删除Group 过期位移甚至是删除Group的消息

什么时候创建

当Kafka集群中的第一个Consumer程序启动时，Kafka会自动创建位移主题。

自动创建，分区数设置，要看Broker端参数offsets.topic.num.partitions 默认值是50

副本因子挥着备份因子怎么控制  offsets.topic.replication.factor 默认值是3

 

提交位移主题

Kafka Consumer 自动提交位移和手动提交位移

Consumer端有个参数叫enable.auto.commit 如果设置为true Consumer在后台默认为你定期提交位移，提交间隔由一个

专属的参数auto.commit.interval.ms来控制

自动提交有个显著优点，省事，你不用操心位移提交的事情，就能保证消息消费不会丢失。但这一点同时也是缺点，丧失了很大灵活性和可控性，完全没法把控Consumer端的位移管理

 

手动提交 consumer.commitSync 当调用这些方法，Kafka会向位移主题写入相应的消息。

Kafka是怎么删除位移主题中过期的消息呢？Compaction整理

Kafka使用Compact策略来删除位移主题中的过期消息，避免该主题无限期膨胀，那么应该如何定义Compact策略中的过期呢？

对于同一个Key的两条消息M1和M2,如果M1的发送时间早于M2，那么M1就是过期消息。Compact的过程就是扫描日志的所有消息，踢出那些过期的消息，然后把剩下的消息整理在一起。

 

图中位移为0 2 3 的消息的key都是K1 Compact之后，分区只需要保存位移为3的消息，因为它是最新发送的。

Kafka提供了专门的后台线程定期巡检待Compact的主题，看看是否存在满足条件的可删除数据。这个后台线程叫Log Cleaner

很多实际生产环境中都出现的位移主题无限膨胀占用过多磁盘空间的问题。如果你的环境中也有这个问题。建议查看一下Log Cleaner线程状态，通常是这个线程挂掉导致的。