消费者组的属性earliest没有一个初始的消费位置刚刚开始的时候这个消费者组里面根本就没有消费者第一个消费者启动了开始去消费了。第二种情况消费者进行消费的时候它是可以自动去提交消费到的offset已经消费到什么位置了。如果消费者有几天和几个星期都没有启动了再次进行启动消费的时候发现以前记录的offset已经过期了那些数据没了。这时候offset也不存在了。在这两种情况下从什么位置消费最早和最晚是最常用的。earliest并不是完全从头开始消费因为已经记录到了当前消费的位置offset是有效的存在的所以设置的earliest是无效的。可以通过seek方法去设置消费位置从哪个分区哪个位置精准开始消费。上面是一段消费者的API可以用它来消费Kafka的指定主题当中的消息。消费者在运行的过程当中消费数据会按照offset进行消费。offset是一条消息在Kafka主题中的唯一标志序列号。每当消费了一条消息offset就会自增一次这样可以保证有顺序的去消费数据。但是在消费的过程当中消费者宕机了出现了问题。当这个消费者再次启动消费的时候可能会出现一些情况当重新启动的时候如何选择消费的位置如果是从主题的头进行消费那么可能出现有一部分数据是冗余的会出现重复消费的情况这会出现问题。当然也不能让消费者从最新的位置开始消费因为从最新的位置开始消费会导致中间有一部分的数据没有消费到这样会导致一部分的数据丢失这样也会出现问题。最理想的情况就是还是从宕机的位置开始消费。比如之前消费到了offset 10的位置下次启动时候就是从11的位置开始消费了所以要记录下。如何去记录下这个偏移量呢Kafka会自动的去完成这样一个工作的它会周期性的帮你去提交offset不需要我们手动去管理。每隔一段时间Kafka会自动的把offset保存起来这样当消费者再次启动就能够从指定的offset开始消费。所以一般情况下是不需要人为干预的。还有一种情况是还没来的及提交offset消费者就宕机了。那么就会导致数据被重复消费了。如果让消费者自动的管理offset就有可能会出现这种情况。如何避免这种情况呢可以让他提交的周期变的短一些那么出现这种情况的概率就少很多。当然也可以手动提交offset首先将自动提交给关闭。在消费的时候每当你消费到了一条数据那么都要使用commit手动的offset提交和维护。这里有同步提交和异步提交同步就是会一直阻塞到提交成功offset。异步的就是不会去阻塞当前的线程但是也不知道提交成功还是失败了提交成功或者失败了可以去callback中进行处理。