手动提交偏移量的原因

最近拜读了很多文章,都谈到为了保证消息的安全消费(避免消息丢失和消息重复读取),建议消费者客户端手动提交偏移量。具体如下:
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消费者客户端是不是自己也存着一份偏移量,而这个偏移量,是实时更新的,所以,每次拉取数据时,从本地存储的偏移量后面拉取数据。但是因为本地的偏移量没有提交到服务端,所以新的消费者读取这个分区时,首先从服务端获取这个分区的偏移量,存到本地,从而造成了数据的重复读取。

Logo

Kafka开源项目指南提供详尽教程,助开发者掌握其架构、配置和使用,实现高效数据流管理和实时处理。它高性能、可扩展,适合日志收集和实时数据处理,通过持久化保障数据安全,是企业大数据生态系统的核心。

更多推荐