事件描述
公司使用的是Spring Cloud工作的微服务框架。其中做了SpringBoot和kafka的结合。但是意外的是enable.auto.commit参数设置成了false，kafka的offset依然提交了（也没有进行人工提交offset）。为了验证这个是否为真实情况，首先测试环境启动项目，enable.auto.commit设置为false。首先记录测试topic的偏移量和logsize（测试topic名字为topicTest），然后本地启动Producer，向topicTest发送10条数据，通过kafka manager观察是否发送到broker。经过查看，消息确实发送到了topicTest中。然后启动Consumer来消费，其中消费组为groupTest。查看kafka manager结果发现offset竟然偏移了。
心中很是郁闷，于是再向topicTest发送10条数据，自己写了个Consumer的main方法，配置也是enable.auto.commit为false。然后启动开始消费，惊人的情况出现了，offset并没有发生偏移。那么这就可以肯定问题出在了spring结合kafka这个点上。
查看spring的源码查找问题
为什么enable.auto.commit设置为false了依然会提交。猜测一定是spring做了什么手脚所以才导致的提交。打断点，追踪断点到KafkaMessageListenerContainer这个类里。可以发现一个很显眼的地方。
如果我们enable.auto.commit设置为false，那么就会走标红的if语句。而且下面有个stopInvokerAndCommitManualAcks()方法，看名字就知道是人工提交的意思。那么我们进去stopInvokerAndCommitManualAcks()方法瞅瞅。
如上图所示有个processCommits()方法，那么继续追进去：
单单看标红的方法是不是就知道这方法里面是更新offset和提交offset的方法。那么我们继续追进去：
看到这里是不是豁然开朗了。这tm明显是手动提交offset的代码啊。至此，终于明白为什么SpringBoot和Kafka结合后，用Spring的方法来初始化enable.auto.commit参数为false，offset依然会提交。
结论：Spring做为一个框架很明显是想减少我们的工作量。这就造成，如果我们把enable.auto.commit参数设置成true。那么offset交给kafka来管理，offset进行默认的提交模式。
enable.auto.commit参数设置成false。那么就是Spring来替为我们做人工提交，从而简化了人工提交的方式。
所以kafka和springboot结合中的enable.auto.commit为false为spring的人工提交模式。enable.auto.commit为true是采用kafka的默认提交模式。
最后终于送了一口气，要是enable.auto.commit的设置为false，而且没有进行人工提交offset，那么这将是一个巨大的工程事故。别看只是一个小小的参数。辛亏，Spring的开发者早已料到这一刻，从而防止小白忘记手动提交offset。另一方面也减少了开发的难易程度。