【Kafka源码】KafkaConsumer

[TOC]

---

KafkaConsumer是从kafka集群消费消息的客户端。这是kafka的高级消费者，而SimpleConsumer是kafka的低级消费者。何为高级？何为低级？

我们所谓的高级，就是可以自动处理kafka集群的失败信息，也可以适应kafka集群中消息的分区迁移。这个客户端也可以与服务端进行交互，使用消费者分组负载平衡消费，下面我们具体会讲解。

消费者与对应的broker保持TCP连接，来获取数据。使用完成后关闭消费者连接失败，会泄露连接。这个消费者不是线程安全的。

一、偏移量和消费者位置Offsets And Consumer position

Kafka在分区中为每条记录维护了一个数字形式的偏移量。这个偏移量是数据在分区中的唯一值，也可以表示为消费者在分区中的偏移量。例如，一个消费者的偏移量为5，表示偏移量为0到4的消息已经被消费过。关于消费者使用的偏移量，有两个比较重要的概念。

1.1 TopicPartition

消费者的偏移量表示消费者下一个需要消费的消息的偏移量。这个值会比当前消费者在那个分区刚刚消费的消息偏移量大一。这个值在下面情况下会自动增长：消费者调用了poll(long)并且获取到了消息。

1.2 committed position提交偏移量

这个committed position表示最新的被安全保存的偏移量。如果当前过程中失败然后重启了，这个是重启后消费的偏移量起点。消费者有三种方式来提交偏移量：

• 自动定时提交
• 同步提交。手动提交偏移量，使用的方法是commitSync()，这个方法会一直被阻塞，直到偏移量被成功提交了，或者在提交过程中发生了严重的错误。
• 异步提交。使用的方法是commitAsync(OffsetCommitCallback)，在成功或者发生严重错误后，会触发OffsetCommitCallback方法。

二、消费分组和主题订阅Consumer Groups and Topic Subscriptions

Kafka使用消费分组的概念，允许一个处理池来将消费和处理过程分开。这些处理可以在同一台机器上运行，也可以分布在多台机器上，来提供扩展性和容错。

每个Kafka消费者都可以配置自己所属的消费分组，并且可以通过接口subscribe(Collection, ConsumerRebalanceListener)动态设置订阅的主题。Kafka会把每条消息传递到分组中的某个运行过程。这是通过平衡消费分组中的每个消费者对应的分区来实现的，最终实现的是每个分组正好被分配到分组的某个消费者。所以如果一个主题有4个分区，一个消费分组有两个消费者process，每个process会消费两个分区。

消费分组中的成员是动态的：如果某个process挂了，分配给他的分区会被分到组中其他的process。类似的，如果一个新的消费者加入了分组，分区会迁移到新的分组上。这被称为分组平衡。需要注意的是，当订阅的主题中新的分区出现的时候，相同的情况也会出现：分组不断地检测新的分区，平衡分组，最终每个分区都被分配到某个组成员上。

概念上，你可以把消费分组想象成一个单独的逻辑上的消费者，恰巧有多个消费进程。作为一个多订阅的系统，kafka天然支持某个主题有多个消费分组，而数据不会重复。

这些功能对于一个消息系统来说很普通。和传统的消息队列不同，你可以同时有很多的分组。在传统消息系统中，每个消费者都会有自己的消费分组，所以每个消费者会订阅主题下的所有记录，也就是会收到所有的消息。

而且，当分组重新分配自动出现时，会通过ConsumerRebalanceListener通知消费者，然后消费者自身处理一些应用级的逻辑，比如状态清除，手动提交offset等等。

对消费者来说，还可以手动分配分区，使用的方法是assign（类似于SimpleConsumer）。在这种情况下，动态分区调整和消费分组协调功能会被禁用。

三、检测消费者失败Detecting Consumer Failures

订阅一批主题之后，消费者在调用poll的时候，会自动加入分组。poll是用于确保消费者的存活。只要消费者不停地调用poll，那么他就会一直存在于分组中，并且不断地收到对应分区推送给他的消息。另外，poll方法也会定时发送心跳给服务端，当你停止调用poll时，心跳也会停止。如果server超过session.timeout时间没有收到心跳，消费者会被踢出分组，分区也会重新分配。这是为了防止消费者挂掉之后，还占用分区的情况发生（这种情况下分组中的其他消费者无法消费到消息）。为了继续存在于分组中，消费者必须调用poll方法证明还活着。

