Kafka - 消费者

目录

一、Kafka消费方式

二、消费者工作流程

1.消费者总体工作流程

2.消费者组原理

3.消费者组初始化流程

4.消费者重要参数

---

一、Kafka消费方式

一般而言数据的消费方式分为拉（pull）和推（push）两种：

pull（拉）：consumer采用从broker中主动拉取数据。 Kafka采用这种方式。

push（推）：Kafka没有采用这种方式，因为由 broker 决定消息发送速率，很难适应所有消费者的消费速率。例如推送的速度是50m/s，而 Consumer1 、 Consumer2 的速度只有10-20m/s，就会来不及处理消息。

pull模式不足之处是，如 果Kafka没有数 据，消费者可能会陷入循环中，一直返回空数据。

---

二、消费者工作流程

1.消费者总体工作流程

一个消费者可以消费多条数据。每个消费者之间互不干预。

在消费者组中，一个消费者消费一个分区的数据。比如其中的A消费者，消费了 broker0 中的数据，那么剩下的B，C就无法再去消费 broker0 中的数据了。否则会造成数据重复问题。

还有一个问题：当消费者在消费broker0中的数据时，他消费到了3然后他自己挂了。当然重新上线时要如何判断自己之前消费到哪了呢？这里就要提到offset了，他会被维护在kafka的系统主题 __consumer_offsets 中。但是在0.9版本之前，是被存储在Zookeeper中的。因为如果所有的消费者都把offset存储在Zookeeper中，那么在工作时都需要到Zookeeper中做大量的交互，这样很浪费系统资源。

---

2.消费者组原理

Consumer Group（CG）：消费者组，由多个consumer组成。形成一个消费者组的条件，是所有消费者的groupid相同。

• 消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费。
• 消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

如果向消费组中添加更多的消费者，超过主题分区数量，则有一部分消费者就会闲置，不会接收任何消息。

---

3.消费者组初始化流程

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分钟），也会触发再平衡

---

4.消费者重要参数

参数名称	描述
bootstrap.servers	向 Kafka 集群建立初始连接用到的 host/port 列表
key.deserializer 和 value.deserializer	指定接收消息的 key 和 value 的反序列化类型。一定要写全类名
group.id	标记消费者所属的消费者组
enable.auto.commit	默认值为 true，消费者会自动周期性地向服务器提交偏移量
auto.commit.interval.ms	如果设置了 enable.auto.commit 的值为 true， 则该值定义了消费者偏移量向 Kafka 提交的频率，默认 5s
auto.offset.reset	当 Kafka 中没有初始偏移量或当前偏移量在服务器中不存在（如，数据被删除了），该如何处理？ earliest：自动重置偏移量到最早的偏移量。 latest：默认，自动重置偏移量为最新的偏移量。 none：如果消费组原来的（previous）偏移量不存在，则向消费者抛异常。 anything：向消费者抛异常
offsets.topic.num.partitions	__consumer_offsets 的分区数，默认是 50 个分区
heartbeat.interval.ms	Kafka 消费者和 coordinator 之间的心跳时间，默认 3s。该条目的值必须小于 session.timeout.ms ，也不应该高于session.timeout.ms 的 1/3
session.timeout.ms	Kafka 消费者和 coordinator 之间连接超时时间，默认 45s。超过该值，该消费者被移除，消费者组执行再平衡
max.poll.interval.ms	消费者处理消息的最大时长，默认是 5 分钟。超过该值，该消费者被移除，消费者组执行再平衡
fetch.min.bytes	默认 1 个字节。消费者获取服务器端一批消息最小的字节 数
fetch.max.wait.ms	默认 500ms。如果没有从服务器端获取到一批数据的最小字节数。该时间到，仍然会返回数据
fetch.max.bytes	默认 Default: 52428800（50 m）。消费者获取服务器端一批消息最大的字节数。如果服务器端一批次的数据大于该值（50m）仍然可以拉取回来这批数据，因此，这不是一个绝对最大值。一批次的大小受 message.max.bytes （broker config）or max.message.bytes （topic config）影响
max.poll.records	一次 poll 拉取数据返回消息的最大条数，默认是 500 条

---