Kafka(三)：kafka消费者

1. 消费方式

1. pull(拉)模式
   consumer采用从broker中主动拉去数据
   kafka采用这种方式
   不足之处：如果kafka没有数据，消费者可能会陷入循环之中，一直返回空数据
2. push(推)模式
   kafka没有采用这种方式，因为由broker决定消息发送速率，很难适应所有消费者的消费速率

2. 消费者总体工作流程

2.1 消费者组

1. 由多个consumer组成。
2. 形成一个消费者组的条件：是所有消费者的groupid相同

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

2.2 消费者组初始化流程

2.3 消费者组详细消费流程

3 消费者重要参数

参数	描述
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	consumer两次poll的最大时间间隔，默认是 5 分钟。超过该值，该消费者被移除，消费者组执行再平衡。
fetch.min.bytes	默认 1 个字节。消费者获取服务器端一批消息最小的字节数。
fetch.max.wait.ms	默认 500ms。如果没有从服务器端获取到一批数据的最小字节数。该时间到，仍然会返回数据
fetch.max.bytes
max.poll.records	一次 poll 拉取数据返回消息的最大条数，默认是 500 条。

4. 分区的分配以及再平衡

1. 一个consumer group中有多个consumer组成，一个topic有多个partition组成，那么到底由哪个consumer来消费哪个partition的数据？
2. Kafka由四种主流的分区分配策略：Range、RoundRobin、Sticky、CooperativeSticky。可以通过配置参数partition.assignment.strategy来修改分区的分配策略，默认策略是Range + CooperativeSticky。Kafka可以同时使用多个分区分配策略

4.1 Range以及再平衡

4.2 RoundRobin以及再平衡

4.3 Sticky以及再平衡

网络查阅别的资料(todo)

5. offset位移

5.1 offset的默认维护位置

1. 0.9版本之前，consumer默认将offset保存在zookeeper中
2. 从0.9版本开始，consumer默认将offset保存在kafka一个内置的topic中，该topic为_consumer_offsets；
   _consumer_offsets 主题里面采用 key 和 value 的方式存储数据。key 是 group.id+topic+分区号，value 就是当前 offset 的值。每隔一段时间，kafka 内部会对这个 topic 进行compact，也就是每个 group.id+topic+分区号就保留最新数据

5.2 自动提交offset

自动提交offset的相关参数：

• enable.auto.commit：是否开启自动提交offset功能，默认是true。消费者会自动周期性地向服务器提交偏移量
• auto.commit.interval.ms：若设置了enable.auto.commit 的值为 true， 则该值定义了消费者偏移量向 Kafka 提交的频率，默认 5s。

5.3 手动提交offset

1. 虽然自动提交offset十分简单便利，但由于其是基于时间提交的，开发人员难以把握offset提交的时机。因此Kafka还提供了手动提交offset的API。
2. 手动提交offset的方法有两种：分别是commitSync（同步提交）和commitAsync（异步提交）。两者的相同点是，都会将本次提交的一批数据最高的偏移量提交；不同点是，同步提交阻塞当前线程，一直到提交成功，并且会自动失败重试（由不可控因素导致，也会出现提交失败）；而异步提交则没有失败重试机制，故有可能提交失败。

• commitSync（同步提交）：必须等待offset提交完毕，再去消费下一批数据。
• commitAsync（异步提交） ：发送完提交offset请求后，就开始消费下一批数据了。

5.4 指定offset消费

auto.offset.reset = earliest | latest | none 默认是 latest。
当Kafka中没有初始偏移量（消费者组第一次消费）或服务器上不再存在当前偏移量时（例如该数据已被删除），该怎么办？
（1）earliest：自动将偏移量重置为最早的偏移量，–from-beginning。
（2）latest（默认值）：自动将偏移量重置为最新偏移量。
（3）none：如果未找到消费者组的先前偏移量，则向消费者抛出异常。
（4）任意指定 offset 位移开始消费

5.5 指定时间消费

在生产环境中，会遇到最近消费的几个小时数据异常，想重新按照时间消费。

6. 漏消费和重复消费

1. 重复消费：已经消费了数据，但是 offset 没提交。
2. 漏消费：先提交offset后消费，有可能会造成数据的漏消费。
   
   那么如何既能做到不漏消费也不重复消费呢？需要借助消费者事务

7. 消费者事务

如果想完成Consumer端的精准一次性消费，那么需要Kafka消费端将消费过程和提交offset
过程做原子绑定。此时我们需要将Kafka的offset保存到支持事务的自定义介质（比如MySQL）

8. 数据积压问题

1. 如果是Kafka消费能力不足，则可以考虑增 加Topic的分区数，并且同时提升消费组的消费者数量，消费者数 = 分区数。（两者缺一不可）
2. 如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间 < 生产速度），使处理的数据小于生产的数据，也会造成数据积压