kafka消息在分区中是按序一条一条存储的，假如分区中有10条消息，位移就是0-9，
consumer消费了5条消息，那么offset就是5，指向了下一条要消费的记录，consumer
需要向kafka汇报自己的位移数据，因为consumer是能够消费多个分区的，所以offset
的粒度是分区，consumer需要为分配给他的各分区分别提交offset信息。
从用户的角度来说，位移提交分为自动提交和手动提交，在consumer的角度来说，位移
分为同步提交和异步提交。
offset提交原理
kafka内部有个topic叫 ‘__consumer_offsets’，offset提交就是往这个topic发送一条消息，
消息格式是key value形式，key是由 groupId、主题名、分区号组成，消息体是位移值
及用户自定义数据和时间戳等。还有2种特殊的格式，一种是用于保存 Consumer Group
信息的消息，用于注册group，另一种是 用于删除 Group 过期位移和删除 Group 的消息。
当kafka集群种第一台consumer启动时，便会创建__consumer_offsets主题，默认50个
分区和3个副本。
当提交方式是自动提交时，就算是当前consumer的offset已经不更新，kafka还是会自动
定期的往__consumer_offsets发送位移消息，所以得对位移主题的消息做定期删除，
假如对于同一个key有2条A和B，A早于B发送，那么A就是属于过期消息。
Compact 策略
compact有点类似jvm gc的标记-整理，把过期消息删掉，把剩下的消息排列在一起
Kafka 提供了专门的后台线程定期地巡检待Compact 的主题，看看是否存在满足条件的
可删除数据，这个线程叫Log Cleaner，当我们发现位移主题日志过多的时候，可以
检查一下是否是这个线程挂了导致的
自动提交导致重复消费
enable.auto.commit 默认即是true，
auto.commit.interval.ms 默认是5秒，表示kafka每5秒自动提交一次位移信息。
自动提交会有消息重复消费的问题，因为他是间隔时间提交一次，假如在间隔期间，
发生了Rebalance ，在Rebalance 之后所有的消费者必须从当前最新的offset开始
继续消费，那么上一次自动提交到Rebalance 的这段时间消费的数据的位移并没有
提交，所以会重复消费，即时我们通过减少 auto.commit.interval.ms 的值来提高提交频率，
那也仅仅是缩小了重复消费的时间窗口，所以我们看看能不能通过手动提交来避免重复消费。
同步提交及异步提交
commitSync()是consumer的同步api，手动提交的好处自然是我们可以控制提交的时机
和频率，由于是同步api，是会阻塞至broker返回结果才会结束这个阻塞状态，对于系统
而言，自然不想发生这种不是由于资源的限制导致的阻塞。
commitAsync()是consumer的异步api，commitAsync()不会阻塞，因此不会影响consumer的
tps，但是他的问题在于他无法重试，因为是异步提交，当因为网络或者系统资源阻塞
导致提交失败，那么他重试的时候，在这期间，consumer可能已经消费好多条消息
并且提交了，所以此时的重试提交的offset已然不是最新值了并没有意义，我们可以通过
异步和同步提交相结合，我们使用同步提交来规避因为网络问题或者broker端的gc导致的
这种瞬时的提交失败，进而通过重试机制而提交offset，使用异步提交来规避提交时的阻塞
分段式提交
前面的commitSync()和commitAsync()，都是consumer poll消息，把这些消息消费完，
再提交最新的offset，如果poll的消息很多呢？消费时间较长，假如中间系统宕机，岂不是
得从头再来一遍，所以kafka提供分段提交的api
commitSync(Map<TopicPartition, OffsetAndMetadata>)
commitAsync(Map<TopicPartition, OffsetAndMetadata>)
假设我们poll了一秒钟的数据，有5000条，我们可以通过计数器，累计到100条，
便通过分段提交api向kafka提交一次offset。
