ConsumerConfig.scala 储存Consumer的配置
按照我的理解，0.10的Kafka没有专门的SimpleConsumer，仍然是沿用0.8版本的。
消费的规则如下：
一个partition只能被同一个ConsumersGroup的一个线程所消费.
线程数小于partition数，某些线程会消费多个partition.
线程数等于partition数，一个线程正好消费一个线程.
当添加消费者线程时，会触发rebalance，partition的分配发送变化.
同一个partition的offset保证消费有序，不同的partition消费不保证顺序.
Consumers编程的用法：
private final KafkaConsumer<Long, String> consumer; // 与Kafka进行通信的consumer... consumer = new KafkaConsumer<Long, String>(props); consumer.subscribe(Collections.singletonList(this.topic)); ConsumerRecords<Long, String> records = consumer.poll(512); ...
consumer，是一个纯粹的单线程程序，后面所讲的所有机制(包括coordinator，rebalance, heartbeat等)，都是在这个单线程的poll函数里面完成的。也因此，在consumer的代码内部，没有锁的出现。
从KafkaConsumer的构造函数可以看出，KafkaConsumer有以下几个核心部件：
Metadata: 存储Topic/Partion与broker的映射关系
NetworkClient:网络层 A network client for asynchronous request/response network i/o.
ConsumerNetworkClient: Higher level consumer access to the network layer //对NetworkClient的封装，非线程安全
ConsumerCoordinator:只是client端的类，只是和服务端的GroupCoordinator通信的介质。（broker端的Coordinator 负责reblance、Offset提交、心跳）
SubscriptionState: consumer的Topic、Partition的offset状态维护
Fetcher: manage the fetching process with the brokers. //获取消息
后面会分组件讲解Consumers的工作流程
在consumer启动时或者coordinator节点故障转移时，consumer发送ConsumerMetadataRequest给任意一个brokers。在ConsumerMetadataResponse中，它接收对应的Consumer Group所属的Coordinator的位置信息。
Consumer连接Coordinator节点，并发送HeartbeatRequest。如果返回的HeartbeatResponse中返回IllegalGeneration错误码，说明协调节点已经在初始化平衡。消费者就会停止抓取数据，提交offsets，发送JoinGroupRequest给协调节点。在JoinGroupResponse，它接收消费者应该拥有的topic-partitions列表以及当前Consumer Group的新的generation编号。这个时候Consumer Group管理已经完成，Consumer就可以开始fetch数据，并为它拥有的partitions提交offsets。
如果HeartbeatResponse没有错误返回，Consumer会从它上次拥有的partitions列表继续抓取数据，这个过程是不会被中断的。
见Producer里面的分析。
补充一下，KafkaConsumer、KafkaProducer都是在构造函数中获取metadata信息，通过调用metadata.update方法来获取信息。
在0.9以前的client api中，consumer是要依赖Zookeeper的。因为同一个consumer group中的所有consumer需要进行协同，新航道雅思培训这与后面要讲的rebalance有关。(ConsumerConnector、KafkaStream、ConsumerIterator) -- package kafka.consumer
0.9之后新的consumer不依赖与Zookeeper，一个consumerGroup内的consumer由Coordinator管理.(KafkaConsumer) -- package org.apache.kafka.clients.consumer
为什么？后面讲
提问：为什么在一个group内部，1个parition只能被1个consumer拥有？
给定一个topic，有4个partition: p0, p1, p2, p3， 一个group有3个consumer: c0, c1, c2。
那么，如果按RangeAssignor策略，分配结果是：
c0: p0, c1: p1, c2: p2, p3
如果按RoundRobinAssignor策略：
c0: p1, p3, c1: p1, c2: p2
partition.assignment.strategy=RangeAssignor,默认值
(到底是哪种分配状态呢)
那这整个分配过程是如何进行的呢？见下图所示：
1. 步骤1：对于每1个consumer group，Kafka集群为其从broker集群中选择一个broker作为其coordinator。因此，第1步就是找到这个coordinator。（1个consumer group对应一个coordinattor）
GroupCoordinatorRequest: GCR，由ConsumerNetworkClient发送请求去寻找coordinator。
2. 步骤2：找到coordinator之后，发送JoinGroup请求
consumer在这里会被划分leader、follower（无责任的说：选择第一个consumer）
leader作用：perform the leader synchronization and send back the assignment for the group（负责发送partition分配的结果）
follower作用：send follower's sync group with an empty assignment
3. 步骤3：JoinGroup返回之后，发送SyncGroup，得到自己所分配到的partition
SyncGroupRequest
consumer leader发送 SyncGroupRequest给Coordinator，Coordinator回给它null
follower发送 null的 SyncGroupRequest 给Coordinator，Coordinator回给它partition分配的结果。
注意，在上面3步中，有一个关键点：
partition的分配策略和分配结果其实是由client决定的，而不是由coordinator决定的。什么意思呢？在第2步，所有consumer都往coordinator发送JoinGroup消息之后，coordinator会指定其中一个consumer作为leader，其他consumer作为follower。
然后由这个leader进行partition分配。
然后在第3步，leader通过SyncGroup消息，把分配结果发给coordinator，其他consumer也发送SyncGroup消息，获得这个分配结果。
接下来就到Fetcher拉取数据了
四个步骤
步骤0:获取consumer的offset
步骤1:生成FetchRequest，并放入发送队列
步骤2:网络poll
步骤3:获取结果
当consumer初次启动的时候，面临的一个首要问题就是：从offset为多少的位置开始消费。
poll之前，给集群发送请求，让集群告知客户端，当前该TopicPartition的offset是多少。通过SubscriptionState来实现, 通过ConsumerCoordinator
if (!subscriptions.hasAllFetchPositions()) updateFetchPositions(this.subscriptions.missingFetchPositions());
核心是：向Coordinator发了一个OffsetFetchRequest，并且是同步调用，直到获取到初始的offset，再开始接下来的poll.（也就是说Offset的信息如果存在Kafka里，是存在GroupCoordinator里面）
consumer的每个TopicPartition都有了初始的offset，接下来就可以进行不断循环取消息了，这也就是Fetch的过程：
fetcher.initFetches(cluster)核心就是生成FetchRequest: 假设一个consumer订阅了3个topic: t0, t1, t2，为其分配的partition分别是： t0: p0; t1: p1, p2; t2: p2
即总共4个TopicPartition，即t0p0, t0p1, t1p1, t2p2。这4个TopicPartition可能分布在2台机器n0, n1上面： n0: t0p0, t1p1 n1: t0p1, t2p2
则会分别针对每台机器生成一个FetchRequest，即Map<Node, FetchRequest>。所以会有一个方法把所有属于同一个Node的TopicPartition放在一起，生成一个FetchRequest。
调用ConsumerNetworkClient.poll发送网络请求。向服务器发 送响应请求和获取服务器的响应。（默认值：executeDelayedTasks=true）
fetcher.fetchedRecords()获取Broker返回的Response，里面包含了List<ConsumerRecord> records
是否自动消费确认：由参数auto.xxx.commit=true控制
手动消费：用于自定义Consumers的消费控制
下面从自动消费确认来分析，Offset自动确认是由ConsumerCoordinator的AutoCommitTask来实现的。
其调用在ConsumerNetworkClient的 DelayedTaskQueue delayedTasks里面，然后被周期性的调用。 周期性的发送确认消息，类似HeartBeat，其实现机制也就是前面所讲的DelayedQueue + DelayedTask.
poll函数中的注释：
// execute delayed tasks (e.g. autocommits and heartbeats) prior to fetching records
可以这样理解：第二次poll调用的时候，提交上一次poll的offset和心跳发送。
先提交offset，再去拉取record。那么这次Offset其实是上一次poll的Record的offset。
因此，当你把按照下面的逻辑写程序的时候，可能会导致Consumer与Coordinator的心跳超时。
while(true) {
consumer.poll();do process message // 假如这个耗时过长，那么这个consumer就无法发送心跳给coordinator，导致它错误认为这个consumer失去联系了，引起不必要的rebalance。槽糕的情况下，会丢重复消费数据。}因此，有必要把offset的提交单独拿出来做一个线程。
到这里，就把整个Consumer的流程走完了。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
