Kafka 0.9如何在使用KafkaConsumer手动提交偏移时重新使用消息

时间:2016-01-20 13:46:07

标签: java apache-kafka kafka-consumer-api

我正在写一个消费者,一旦将一系列记录提交给Mongo,就会手动提交偏移量 在发生Mongo错误或任何其他错误的情况下,尝试将记录持久化到错误处理集合 以后重播。 如果Mongo失败,那么我希望消费者在尝试从Kakfa的非连续偏移中读取记录之前停止处理一段时间。
以下示例有效,但我想知道这种情况的最佳做法是什么?

while (true) {
    boolean commit = false;
    try {
        ConsumerRecords<K, V> records = consumer.poll(consumerTimeout);
        kafkaMessageProcessor.processRecords(records);
        commit = true;
    }
    catch (Exception e) {
        logger.error("Unable to consume closing consumer and restarting", e);
        try {
           consumer.close();
        }
        catch (Exception consumerCloseError) {
            logger.error("Unable to close consumer", consumerCloseError);
        }
        logger.error(String.format("Attempting recovery in  [%d] milliseconds.", recoveryInterval), e);
        Thread.sleep(recoveryInterval);
        consumer = createConsumer(properties);
    }
    if (commit) {
        consumer.commitSync();
    }

}

private KafkaConsumer<K, V> createConsumer(Properties properties) {
    KafkaConsumer<K, V> consumer = new KafkaConsumer<K, V>(properties);
    consumer.subscribe(topics);
    return consumer;
}

如果我没有重新创建消费者,我会收到以下错误。

o.a.k.c.c.internals.AbstractCoordinator  : Marking the coordinator 2147483647 dead.
o.a.k.c.c.internals.ConsumerCoordinator  : Error ILLEGAL_GENERATION occurred while committing offsets for group test.consumer

3 个答案:

答案 0 :(得分:8)

以下是使用客户端版本0.10.0的代码。

似乎可以满足你的要求。

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import java.util.Properties;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;

import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.KafkaConsumer;
import org.apache.kafka.clients.consumer.OffsetAndMetadata;
import org.apache.kafka.clients.consumer.OffsetCommitCallback;
import org.apache.kafka.common.TopicPartition;
import org.apache.kafka.common.serialization.StringDeserializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MessageProcesser implements Runnable {

    private static Logger logger = LoggerFactory.getLogger(MessageProcesser.class);

    private final ExecutorService pool = Executors.newFixedThreadPool(4);

    private final KafkaConsumer<String, String> consumer;

    private final String topic;

    private final AtomicBoolean closed = new AtomicBoolean(false);

    public MessageProcesser(String groupId, String topic, String kafkaServer) {
        this.topic = topic;
        Properties props = new Properties();
        props.put("bootstrap.servers", kafkaServer);
        props.put("group.id", groupId);
        props.put("key.deserializer", StringDeserializer.class.getName());
        props.put("value.deserializer", StringDeserializer.class.getName());
        props.put("enable.auto.commit", "false");
        this.consumer = new KafkaConsumer<>(props);
    }

    @Override
    public void run() {
        try {

            consumer.subscribe(Collections.singleton(topic));

            while (true) {
                if (closed.get()) {
                    consumer.close();
                }

                ConsumerRecords<String, String> records = consumer.poll(1000 * 60); 
                for (ConsumerRecord<String, String> record : records) {

                    String value = record.value();
                    if (null == value) {
                        continue;
                    }

                    boolean processResult = false;
                    try {
                        Future<Object> f = pool.submit(new ProcessCommand(value));
                        processResult = (boolean) f.get(100, TimeUnit.MILLISECONDS);
                    } catch (Exception e) {
                        logger.error(e.getMessage(), e);
                    }

                    if (!processResult) {
                        //here if process fail, seek to current offset
                        consumer.seek(new TopicPartition(record.topic(), record.partition()), record.offset());
                    } else {
                        this.commitAsyncOffset(record);
                    }
                }
            }
        } catch (Exception e) {
            logger.error(e.getMessage(), e);
            if (!closed.get()) {
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e1) {
                    // ignore
                }
            }
        }
    }

    public void shutdown() {
        closed.set(true);
    }

    public void commitAsyncOffset(ConsumerRecord<String, String> record) {
        Map<TopicPartition, OffsetAndMetadata> offsets = new HashMap<>();
        offsets.put(new TopicPartition(record.topic(), record.partition()), new OffsetAndMetadata(record.offset() + 1));

        consumer.commitAsync(offsets, new OffsetCommitCallback() {
            @Override
            public void onComplete(Map<TopicPartition, OffsetAndMetadata> offsets, Exception e) {
                if (e != null) {
                    logger.error("kafka offset commit fail. {} {}", offsets, PushUtil.getStackString(e.getStackTrace()));
                }
            }
        });
    }
}

答案 1 :(得分:6)

如果您没有提交偏移量且auto.commit.enable属性为false,那么当对Mongo的调用失败时,您只需等待您认为必要的时间并重试poll()。

你看到的问题是新的消费者使用poll()作为心跳机制,所以如果你等待更长时间的超时请求,那么主题的协调者将推出消费者,因为它会认为已经死了它将重新平衡该组。所以等待mongo,但你可能想在一段时间内轮询()。

编辑:作为一种解决方法,您可以将此属性设置为更高的request.timeout.ms

希望它有所帮助!

答案 2 :(得分:2)

据我了解,(新)客户端是保持消耗的偏移量的客户端。提交将偏移量发送到服务器,但它对来自该客户端的下一轮询没有影响,因为客户端对服务器说“给我下一个消息”。 那为什么发送到服务器的偏移量呢?对于下一次重新平衡。因此,唯一情况服务器使用提交的偏移是当某个客户端死亡/断开连接时 - 然后重新平衡分区,并且通过重新平衡,客户端从服务器获得偏移量。

因此,如果您不提交偏移量然后调用poll(),则不能指望再次读取该消息。为此,必须有可能在客户端中回滚偏移量。我没有尝试,但我认为将KafkaConsumer.seek调用到失败消息的偏移应该可以解决问题。

https://kafka.apache.org/090/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#seek(org.apache.kafka.common.TopicPartition,%20long)

BTW,通过这种方式,你甚至可以提交最后一个成功处理的消息,并寻找第一个失败的消息,这样你就不需要重复整个记录列表,当它中间的某些消息发生故障时。