Kafka 0.8 Consumer处理逻辑
0.前言
客户端用法:
kafka.javaapi.consumer.ConsumerConnector consumer = kafka.consumer.Consumer.createJavaConsumerConnector(new ConsumerConfig(properties));
// 决定一个topic启动几个线程去拉取数据,即生成几个KafkaStream;
Map<String, Integer> topicCountMap = new HashMap<String, Integer>();
topicCountMap.put(topic, new Integer(threads));
Map<String, List<KafkaStream<byte[], byte[]>>> topicMessageStreams = consumer.createMessageStreams(topicCountMap);
List<KafkaStream<byte[], byte[]>> streams = topicMessageStreams.get(topic);
// 本质是调用了 ZookeeperConsumerConnector
val consumerConnect = new kafka.javaapi.consumer.ZookeeperConsumerConnector(config)
- 一个Topic启动几个消费者线程,会生成几个KafkaStream。
- 一个KafkaStream对应的是一个Queue(有界的LinkedBlockingQueue),有界的参数控制:
queued.max.message.chunks
。消费者线程数量决定阻塞队列的个数。 - Fetcher线程是对应topic所在的broker的个数。
因此,分析Consumer,主要是分析ZookeeperConsumerConnector
。代码里面,有两个类,它们是什么关系呢?
- kafka.consumer.ZookeeperConsumerConnector:核心类
- kafka.javaapi.consumer.ZookeeperConsumerConnector:对上面那个类的scala数据结构封装,方便Java程序员使用。
0.8.0 和 0.8.2.1
ZookeeperConsumerConnector
的源码不一样,下面以0.8.2.1源码为主来分析,也就是从这个版本开始,可以将Offset存在Kafka的Broker中。(关注实现思想,忽略细节。)
1.ZookeeperConsumerConnector 架构
一个Consumer会创建一个ZookeeperConsumerConnector,代表一个消费者进程.
- fetcher: 消费者获取数据, 使用ConsumerFetcherManager fetcher线程抓取数据
- zkClient: 消费者要和ZK通信, 除了注册自己,还有其他信息也会写到ZK中
- topicThreadIdAndQueues: 消费者会指定自己消费哪些topic,并指定线程数, 所以topicThreadId都对应一个队列
- messageStreamCreated: 消费者会创建消息流, 每个队列都对应一个消息流
- offsetsChannel: offset可以存储在ZK或者kafka中,如果存在kafka里,像其他请求一样,需要和Broker通信。可以理解成OffsetManager的一部分。
- scheduler: 后台调度autoCommit
- 还有其他几个Listener监听器,分别用于topicPartition的更新,负载均衡,消费者重新负载等
简述获取数据的流程
- 初始化上面的几个组件,包括与ZK的连接,创建ConsumerFetcherManager,确保连接上OffsetManager(为该ConsumerGroup建立一个OffsetChannel)。
createMessageStreams
创建消息流,反序列化message- 通过Fetcher线程拉取数据,放入BlockingQueue来给客户端。
- 客户端启动ZKRebalancerListener,ZKRebalancerListener实例会在内部创建一个线程,这个线程定时检查监听的事件有没有执行(消费者发生变化),如果没有变化则wait 1秒钟,当发生了变化就调用
syncedRebalance
方法,去rebalance
消费者。
1.1 消费者线程(consumer thread),队列(LinkedBlockingQueue),拉取线程(fetch thread)三者之间关系
以一段代码来说明,消费的topic 12 partition,分配在3台broker机器上。
ConsumerConnector consumer = kafka.consumer.Consumer.createJavaConsumerConnector(createConsumerConfig());
Map<String, Integer> topicCountMap = new HashMap<String, Integer>();
topicCountMap.put("test-string-topic", new Integer(2)); //value表示consumer thread线程数量
Map<String, List<KafkaStream<byte[], byte[]>>> consumerMap = consumer.createMessageStreams(topicCountMap);
- consumer thread数量与BlockingQueue一一对应。所以上述的代码只有2个BlockQueue。(它们连接的桥梁是KafkaStream)
- fetcher线程数和topic所在多少台broker有关。因此,共有3个fetcher线程与broker建立一个连接。(3个fetch thread线程去拉取消息数据,最终放到2个BlockingQueue中,等待consumer thread来消费。)
下面是分配的情况:
- 消费者线程,缓冲队列,partitions分布列表如下
consumer线程 |Blocking Queue|partitions
---|---|---|---
consumer thread1 |blockingQueue1|0,1,2,3,4,5
consumer thread2 |blockingQueue2|6,7,8,9,10,11
- fetch thread与partitions分布列表如下
fetch线程 |partitions
---|---|---
fetch thread1 | 0,3,6,9
fetch thread2 | 1,4,7,10
fetch thread3 | 2,5,8,11
用户的consumer thread就使用2个BlockingQueue的数据进行处理;所以一般会使用2个consumer thread去消费这2个BlockingQueue数据。
1.2 rebalance的流程
代码上调用:syncedRebalance方法在内部会调用def rebalance(cluster: Cluster): Boolean方法,去执行操作。
- // 关闭所有的数据获取者 closeFetchers
- // 解除分区的所有者 releasePartitionOwnership
- // 按规则得到当前消费者拥有的分区信息并保存到topicRegistry中
topicRegistry=getCurrentConsumerPartitionInfo
- // 修改并重启Fetchers updateFetchers
最后,对每个broker创建一个FetcherRunnable线程,并启动它。这个fetcher线程负责从Broker上不断获取数据,对每个partition分别创建FetchRequest,最后把数据插入BlockingQueue的操作。
KafkaStream
对ConsumerIterator
做了进一步的封装,我们调用stream的next
方法就可以取到数据了(内部通过调用ConsumerIterator
的next
方法实现)
1.3 注意
ConsumerIterator
的实现可能会造成数据的重复发送(这要看生产者如何生产数据),FetchedDataChunk
是一个数据集合,它内部会包含很多数据块,一个数据块可能包含多条消息,但同一个数据块中的消息只有一个offset,所以当一个消息块有多条数据,处理完部分数据发生异常时,消费者重新去取数据,就会再次取得这个数据块,然后消费过的数据就会被重新消费。
- 没想到里面,里面是这个样子的,给一个数据块,导致了数据消费的重复。
3.美团遇到的一个问题
问题: Kafka中由Consumer维护消费状态,当Consumer消费消息时,支持2种模式commit消费状态,分别为立即commit和周期commit。前者会导致性能低下,做到消息投递恰好一次,但很少使用,后者性能高,通常用于实际应用,但极端条件下无法保证消息不丢失。
解决方案(这个问题太极端情况,不推荐,长个知识)
- 将本来的结果改成下面的处理流程:等待“执行业务逻辑”成功完成后更新缓存消费状态,就可以保证消息不会丢失。
变成下面的:
posted on 2017-02-04 10:04 BYRHuangQiang 阅读(3945) 评论(0) 编辑 收藏 举报