这个设计的目的还在于，一个poll循环中的消息处理过程的时间必须是有界的，那样心跳才能在session.timeout之前发出去。消费者提供两个配置来控制这种行为：

• session.timeout.ms：通过增加这个值，消费者可以有更多的时间来处理poll返回的一批消息。唯一的缺点就是服务端要耗费更多的时间来检测消费者是否存活，这可能会导致分组平衡的延迟。然后，这不会影响close方法的调用，因为一旦调用了这个方法，消费者会发送一个明确的消息给服务端，离开分组，分组平衡会被立即触发。
• max.poll.records：一个poll循环的处理时间应该和消息的数量成正比。所以应该设置一次最多处理多少条数据。默认情况下，这个值没有限制消息的数量。

三、举例

当前消费客户端提供了多种方法来消费，下面是几个例子。

3.1 自动提交Automatic Offset Committing

这个方法说明了kafka消费客户端的简单使用，依赖于自动提交offset。

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", "1000");
props.put("session.timeout.ms", "30000");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
KafkaConsumer consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("foo", "bar"));
while (true) {
    ConsumerRecords records = consumer.poll(100);
    for (ConsumerRecord record : records)
        System.out.printf("offset = %d, key = %s, value = %s", record.offset(), record.key(), record.value());
}

配置enable.auto.commit表示是自动提交offset，并且提交的频率为auto.commit.interval.ms。服务器可以通过bootstrap.servers来配置，可以不用配置全部的服务器，因为会自动发现集群中所有的服务器。当然不建议只配置一个，因为如果这个挂掉了，就找不到其他的机器了。

反序列化配置表示如何把二进制消息转换为消息对象。例如，使用string反序列化，表示消息的key和value都是字符串。

3.2 手动提交偏移量Manual Offset Control

与自动提交不同，我们可以通过配置来控制消息什么时候消费完成，并提交偏移量。在一条消息需要多个任务处理，所有任务完成后才能提交偏移量的场景下，需要手动提交。在下面的例子中，我们会一次消费一批数据，然后把他们放到内存中，当消息达到一定的数量时，我们会把他们插入数据库中。如果这种情况下，我们配置为自动提交，那么就会出现消息被消费，但是实际上并没有插入到数据库的情况。为了避免这种情况，我们必须在消息插入数据库之后，手动提交偏移量。这也会出现另一种情况，就是消息插入数据库成功，但是在提交偏移量的过程中失败。这种情况下，其他的消费者会继续读取偏移量，然后重新执行批量插入数据库的操作。这么使用的话，kafka提供的是“至少一次”的消息保证，也就是消息至少会被传递一次，但是消费失败的情况下会重复消费。

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "test");
props.put("enable.auto.commit", "false");
props.put("auto.commit.interval.ms", "1000");
props.put("session.timeout.ms", "30000");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
KafkaConsumer consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("foo", "bar"));
final int minBatchSize = 200;
List> buffer = new ArrayList<>();
while (true) {
    ConsumerRecords records = consumer.poll(100);
    for (ConsumerRecord record : records) {
        buffer.add(record);
    }
    if (buffer.size() >= minBatchSize) {
        insertIntoDb(buffer);
        consumer.commitSync();
        buffer.clear();
    }
}

上面的例子使用的是同步提交commitSync()方法。在某些情况下，你可能需要对消息消费有更加精确的控制，下面的例子中，我们按照分区提交偏移量。

try {
    while(running) {
        ConsumerRecords records = consumer.poll(Long.MAX_VALUE);
        for (TopicPartition partition : records.partitions()) {
            List> partitionRecords = records.records(partition);
            for (ConsumerRecord record : partitionRecords) {
                System.out.println(record.offset() + ": " + record.value());
            }
            long lastOffset = partitionRecords.get(partitionRecords.size() - 1).offset();
            consumer.commitSync(Collections.singletonMap(partition, new OffsetAndMetadata(lastOffset + 1)));
        }
    }
} finally {
  consumer.close();
}

注意：提交的偏移量应该是下一次消费的消息的偏移量，所以commitSync(offsets)这个方法中的内容，应该是当前消息偏移量加上一。

