Kafka手动提交偏移量的作用到底是什么???
Kafka手动提交1.一条一条处理并提交偏移量,某一条偏移量不提交,后面的偏移量提交后会覆盖掉前面的偏移量2.批量处理数据,不提交,会整体的偏移量都不提交。但是当新的数据进入kafka后,消费者也能接收新消息。但是偏移量没有提交到服务端,当发生分区再均衡时,其他消费者分到了这个分区,就会重复消费。没有发生分区再均衡的情况下,消费者本地存着一个分区的偏移量,所以在拉取的时候,会根据本地的偏移量去往后
手动提交偏移量的原因
最近拜读了很多文章,都谈到为了保证消息的安全消费(避免消息丢失和消息重复读取),建议消费者客户端手动提交偏移量。具体如下:
1.当设置为自动提交时,当kafka消费者读取到消息后,加入消费端处理业务报错,但是偏移量已经提交到了kafka服务端,则这条消息再无法进行处理了,这在MQ中相当于消息的丢失。
2.当设置为自动提交时,默认情况下美格5秒提交一次偏移量,假如在3秒的时候发生了分区再均衡,则偏移量没有提交上去,其他消费者获取到这个分区时,就出现了消息的重复消费。
猛地一听,确实存在这样的问题,所以我们设置为手动提交偏移量比较好。
但是细细一想,又觉得上面的说法都有问题。可能是本人才疏学浅,没有悟透其中的道理,下面我写一下我的想法,还请大牛为我指点一二。
个人见解
1.针对上述说的第一种情况,业务处理消息时报错了,而偏移量已经提交了,所以我们无法读取这条数据,相当于消息的丢失。这句话本身没有问题。但是即使设置成手动提交,又如何呢?我们在使用消费者连接kafka时,建立的是长连接,假如我们处理其中的某一条消息时,发生了异常,我们可以控制其偏移量不进行提交。但是这个消费者不可能因为这条业务数据的处理失败,就断开与kafka的连接吧,它还会继续去接收kafka的消息吧,当它接收到下一条消息时,处理成功了,我们肯定会提交下一条消息的偏移量吧,那这样的话,不就覆盖了之前没有提交的那一个偏移量了吗?这不还是相当于消息丢失了吗?
本人想到的处理方式,就是在数据库中存储处理失败的消息的偏移量,然后单独再去读取和处理这些偏移量的数据。这样说来,设置手动提交和自动提交,都一样了。所以不太理解手动提交避免消息丢失是什么原理。
2.针对上述的第二种情况,分区再均衡时,自动提交每到时间,不会提交,造成了数据可重复读取,这句话也是没问题的。本人还专门做了实验,kafka在发生分区再均衡时,确实不会等待客户端去提交偏移量,如果客户端没提交旧分区的偏移量,发生分区再均衡后,确实就没有机会再提交旧分区的偏移量了。
但是即使我们手动的去提交偏移量,我们也不知道何时发生分区再均衡,假如在我们手动调用提交偏移量的方法之前,发生了再均衡,它会提交偏移量吗?
而且kafka提供了分区再均衡监听器,我们完全可以在监听器中,让消费者提交各自的偏移量。所以,无论设置成手动提交还是自动提交,只要定义了分区再均衡监听器,就可以保证分区前的偏移量提交吧?
所以,综合上面的阐述,个人认为,我们完全可以把kafka设置成自动提交偏移量,然后将处理失败的偏移量,存入数据库单独处理,来避免消息的丢失;定义分区再均衡监听器,在分区发生之前提交消费者的偏移量,来避免消息的重复消费。这样理解,不知有何问题,还请大神指点一二。
额外收获
花费了一下午的时间,去试验kafka的机制,最终搞的是乱七八糟,一脸懵逼,但是也发现了其中的一些问题,分享一哈。
kafka消费者默认是一次性拉取500条数据。在我的实验中,一次性发送2000条消息到kafka,消息内容就是自然数字的递增。
broker中的主题只有一个分区,这样方便测试。
在消费端,设置成手动提交,且是批量处理一次性拉取得500条数据,处理完成后,提交一次偏移量。在消费端的逻辑中,做了判断,每当消息中包含5,就抛出一个异常。抛出异常后,偏移量就不再提交了。因为每个批次的500条数据里,都有带5的消息,所以,每个批次的偏移量,都提交不成功。
启动服务后,虽然每个批次的消息最后的偏移量都没有提交。但是这个消费者却能正确的按批次拉取数据。拉取完kafka服务端的这2000条数据后,实时给broker发数据,这个消费者也能实时的按照偏移量去正确读取数据。但是此时读取数据的偏移量都没有提交,所以发生分区再均衡时,新的消费者会重新拉取数据。
猜想:
kafka消费者客户端是不是自己也存着一份偏移量,而这个偏移量,是实时更新的,所以,每次拉取数据时,从本地存储的偏移量后面拉取数据。但是因为本地的偏移量没有提交到服务端,所以新的消费者读取这个分区时,首先从服务端获取这个分区的偏移量,存到本地,从而造成了数据的重复读取。
更多推荐
所有评论(0)