5、消费者组和分区数之间的关系是怎样的？

消费者组数小于等于分区数，消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费。

6、kafka如何知道哪个消费者消费哪个分区？

生产者把数据发送给各个分区，每个broker节点都有一个coordinator(协调器)，消费者组对分区进行消费，到底哪个消费者消费哪个分区呢？首先groupId对50取模，看最后的结果是哪个分区节点，假如是1分区，那么1分区的协调器就是本次消费者组的老大，消费者纷纷向该协调器进行注册，协调器从中随机选择一个消费者作为本次消费的Leader，然后把本次消费的具体情况发送给Leader，让其制定一个消费计划（就是哪个消费者消费哪个分区），然后Leader发送给协调器，协调器再进行群发，将计划公布，各个消费者按照这个计划进行消费。

7、kafka消费者的消费分区策略有哪些，默认是个？

Kafka有四种主流的分区分配策略： Range、RoundRobin（轮询）、Sticky（粘性）、CooperativeSticky（配合的粘性）。

1.Range分区策略原理：

Kafka 默认的分区分配策略就是 Range + CooperativeSticky，所以不需要修改策略。

默认是Range,但是在经过一次升级之后，会自动变为CooperativeSticky。这个是官方给出的解释。默认的分配器是[RangeAssignor, CooperativeStickyAssignor]，默认情况下将使用RangeAssignor，但允许通过一次滚动反弹升级到CooperativeStickyAssignor，该滚动反弹会将RangeAssignor从列表中删除。会出现数据倾斜，当每个topic中的consumer都多被分配一个的时候topic越大数据倾斜就越严重。

2）Range 分区分配再平衡策略

说明：某个消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需

要等待，时间到了 45s 后，判断它真的退出就会把任务分配给其他 broker 执行。

2.RoundRobin轮询分区策略以及再平衡

原理：

2）RoundRobin 分区分配再平衡案例

某个消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需要等待，时间到了 45s 后，判断它真的退出就会把任务分配给其他 broker 执行。

3.Sticky 以及再平衡

粘性分区定义：可以理解为分配的结果带有“粘性的”。即在执行一次新的分配之前， 考虑上一次分配的结果，尽量少的调整分配的变动，可以节省大量的开销。 粘性分区是 Kafka 从 0.11.x 版本开始引入这种分配策略，首先会尽量均衡的放置分区 到消费者上面，在出现同一消费者组内消费者出现问题的时候，会尽量保持原有分配的分区不变化。

Sticky 分区分配再平衡

某个消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需要等待，时间到了 45s 后，判断它真的退出就会把任务分配给其他 broker 执行。

4.CooperativeSticky 的解释【新的kafka中刚添加的策略】

在消费过程中，会根据消费的偏移量情况进行重新再平衡，也就是粘性分区，运行过程中还会根据消费的实际情况重新分配消费者，直到平衡为止。

好处是：负载均衡，不好的地方是：多次平衡浪费性能。

动态平衡，在消费过程中，实施再平衡，而不是定下来，等某个消费者退出再平衡。

8.kafka中的消费者，他们的偏移量存储在哪里？

从0.9版本开始，consumer默认将offset保存在Kafka一个内置的topic中，该topic为__consumer_offsets 【topic 其实就是数据，就是位置 topic -log --segment- 一个个文件】

Kafka0.9版本之前，consumer默认将offset 保存在Zookeeper中。

kafka0.11 版本 高于 kafka 0.9，咱们用的kafka是 3.0版本。

假如公司中想重置kafka。 删除每一个kafka logs 以及 datas，zk中的kafka 文件夹删除掉。

为什么要把消费者的偏移量从zk中挪到 kafka中呢？原因是避免Conusmer频发跟zk进行通信。

__consumer_offsets 主题里面采用 key 和 value 的方式存储数据。key 是group.id+topic+ 分区号，value 就是当前 offset 的值。每隔一段时间，kafka 内部会对这个 topic 进行 compact （压缩），也就是每个 group.id+topic+分区号就只保留最新数据。

9.kafka中数据挤压太多，怎么办？（提高消费者的效率）

10.Kafka中的数据在消费过程中，有漏消费和重复消费的情况，怎么办？

如果想完成Consumer端的精准一次性消费，那么需要Kafka消费端将消费过程和提交offset 过程做原子绑定。

11.Kafka中的数据在消费过程中，有漏消费和重复消费的情况，怎么办？

consumer是底层采用的是一个阻塞队列，只要一有producer生产数据，那consumer就会将数据消费。当然这里会产生一个很严重的问题，如果你重启一消费者程序，那你连一条数据都抓不到，但是log文件中明明可以看到所有数据都好好的存在。换句话说，一旦你消费过这些数据，那你就无法再次用同一个groupid消费同一组数据了。

原因：消费者消费了数据并不从队列中移除，只是记录了offset偏移量。同一个consumergroup的所有consumer合起来消费一个topic，并且他们每次消费的时候都会保存一个offset参数在zookeeper的root上。如果此时某个consumer挂了或者新增一个consumer进程，将会触发kafka的负载均衡，暂时性的重启所有consumer，重新分配哪个consumer去消费哪个partition，然后再继续通过保存在zookeeper上的offset参数继续读取数据。注意:offset保存的是consumer 组消费的消息偏移。

12.kafka中的数据已经消费过的数据，是否可以再次消费？怎么做？

要消费同一组数据，你可以：

采用不同的group。
通过一些配置，就可以将线上产生的数据同步到镜像中去，然后再由特定的集群区处理大批量的数据。