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 组合)
- 可以利用同步提交的自动重试来规避瞬时错误,比如:网络抖动、Broker端GC等。这些短暂问题可以规避掉。
- 并且利用异步提交来解决程序阻塞问题,从而不影响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();
}
}
这样既解决了
- 同步提交中程序阻塞带来的问题
- 异步提交中正确的位移数据问题
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端。来避免大批量的重复消费。
如有错误欢迎指正