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中的数据在消费过程中，有漏消费和重复消费的情况，怎么办？
Kafka消息丢失和重复消费是常见的问题，可以通过以下方法来处理：
-
使用消息确认机制：在生产者发送消息时，可以设置消息确认机制，确保消息成功发送到Kafka集群。在消费者消费消息时，可以设置消息消费确认机制，确保消息成功消费。
-
使用消息偏移量来保证消费顺序：消费者可以在消费消息后保存消息的偏移量，以便在发生重复消费或消息丢失时，可以根据偏移量重新消费消息。
-
设置消息延迟时间：可以在消费者消费消息时设置消息的延迟时间，以防止消息重复消费。
-
使用幂等性保证：在生产者发送消息时，可以设置消息幂等性，确保同一消息不会被重复发送到Kafka集群。
-
使用消息日志和监控系统：可以通过监控系统监控消息的发送和消费情况，及时发现消息丢失或重复消费的问题，并进行处理。
总的来说，通过合理设置消息确认机制、消息偏移量、消息延迟时间、消息幂等性以及消息日志和监控系统，可以有效处理Kafka消息丢失和重复消费的问题。
11.Kafka中的数据在消费过程中，有漏消费和重复消费的情况，怎么办？
consumer是底层采用的是一个阻塞队列，只要一有producer生产数据，那consumer就会将数据消费。当然这里会产生一个很严重的问题，如果你重启一消费者程序，那你连一条数据都抓不到，但是log文件中明明可以看到所有数据都好好的存在。换句话说，一旦你消费过这些数据，那你就无法再次用同一个groupid消费同一组数据了。
原因：消费者消费了数据并不从队列中移除，只是记录了offset偏移量。同一个consumergroup的所有consumer合起来消费一个topic，并且他们每次消费的时候都会保存一个offset参数在zookeeper的root上。如果此时某个consumer挂了或者新增一个consumer进程，将会触发kafka的负载均衡，暂时性的重启所有consumer，重新分配哪个consumer去消费哪个partition，然后再继续通过保存在zookeeper上的offset参数继续读取数据。注意:offset保存的是consumer 组消费的消息偏移。
要消费同一组数据，你可以
采用不同的group。
通过一些配置，就可以将线上产生的数据同步到镜像中去，然后再由特定的集群区处理大批量的数据。
