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消费者客户端是不是自己也存着一份偏移量，而这个偏移量，是实时更新的，所以，每次拉取数据时，从本地存储的偏移量后面拉取数据。但是因为本地的偏移量没有提交到服务端，所以新的消费者读取这个分区时，首先从服务端获取这个分区的偏移量，存到本地，从而造成了数据的重复读取。