kafka消费方式
pull(拉)模式：
consumer采用从broker中主动拉取数据。
Kafka采用这种方式。
push(推)模式：
Kafka没有采用这种方式，因为由broker决定消息发送速率，很难适应所有消费者的速率。例如推送速度是50m/s，consumer1，consumer2就来不及处理消息
pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一致返回空数据
消费者总体工作流程
1）每个消费者的offset由消费者提交到系统主题保存
2）每个分区的数据只能由消费者组中一个消费者消费
3）一个消费者可以消费多个分区数据
消费者原理
Consumer Group(CG):消费者组，由多个consumer组成，形成一个消费组的条件，是所有消费组groupid相同。
消费者组内每个消费者负责消费不同的分区数据，一个分区只能由由一个组内消费者消费。
消费者组之间互不影响，所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
1）如果消费组中添加更多的消费者，超过主题分区数量，则有一部分消费者就会闲置，不会接收任何消息
2）消费者组之间互不影响，所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者
消费者初始化流程
coordinator:辅组实现消费者组的初始化和分区的分配
coordinator节点选择=groupid的hashcode值%50（_consumer_offsets的分区数组）
例如：groupid的hashcode值=1，1%50=1,那么_consumer_offsets主题的1号分区，在哪个broker上，就选择这个节点的coordinator作为这个消费者组的老大，消费者组下的所有消费者提交offset的时候就往这个分区去提交offset
1)每个consumer都发送joinGroup请求
2)选出一个consumer作为leader
3)要把消费的topic情况发送给leader消费者
4)leader会负责指定消费方案
5)把消费方案分给coordinator
6)coordinator就把消费方案下发给各个consumer
7)每个消费者都会和coordinator保存心跳（默认3s），一旦超时（session.timeout.ms=45s），该消费者就会被一处，并触发再平衡，或者消费者处理消息的时间过长（max.poll.interval.ms5分钟），也会触发再平衡
Fetch.min.bytes每批次最小抓取大小，默认1字节
fetch.max.wait.ms一批数据最小值未达到的超时间，默认500ms
fetch.max.bytes每批次最大抓取大小，默认50m
max.poll.records一次拉取数据返回消息的最大条数，默认500条
