【kafka实践】09｜消费者位移

本文介绍: 新的位移管理机制也很简单，就是将 Con sum e r 的位移数据作为一条条普通的 Kaf k a 消息，提交到 __consumer _offset s 中。虽然我们可以手动修改位移主题，但它的消息格式却是Kaf ka自己定义的，不能随便修改，也就是说不能随意地向这个主题写消息，一旦你写入的消息不满足 Kaf ka 规定的格式，那么 Kaf ka 内部无法成功解析，就会造成 Bro k er 的崩溃。当然这只是大体的消息格式，实际上的设计比这个复杂的多，我们有个大体的概念即可，又深入了解的朋友欢迎评论区交流。

前面的章节中已经多次提到消费位移了，本节内容就要深入了解下消费位移topic：__consumer _offset s（前面是两个下划线），我们也可以称其为“位移主题”

上一节有提到老版本 Con sum er 的位移管理是通过Zo oKee per 实现的。当 Con sum er 重启时，从 Zo oKee per 中读取位移数据，继续上一次的消费。这使得 Kaf ka Bro k er 不需要保存位移数据，减少了 Bro k er 端需要持有的状态空间，有利于实现高伸缩性。

但Zo oKee per并不适用于这种高频写操作，因此Kaf ka在更新了几个版本之后，最终抛弃了位移管理机制，同时引入了__consumer _offset s这个内部主题。

新的位移管理机制也很简单，就是将 Con sum er 的位移数据作为一条条普通的 Kaf ka 消息，提交到 __consumer _offset s 中。__consumer_offsets 的主要作用是保存 Kafka 消费者的位移信息。它要求这个提交过程不仅要实现高持久性，还要支持高频的写操作。Kafka本身的设计就满足这两个条件，因此使用 __consumer_off sets 主题来保存位移就水到渠成了。

位移主题并不神秘，你可以手动地创建它、修改它，甚至删除它。不过大部分情况下，不需要管理它，既然是内部主体，把它交给 Kafka就行了。

虽然我们可以手动修改位移主题，但它的消息格式却是Kafka自己定义的，不能随便修改，也就是说不能随意地向这个主题写消息，一旦你写入的消息不满足 Kafka 规定的格式，那么 Kafka 内部无法成功解析，就会造成 Broker 的崩溃。

关于__c on sum er_off sets的消息格式，可以简单地理解为是一个 KV 对。Key 和 Value 分别表示消息的键值和消息体，既然是存储位移那value一定和就是位移信息，那key呢，大家可以先思考一下。位移主题的 Key 中应该保存 3 部分内容：groupId + topic信息 + partition信息，这样就能区分具体c on sumer的消费情况了！

当然这只是大体的消息格式，实际上的设计比这个复杂的多，我们有个大体的概念即可，又深入了解的朋友欢迎评论区交流。

通常当 Kafka 集群中的第一个 Con su mer 程序启动时，会自动创建位移主题。位移主题就是普通的 Kafka 主题，如果是Kafka自动创建的，分区数是怎么设置的呢？这取决于Broker端参数 off sets.topic.num.partitions的取值，默认值是 50，同理副本数通过 off sets.topic.replica t ion.factor 配置，它的默认值是 3。所以 Kafka 会自动创建一个 50 分区、副本为 3的位移主题。

简单提一下过期位移的删除，Kafka 使用 Co mpact 策略来删除位移主题中的过期消息，避免该主题数据堆积过多。同时Kafka 提供了专门的后台线程（Lo g Cleaner）定期地巡检待 Co mpact 的主题，看是否存在满足条件的可删除数据。如果生产环境中出现过位移主题用过多磁盘空间的问题，可以检查下是否是该现场挂掉。