概述
每当我们调用Kafka的poll()方法或者使用@KafkaListener(其实底层也是poll()方法)时，它都会返回之前被写入Kafka的记录，即我们组中的消费者还没有读过的记录。 这意味着我们有一种方法可以跟踪该组消费者读取过的记录。 如前所述，Kafka的一个独特特征是它不会像许多JMS队列那样跟踪消费过的记录。 相反，它允许消费者使用Kafka跟踪每个分区中的位置（偏移）。
我们将更新分区中当前位置的操作称为提交(commits)。
那么消费者是如何提交偏移量(offset)的呢？ 它向Kafka生成一条消息，指向一个特殊的 __consumer_offsets主题，包含每个分区需要提交的偏移量。 但是，如果消费者崩溃或新的消费者加入消费者群体，这将触发重新平衡(rebalance)。 在重新平衡之后，可以为每个消费者分配一组新的分区而不是之前处理的分区。 然后消费者将读取每个分区的已提交偏移量并从那里继续。
如果提交的偏移量小于客户端处理的最后一条消息的偏移量，那么最后处理的偏移量与提交的偏移量之间的消息将被处理两次，如下图：
如果提交的偏移量大于客户端实际处理的最后一条消息的偏移量，那么消费者组将忽略上次处理的偏移量与提交的偏移量之间的所有消息，如下图：
自动提交(Automatic Commit)
提交偏移量的最简单方法是允许消费者来完成。 如果配置 enable.auto.commit=true，则消费者每五秒钟将提交客户端从poll()收到的最大偏移量。 五秒间隔是默认值，可通过设置auto.commit.interval.ms来控制。 就像消费者中的其他机制一样，自动提交由poll loop驱动。 无论您何时轮询，消费者都会检查是否需要提交，如果是，它将提交它在上次轮询中返回的偏移量。
虽然这个选取很方便，但是它也有一定的不足。
请注意，默认情况下，自动提交每五秒钟发生一次。 假设我们在最近的提交之后三秒钟并且触发了重新平衡。 在重新平衡之后，所有消费者将从最后提交的偏移开始消费。 在这种情况下，偏移量是三秒钟之前偏移量，因此在这三秒内到达的所有事件将被处理两次。 可以将提交间隔配置为更频繁地提交并减少记录将被复制的窗口，但是不可能完全消除它们。
启用自动提交后，对poll的调用将始终提交上一轮询返回的最后一个偏移量。 它不知道实际处理了哪些事件，因此在再次调用poll()之前，始终处理完poll()返回的所有事件至关重要, 因为和poll()一样，close()方法也会自动提交偏移量。
自动提交很方便，但它们不能给开发人员足够的控制以避免重复的消息。
故最近在使用kafka的过程中遇到了一个疑问，在查阅了一些资料和相关blog之后，做一下总结和记录。
问题:消费者在消费消息的过程中，配置参数
spring.kafka.listener .ackMode设置为不自动提交offset，在消费完数据之后如果不手动提交offset，那么在程序中和kafak中的数据会如何被处理呢?
spring.kafka.listener.ackMode：指定消息确认模式，包括 RECORD、BATCH 和 MANUAL_IMMEDIATE等。可根据需求选择不同的确认模式，用于控制消息的确认方式。
ackMode是个枚举类型：
- RECORD
每处理一条commit一次 - BATCH(默认)
每次poll的时候批量提交一次，频率取决于每次poll的调用频率 - TIME
每次间隔ackTime的时间去commit - COUNT
累积达到ackCount次的ack去commit - COUNT_TIME
ackTime或ackCount哪个条件先满足，就commit - MANUAL
处理完业务后，手动调用Acknowledgment.acknowledge()先将offset存放到map本地缓存，在下一次poll之前从缓存拿出来批量提交。最终也是批量提交。 - MANUAL_IMMEDIATE
每次处理完业务，手动调用Acknowledgment.acknowledge()后立即提交
参考Kafka系列之SpringBoot集成Kafka
————————————————————————————————————————————————————————————
首先简单的介绍一下消费者对topic的订阅。客户端的消费者订阅了topic后，如果是单个消费者，那么消费者会顺序消费这些topic分区中的数据，如果是创建了消费组有多个消费者，那么kafak的服务端将这些topic平均分配给每个消费者。比如有2个topic,每个topic有2个分区，总共有4个分区，如果一个消费组开了四个消费者线程，那么每个消费者将被分配一个分区进行消费。一般建议是一个消费组里的消费者的个数与订阅的topic的总分区数相等，这样可以达到最高的吞吐量。如果消费者的个数大于订阅的topic的总分区，那么多出的消费者将分配不到topic的分区，等于是白白创建了一个消费者线程，浪费资源。
我们进入正题，对开头提出的问题的总结如些：
注意：以下情况均基于kafka的消费者关闭自动提交offset的条件下。亦是基于同一个消费者组的情况，因为不同的消费者组之间，他们彼此的offset偏移量是完全独立的。
-
如果消费端在消费kafka的数据过程中，一直没有提交offset，那么在此程序运行的过程中它不会重复消费。但是如果重启之后，就会重复消费之前没有提交offset的数据。
-
如果在消费的过程中有几条或者一批数据数据没有提交offset（比如异常情况程序没有走到手动提交的代码），后面其他的消息消费后正常提交offset至服务端，那么服务端会更新为消费后最新的offset，不会重新消费，就算重启程序或者rebalance也不会重新消费。
-
消费端如果没有提交offset，程序不会阻塞或者重复消费，除非在消费到这个你没有提交offset的消息时你新增或者减少消费端，此时会发生rebalance现象，即可再次消费到这个未提交offset的数据，产生重复消费问题。因为客户端也记录了当前消费者的offset信息，所以程序会在每次消费了数据之后，自己记录offset，而手动提交到服务端的offset与这个并没有关系，所以程序会继续往下消费。在发生rebalance现象之后，会从服务端得到最新的offset信息记录到本地。所以说如果当前的消费的消息没有提交offset，此时在你重新初始化消费者之后，可得到这条未提交消息的offset，从此位置开始消费。