3.3 手动分配分区Manual Partition Assignment

前面的例子中，消费者订阅主题，然后服务端动态分配了分区给消费者。在某些情况下，我们需要精确控制消费的分区，例如：

消费者维护了与分区相关的本地状态（例如本地磁盘键值存储），那么他应该只读取特定分区的数据。如果消费者本身是高可用的，在挂掉之后会自动重启（可能正在使用集群管理框架，比如YARN，Mesos或者AWS，或者作为流式处理框架）。这种情况下，kafka没必要检测消费者的存活，重新分配分区，因为消费进程会在同样的机器上重启。

为了使用这种模式，我们不能使用subscribe(Collection)，而是应该使用assign(Collection)方法，来指定一批分区。

String topic = "foo";                                    
TopicPartition partition0 = new TopicPartition(topic, 0);
TopicPartition partition1 = new TopicPartition(topic, 1);
consumer.assign(Arrays.asList(partition0, partition1));  

这种情况下，不会使用到分组协调器，所以消费者挂掉的情况，也不会重新分配分区。所以每个消费者都是独立的，为了避免偏移量提交冲突，每个消费者的分组信息应该是唯一的。

3.4 在kafka外存储偏移量Storing Offsets Outside Kafka

消费者应用可能不想把offset存到kafka中，所以kafka也提供了把offset存储到其他地方的接口。这种情况下，就能自己实现消息只消费一次的场景，比至少一次强很多。那么我们如何使用呢？

• 首先需要配置enable.auto.commit=false
• 使用ConsumerRecord提供的偏移量来存储你的offset
• 重启时使用seek(TopicPartition, long)来发现重启前的offset

这种场景在手动分配分区的情况下很简单。如果分区分配是自动的，我们需要特殊处理分区分配改变的情况。这个可以通过提供ConsumerRebalanceListener实例，在调用subscribe(Collection, ConsumerRebalanceListener)和subscribe(Pattern, ConsumerRebalanceListener)时实现。

3.5 控制消费者位点Controlling The Consumer's Position

大多数情况下，消费者会简单的从头到尾消费消息，定时提交位点（自动或手动）。然后，kafka允许消费者手动控制位点，可以设置位点的位置。这意味着消费者可以消费已经消费过的消息，也可以跳过最新的消息。

kafka可以通过seek(TopicPartition, long)方法来指定消费起点，寻找早的或者新的位点，也可以通过seekToBeginning(Collection)和seekToEnd(Collection)来指定。

3.6 消费流量控制

如果一个消费者被分配到了多个分区，他会尝试同时消费所有的分区，所有的分区的权重一样。然而，在某些情况下，消费者需要首先全速消费某些特定的分区，当这个分区没有消息后再消费其他的分区。

例如，流式处理。消费者同时从两个主题消费，然后把消息合并。当某个主题落后于另一个主题很多时，消费者应该停止消费快的那个主题，等慢的那个赶上来。再比如，有个主题有很多历史数据需要被消费，这种情况下，消费者应该优先消费那些有最新消息的主题。

kafka支持动态控制消费流量，通过pause(Collection)和resume(Collection)方法。

四、多线程消费Multi-threaded Processing

kafka消费者不是线程安全的。所有的网络IO操作都在发起调用的一个线程中执行。他需要保证多线程时的线程安全。不同的操作会引起ConcurrentModificationException。

我们在外部线程中可以调用wakeup()方法来停止当前的操作。这种情况下，可能会从阻塞操作的线程抛出org.apache.kafka.common.errors.WakeupException异常。这可以用于在另一个线程中停止当前的消费者。

public class KafkaConsumerRunner implements Runnable {
    private final AtomicBoolean closed = new AtomicBoolean(false);
    private final KafkaConsumer consumer;

    public void run() {
        try {
            consumer.subscribe(Arrays.asList("topic"));
            while (!closed.get()) {
                ConsumerRecords records = consumer.poll(10000);
                // Handle new records
            }
        } catch (WakeupException e) {
            // Ignore exception if closing
            if (!closed.get()) throw e;
        } finally {
            consumer.close();
        }
    }

    // Shutdown hook which can be called from a separate thread
    public void shutdown() {
        closed.set(true);
        consumer.wakeup();
    }
}

在另一个线程中，可以通过closed标识来关闭或者启动消费者。