Kafka consumer提交中的问题，如何选择？同步提交还是异步提交？

---

从用户角度来说“位移提交”分为自动提交和手动提交；从Consumer端角度来说分为同步提交和异步提交。

1.自动提交

自动提交就是Kafka Consumer在后台自动的为你提交，你不需要管理提交的问题。
在Apache Kafka下的API中只需要在Consmuer端设置参数就可以变为自动提交。

# 默认就是自动提交 true
enable.auto.commit=true

# 默认5000ms 和自动提交绑定的还有 自动提交间隔参数ms，比如每隔5s提交位移到broker端
auto.commit.interval.ms=5000

以下就是配置代码

Properties props = new Properties();
     props.put("bootstrap.servers", "localhost:9092");
     props.put("group.id", "test");
     props.put("enable.auto.commit", "true");
     props.put("auto.commit.interval.ms", "2000");
     props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
     props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
     KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
     consumer.subscribe(Arrays.asList("foo", "bar"));
     while (true) {
         ConsumerRecords<String, String> records = consumer.poll(100);
         for (ConsumerRecord<String, String> record : records)
             System.out.printf("offset = %d, key = %s, value = %s%n", record.offset(), record.key(), record.value());
     }

一旦设置了 enable.auto.commit 为 true，Kafka 会保证在开始调用 poll 方法时，提交上次 poll 返回的所有消息。从顺序上来说，poll 方法的逻辑是先提交上一批消息的位移，再处理下一批消息，因此它能保证不出现消费丢失的情况。但自动提交位移的一个问题在于，它可能会出现重复消费。

在默认情况下，Consumer 每 5 秒自动提交一次位移。现在，我们假设提交位移之后的 3 秒发生了 Rebalance 操作。在 Rebalance 之后，所有 Consumer 从上一次提交的位移处继续消费，但该位移已经是 3 秒前的位移数据了，故在 Rebalance 发生前 3 秒消费的所有数据都要重新再消费一次。虽然你能够通过减少 auto.commit.interval.ms 的值来提高提交频率，但这么做只能缩小重复消费的时间窗口，不可能完全消除它。这是自动提交机制的一个缺陷。

---

2.手动提交

与自动提交相反，手动提交非常灵活。需要将

2.1 enable.auto.commit值主动写为false

# 默认就是自动提交 true
enable.auto.commit=false

2.2 并且主动调用API手动提交位移

while (true) {
            ConsumerRecords<String, String> records =
                        consumer.poll(Duration.ofSeconds(1));
            process(records); // 处理消息
            try {
                        consumer.commitSync();
            } catch (CommitFailedException e) {
                        handle(e); // 处理提交失败异常
            }
}

---

2.3 同步提交和异步提交

2.3.1 同步提交的缺陷

当调用 commitSync() 同步提交的时候，Consumer 程序会处于阻塞状态，直到远端的 Broker 返回提交结果，这个状态才会结束。在任何系统中，因为程序而非资源限制而导致的阻塞都可能是系统的瓶颈，会影响整个应用程序的 TPS。当然，你可以选择拉长提交间隔，但这样做的后果是 Consumer 的提交频率下降，在下次 Consumer 重启回来后，会有更多的消息被重新消费。介于这个问题Kafka社区提供了一套异步提交方式

2.3.2 异步提交的缺陷

调用 commitAsync() 之后，它会立即返回，不会阻塞，因此不会影响 Consumer 应用的 TPS。由于它是异步的，Kafka 提供了回调函数（callback），供你实现提交之后的逻辑。代码如下：

while (true) {
            ConsumerRecords<String, String> records = 
	consumer.poll(Duration.ofSeconds(1));
            process(records); // 处理消息
            consumer.commitAsync((offsets, exception) -> {
	if (exception != null)
	handle(exception);
	});
}

commitAsync 的问题在于，出现问题时它不会自动重试。因为它是异步操作，倘若提交失败后自动重试，那么它重试时提交的位移值可能早已经“过期”或不是最新值了。因此，异步提交的重试其实没有意义，所以 commitAsync 是不会重试的。

2.3.3 将同步提交和异步提交相结合（commitSync 和 commitAsync 组合）

1. 可以利用同步提交的自动重试来规避瞬时错误，比如：网络抖动、Broker端GC等。这些短暂问题可以规避掉。
2. 并且利用异步提交来解决程序阻塞问题，从而不影响TPS系统吞吐量。
   代码如下：

try {
    while (true) {
        ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(1));
        process(records); // 处理消息
        commitAysnc(); // 使用异步提交规避阻塞
    }
} catch (Exception e) {
            handle(e); // 处理异常
} finally {
    try {
        consumer.commitSync(); // 最后一次提交使用同步阻塞式提交
	} finally {
	     consumer.close();
    }
}

这样既解决了

1. 同步提交中程序阻塞带来的问题
2. 异步提交中正确的位移数据问题

2.3.4 Kafka Consmer 提供的一种避免大批量重新消费的API

问题描述：
	设想这样一个场景：你的 poll 方法返回的不是 500 条消息，而是 5000 条。那么，你肯定
不想把这 5000 条消息都处理完之后再提交位移，因为一旦中间出现差错，之前处理的全部都要重来
一遍。这类似于我们数据库中的事务处理。很多时候，我们希望将一个大事务分割成若干个小事务分
别提交，这能够有效减少错误恢复的时间。

commitSync(Map<TopicPartition, OffsetAndMetadata>) 和 commitAsync(Map<TopicPartition, OffsetAndMetadata>)
它们的参数是一个 Map 对象，键就是 TopicPartition，即消费的分区，而值是一个 OffsetAndMetadata 对象，保存的主要是位移数据。（以commitAsync 异步提交为例，commitSync同步提交也一样）代码如下：

private Map<TopicPartition, OffsetAndMetadata> offsets = new HashMap<>();
int count = 0;
while (true) {
            ConsumerRecords<String, String> records = 
	consumer.poll(Duration.ofSeconds(1));
            for (ConsumerRecord<String, String> record: records) {
                        process(record);  // 处理消息
                        offsets.put(new TopicPartition(record.topic(), record.partition()),
                                    new OffsetAndMetadata(record.offset() + 1)；
                        if（count % 100 == 0）
                                    consumer.commitAsync(offsets, null); // 回调处理逻辑是 null
                        count++;
	}
}

---

3.总结

当理解了自动提交和手动提交以后，我们会选择手动提交，而在手动提交中，为了解决程序阻塞引起的非硬件性能问题和提交准确性问题，我们将选择以异步和同步结合的方式解决也就是 2.3.3 中所说。而面对大批量数据一次处理中我们还需要将多条消息拆分成小块，进行及时的提交位移给Broker端。来避免大批量的重复消费。

如有错误欢迎指正