Kafka提交offset机制

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kafka提交offset机制相关的知识,希望对你有一定的参考价值。

参考技术A 【转】 https://www.baidu.com/link?url=3sPGFihkBbhc41jSaAzCwPnANCbs1z56_l4a1eXnhRtd2XxT5B4r7_2HB3wJT2IhoGMzpD858l_RKRrU8TDQm_&wd=&eqid=e88a5ce70002861e000000035d4cdc76

在kafka的消费者中,有一个非常关键的机制,那就是offset机制。它使得Kafka在消费的过程中即使挂了或者引发再均衡问题重新分配Partation,当下次重新恢复消费时仍然可以知道从哪里开始消费。它好比看一本书中的书签标记,每次通过书签标记(offset)就能快速找到该从哪里开始看(消费)。

Kafka对于offset的处理有两种提交方式:(1) 自动提交(默认的提交方式) (2) 手动提交(可以灵活地控制offset)

kafka consumer offset机制

参考技术A kafka消息在分区中是按序一条一条存储的,假如分区中有10条消息,位移就是0-9,

consumer消费了5条消息,那么offset就是5,指向了下一条要消费的记录,consumer

需要向kafka汇报自己的位移数据,因为consumer是能够消费多个分区的,所以offset

的粒度是分区,consumer需要为分配给他的各分区分别提交offset信息。

从用户的角度来说,位移提交分为自动提交和手动提交,在consumer的角度来说,位移

分为同步提交和异步提交。

kafka内部有个topic叫 ‘__consumer_offsets’,offset提交就是往这个topic发送一条消息,

消息格式是key value形式,key是由 groupId、主题名、分区号组成,消息体是位移值

及用户自定义数据和时间戳等。还有2种特殊的格式,一种是用于保存 Consumer Group 

信息的消息,用于注册group,另一种是 用于删除 Group 过期位移和删除 Group 的消息。

当kafka集群种第一台consumer启动时,便会创建__consumer_offsets主题,默认50个

分区和3个副本。

当提交方式是自动提交时,就算是当前consumer的offset已经不更新,kafka还是会自动

定期的往__consumer_offsets发送位移消息,所以得对位移主题的消息做定期删除,

假如对于同一个key有2条A和B,A早于B发送,那么A就是属于过期消息。

compact有点类似jvm gc的标记-整理,把过期消息删掉,把剩下的消息排列在一起

Kafka 提供了专门的后台线程定期地巡检待Compact 的主题,看看是否存在满足条件的

可删除数据,这个线程叫Log Cleaner,当我们发现位移主题日志过多的时候,可以

检查一下是否是这个线程挂了导致的

enable.auto.commit 默认即是true,

auto.commit.interval.ms 默认是5秒,表示kafka每5秒自动提交一次位移信息。

自动提交会有消息重复消费的问题,因为他是间隔时间提交一次,假如在间隔期间,

发生了Rebalance ,在Rebalance 之后所有的消费者必须从当前最新的offset开始

继续消费,那么上一次自动提交到Rebalance 的这段时间消费的数据的位移并没有

提交,所以会重复消费,即时我们通过减少 auto.commit.interval.ms 的值来提高提交频率,

那也仅仅是缩小了重复消费的时间窗口,所以我们看看能不能通过手动提交来避免重复消费。

commitSync()是consumer的同步api,手动提交的好处自然是我们可以控制提交的时机

和频率,由于是同步api,是会阻塞至broker返回结果才会结束这个阻塞状态,对于系统

而言,自然不想发生这种不是由于资源的限制导致的阻塞。

commitAsync()是consumer的异步api,commitAsync()不会阻塞,因此不会影响consumer的

tps,但是他的问题在于他无法重试,因为是异步提交,当因为网络或者系统资源阻塞

导致提交失败,那么他重试的时候,在这期间,consumer可能已经消费好多条消息

并且提交了,所以此时的重试提交的offset已然不是最新值了并没有意义,我们可以通过

异步和同步提交相结合,我们使用同步提交来规避因为网络问题或者broker端的gc导致的

这种瞬时的提交失败,进而通过重试机制而提交offset,使用异步提交来规避提交时的阻塞

前面的commitSync()和commitAsync(),都是consumer poll消息,把这些消息消费完,

再提交最新的offset,如果poll的消息很多呢?消费时间较长,假如中间系统宕机,岂不是

得从头再来一遍,所以kafka提供分段提交的api

commitSync(Map<TopicPartition, OffsetAndMetadata>) 

 commitAsync(Map<TopicPartition, OffsetAndMetadata>)

假设我们poll了一秒钟的数据,有5000条,我们可以通过计数器,累计到100条,

便通过分段提交api向kafka提交一次offset。

以上是关于Kafka提交offset机制的主要内容,如果未能解决你的问题,请参考以下文章

kafka 提交offset

kafka消费端提交offset的方式

kafka消费者和offset的关系,以及异常处理问题

kafka auto.offset.reset latest earliest 详解

Springboot 整合Kafka 实现手动提交 offset

Kafka问题优化之消费重复问题