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条