Kafka消费者一些重要参数

消费者重复消费场景：
假设刚刚提交完一次消费位移，然后拉取一批消息进行消费，在下一次自动提交消费位移之前，消费者崩溃了，那么又得从上一次位移提交的地方重新开始消费，这样便发生了重复消费的现象（对于再均衡的情况同样适用）。我们可以通过减小位移提交的时间间隔来减小重复消息的窗口大小，但这样   并不能避免重复消费的发送，而且也会使位移提交更加频繁

消费者丢失消息场景：
按照一般思维逻辑而言，自动提交是延时提交，重复消费可以理解，那么消息丢失又是在什么情形下   会发生的呢？我们来看下图中的情形：

拉取线程不断地拉取消息并存入本地缓存，比如在 BlockingQueue 中，另一个处理线程从缓存中读取消息并进行相应的逻辑处理。设目前进行到了第 y+l 次拉取，以及第 m 次位移提交的时候，也就是x+6 之前的位移己经确认提交了，处理线程却还正在处理 x+3 的消息；此时如果处理线程发生了异常， 待其恢复之后会从第 m 次位移提交处，也就是 x+6 的位置开始拉取消息，那么 x+3 至 x+6  之间的消息就没有得到相应的处理，这样便发生消息丢失的现象。

重要配置:

enable.auto.commit和auto.commit.interval.ms
Kafka 中默认的消费位移的提交方式是自动提交，这个由消费者客户端参数 enable.auto.commit 配置， 默认值为 true 。当然这个默认的自动提交不是每消费一条消息就提交一次，而是定期提交，这个定期的周期时间由客户端参数 auto.commit.interval.ms 配置，默认值为 5 秒，此参数生效的前提是 enable. auto.commit 参数为 true。
在默认的方式下，消费者每隔 5 秒会将拉取到的每个分区中最大的消息位移进行提交。自动位移提交的动作是在 poll() 方法的逻辑里完成的，在每次真正向服务端发起拉取请求之前会检查是否可以进行位移提交，如果可以，那么就会提交上一次轮询的位移。自动提交是延时提交

手动提交又分为同步提交和异步提交，对应于 KafkaConsumer 中的 commitSync()和commitAsync()两种类型的方法。

同步提交：

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000)); 
    for (ConsumerRecord<String, String> r : records) {
     //do something to process record.
    }
    consumer.commitSync();
}

对于采用 commitSync()的无参方法，它提交消费位移的频率和拉取批次消息、处理批次消息的频率是一样的，如果想寻求更细粒度的、更精准的提交，那么就需要使用 commitSync()的另一个有参方法， 具体定义如下：

while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000)); 
    for (ConsumerRecord<String, String> r : records) {
      long offset = r.offset();
      //do something to process record.

      TopicPartition topicPartition = new TopicPartition(r.topic(), r.partition());

      consumer.commitSync(Collections.singletonMap(topicPartition,new OffsetAndMetadata(offset+1)));
    }
}

异步提交：
异步提交的方式（ commitAsync()）在执行的时候消费者线程不会被阻塞；可能在提交消费位移的结果还未返回之前就开始了新一次的拉取操 。异步提交以便消费者的性能得到一定的增强。 commitAsync 方法有一个不同的重载方法，具体定义如下

 

while (true) {
  ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000)); 
  for (ConsumerRecord<String, String> r : records) {
    long offset = r.offset();

    //do something to process record.
    TopicPartition topicPartition = new TopicPartition(r.topic(), r.partition()); 
    consumer.commitAsync(Collections.singletonMap(topicPartition, new OffsetAndMetadata(offset + 1)), 
      new OffsetCommitCallback() {
        @Override
        public void onComplete(Map<TopicPartition, OffsetAndMetadata> map, Exception e) { 
          if(e == null ){
          System.out.println(map);
          }else{
          System.out.println("error commit offset");
          }
        }
    });
  }
}

fetch.min.bytes
一次拉取的最小字节数(1B)

fetch.max.bytes
一次拉取的最大数据量(50M)

fetch.max.wait.ms
拉取时的最大等待时长(500ms)

max.partition.fetch.bytes
每个分区一次拉取的最大数据量(1MB)

max.poll.records
一次拉取的最大条数(500)

connections.max.idle.ms
网络连接的最大闲置时长(540000ms)

request.timeout.ms
一次请求等待响应的最大超时时间，consumer 等待请求响应的最长时间(30000ms)

metadata.max.age.ms
元数据在限定时间内没有进行更新，则会被强制更新(300000)

reconnect.backoff.ms
尝试重新连接指定主机之前的退避时间(50ms)

retry.backoff.ms
尝试重新拉取数据的重试间隔(100ms)

isolation.level
隔离级别！决定消费者能读到什么样的数据read_uncommitted：可以消费到 LSO（LastStableOffset）位置； read_committed：可以消费到 HW（High Watermark）位置

max.poll.interval.ms
超过时限没有发起 poll 操作，则消费组认为该消费者已离开消费组