标签:back 消息系统 sep called 禁用 重要 停止 new 场景
[TOC]
KafkaConsumer是从kafka集群消费消息的客户端。这是kafka的高级消费者,而SimpleConsumer是kafka的低级消费者。何为高级?何为低级?
我们所谓的高级,就是可以自动处理kafka集群的失败信息,也可以适应kafka集群中消息的分区迁移。这个客户端也可以与服务端进行交互,使用消费者分组负载平衡消费,下面我们具体会讲解。
消费者与对应的broker保持TCP连接,来获取数据。使用完成后关闭消费者连接失败,会泄露连接。这个消费者不是线程安全的。
Kafka在分区中为每条记录维护了一个数字形式的偏移量。这个偏移量是数据在分区中的唯一值,也可以表示为消费者在分区中的偏移量。例如,一个消费者的偏移量为5,表示偏移量为0到4的消息已经被消费过。关于消费者使用的偏移量,有两个比较重要的概念。
消费者的偏移量表示消费者下一个需要消费的消息的偏移量。这个值会比当前消费者在那个分区刚刚消费的消息偏移量大一。这个值在下面情况下会自动增长:消费者调用了poll(long)并且获取到了消息。
这个committed position表示最新的被安全保存的偏移量。如果当前过程中失败然后重启了,这个是重启后消费的偏移量起点。消费者有三种方式来提交偏移量:
Kafka使用消费分组的概念,允许一个处理池来将消费和处理过程分开。这些处理可以在同一台机器上运行,也可以分布在多台机器上,来提供扩展性和容错。
每个Kafka消费者都可以配置自己所属的消费分组,并且可以通过接口subscribe(Collection, ConsumerRebalanceListener)动态设置订阅的主题。Kafka会把每条消息传递到分组中的某个运行过程。这是通过平衡消费分组中的每个消费者对应的分区来实现的,最终实现的是每个分组正好被分配到分组的某个消费者。所以如果一个主题有4个分区,一个消费分组有两个消费者process,每个process会消费两个分区。
消费分组中的成员是动态的:如果某个process挂了,分配给他的分区会被分到组中其他的process。类似的,如果一个新的消费者加入了分组,分区会迁移到新的分组上。这被称为分组平衡。需要注意的是,当订阅的主题中新的分区出现的时候,相同的情况也会出现:分组不断地检测新的分区,平衡分组,最终每个分区都被分配到某个组成员上。
概念上,你可以把消费分组想象成一个单独的逻辑上的消费者,恰巧有多个消费进程。作为一个多订阅的系统,kafka天然支持某个主题有多个消费分组,而数据不会重复。
这些功能对于一个消息系统来说很普通。和传统的消息队列不同,你可以同时有很多的分组。在传统消息系统中,每个消费者都会有自己的消费分组,所以每个消费者会订阅主题下的所有记录,也就是会收到所有的消息。
而且,当分组重新分配自动出现时,会通过ConsumerRebalanceListener通知消费者,然后消费者自身处理一些应用级的逻辑,比如状态清除,手动提交offset等等。
对消费者来说,还可以手动分配分区,使用的方法是assign(类似于SimpleConsumer)。在这种情况下,动态分区调整和消费分组协调功能会被禁用。
订阅一批主题之后,消费者在调用poll的时候,会自动加入分组。poll是用于确保消费者的存活。只要消费者不停地调用poll,那么他就会一直存在于分组中,并且不断地收到对应分区推送给他的消息。另外,poll方法也会定时发送心跳给服务端,当你停止调用poll时,心跳也会停止。如果server超过session.timeout时间没有收到心跳,消费者会被踢出分组,分区也会重新分配。这是为了防止消费者挂掉之后,还占用分区的情况发生(这种情况下分组中的其他消费者无法消费到消息)。为了继续存在于分组中,消费者必须调用poll方法证明还活着。
这个设计的目的还在于,一个poll循环中的消息处理过程的时间必须是有界的,那样心跳才能在session.timeout之前发出去。消费者提供两个配置来控制这种行为:
当前消费客户端提供了多种方法来消费,下面是几个例子。
这个方法说明了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<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", record.offset(), record.key(), record.value());
}
配置enable.auto.commit表示是自动提交offset,并且提交的频率为auto.commit.interval.ms。服务器可以通过bootstrap.servers来配置,可以不用配置全部的服务器,因为会自动发现集群中所有的服务器。当然不建议只配置一个,因为如果这个挂掉了,就找不到其他的机器了。
反序列化配置表示如何把二进制消息转换为消息对象。例如,使用string反序列化,表示消息的key和value都是字符串。
与自动提交不同,我们可以通过配置来控制消息什么时候消费完成,并提交偏移量。在一条消息需要多个任务处理,所有任务完成后才能提交偏移量的场景下,需要手动提交。在下面的例子中,我们会一次消费一批数据,然后把他们放到内存中,当消息达到一定的数量时,我们会把他们插入数据库中。如果这种情况下,我们配置为自动提交,那么就会出现消息被消费,但是实际上并没有插入到数据库的情况。为了避免这种情况,我们必须在消息插入数据库之后,手动提交偏移量。这也会出现另一种情况,就是消息插入数据库成功,但是在提交偏移量的过程中失败。这种情况下,其他的消费者会继续读取偏移量,然后重新执行批量插入数据库的操作。这么使用的话,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<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("foo", "bar"));
final int minBatchSize = 200;
List<ConsumerRecord<String, String>> buffer = new ArrayList<>();
while (true) {
ConsumerRecords<String, String> records = consumer.poll(100);
for (ConsumerRecord<String, String> record : records) {
buffer.add(record);
}
if (buffer.size() >= minBatchSize) {
insertIntoDb(buffer);
consumer.commitSync();
buffer.clear();
}
}
上面的例子使用的是同步提交commitSync()方法。在某些情况下,你可能需要对消息消费有更加精确的控制,下面的例子中,我们按照分区提交偏移量。
try {
while(running) {
ConsumerRecords<String, String> records = consumer.poll(Long.MAX_VALUE);
for (TopicPartition partition : records.partitions()) {
List<ConsumerRecord<String, String>> partitionRecords = records.records(partition);
for (ConsumerRecord<String, String> 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)这个方法中的内容,应该是当前消息偏移量加上一。
前面的例子中,消费者订阅主题,然后服务端动态分配了分区给消费者。在某些情况下,我们需要精确控制消费的分区,例如:
消费者维护了与分区相关的本地状态(例如本地磁盘键值存储),那么他应该只读取特定分区的数据。如果消费者本身是高可用的,在挂掉之后会自动重启(可能正在使用集群管理框架,比如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));
这种情况下,不会使用到分组协调器,所以消费者挂掉的情况,也不会重新分配分区。所以每个消费者都是独立的,为了避免偏移量提交冲突,每个消费者的分组信息应该是唯一的。
消费者应用可能不想把offset存到kafka中,所以kafka也提供了把offset存储到其他地方的接口。这种情况下,就能自己实现消息只消费一次的场景,比至少一次强很多。那么我们如何使用呢?
这种场景在手动分配分区的情况下很简单。如果分区分配是自动的,我们需要特殊处理分区分配改变的情况。这个可以通过提供ConsumerRebalanceListener实例,在调用subscribe(Collection, ConsumerRebalanceListener)和subscribe(Pattern, ConsumerRebalanceListener)时实现。
大多数情况下,消费者会简单的从头到尾消费消息,定时提交位点(自动或手动)。然后,kafka允许消费者手动控制位点,可以设置位点的位置。这意味着消费者可以消费已经消费过的消息,也可以跳过最新的消息。
kafka可以通过seek(TopicPartition, long)方法来指定消费起点,寻找早的或者新的位点,也可以通过seekToBeginning(Collection)和seekToEnd(Collection)来指定。
如果一个消费者被分配到了多个分区,他会尝试同时消费所有的分区,所有的分区的权重一样。然而,在某些情况下,消费者需要首先全速消费某些特定的分区,当这个分区没有消息后再消费其他的分区。
例如,流式处理。消费者同时从两个主题消费,然后把消息合并。当某个主题落后于另一个主题很多时,消费者应该停止消费快的那个主题,等慢的那个赶上来。再比如,有个主题有很多历史数据需要被消费,这种情况下,消费者应该优先消费那些有最新消息的主题。
kafka支持动态控制消费流量,通过pause(Collection)和resume(Collection)方法。
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标识来关闭或者启动消费者。
标签:back 消息系统 sep called 禁用 重要 停止 new 场景
原文地址:http://www.cnblogs.com/f-zhao/p/7843883.html