消费者组: Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。组内必然可以有多个消费者或消费者实例（Consumer Instance），它们共享一个公共的 ID，这个 ID 被称为 Group ID
特性
- Consumer Group 下可以有一个或多个 Consumer 实例。这里的实例可以是一个单独的进程，也可以是同一进程下的线程。在实际场景中，使用进程更为常见一些。
- Group ID 是一个字符串，在一个 Kafka 集群中，它标识唯一的一个 Consumer Group。
- Consumer Group 下所有实例订阅的主题的单个分区，只能分配给组内的某个 Consumer 实例消费。这个分区当然也可以被其他的 Group 消费。
一个 Group 下该有多少个 Consumer 实例呢？理想情况下，Consumer 实例的数量应该等于该 Group 订阅主题的分区总数。
Offset 就是一个数值而已，其实对于 Consumer Group 而言，它是一组 KV 对，Key 是分区，V 对应 Consumer 消费该分区的最新位移。
Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 Consumer 如何达成一致，来分配订阅 Topic 的每个分区。比如某个 Group 下有 20 个 Consumer 实例，它订阅了一个具有 100 个分区的 Topic。正常情况下，Kafka 平均会为每个 Consumer 分配 5 个分区。这个分配的过程就叫 Rebalance。
消费者组的重平衡：
（1）重平衡：本质上是一种协议，规定了消费者组下的每个消费者如何达成一致，来分配订阅topic下的每个分区。
（2）触发条件：
a，组成员数发生变更
b，订阅主题数发生变更
c，定阅主题分区数发生变更
（3）影响：
Rebalance 的设计是要求所有consumer实例共同参与，全部重新分配所有用分区。并且Rebalance的过程比较缓慢，这个过程消息消费会中止。
重平衡是指consumer group级别的，不是主题级别的。Rebalance时所有consumer都不能消费，等结束后才能继续消费
Kafka的老版本消费者组的位移保存在Zookeeper中，好处是Kafka减少了Kafka Broker端状态保存开销。但ZK是一个分布式的协调框架，不适合进行频繁的写更新，这种大吞吐量的写操作极大的拖慢了Zookeeper集群的性能。Kafka的新版本采用了将位移保存在Kafka内部主题的方法。
社区2.3引入了static consumer，这样consumer程序正常的停机重启不会rebalance
消费者组中的一台服务器出问题就rebalance了，
重平衡是指consumer group级别的
从某个时间点之后投入kafka的数据开始消费 ？
- kafka提供offsetsForTimes方法
Consumer Group ：Kafka提供的可扩展且具有容错性的消息者机制。
1，重要特征：
- A：组内可以有多个消费者实例（Consumer Instance）。
- B：消费者组的唯一标识被称为Group ID，组内的消费者共享这个公共的ID。
- C：消费者组订阅主题，主题的每个分区只能被组内的一个消费者消费
- D：消费者组机制，同时实现了消息队列模型和发布/订阅模型。
2，重要问题：
- A：消费组中的实例与分区的关系：消费者组中的实例个数，最好与订阅主题的分区数相同，否则多出的实例只会被闲置。一个分区只能被一个消费者实例订阅。
- B：消费者组的位移管理方式：
- （1）对于Consumer Group而言，位移是一组KV对，Key是分区，V对应Consumer消费该分区的最新位移
- （2）Kafka的老版本消费者组的位移保存在Zookeeper中，好处是Kafka减少了Kafka Broker端状态保存开销。但ZK是一个分布式的协调框架，不适合进行频繁的写更新，这种大吞吐量的写操作极大的拖慢了Zookeeper集群的性能。
- （3）Kafka的新版本采用了将位移保存在Kafka内部主题的方法。
- C：消费者组的重平衡：
- （1）重平衡：本质上是一种协议，规定了消费者组下的每个消费者如何达成一致，来分配订阅topic下的每个分区。
- （2）触发条件：a，组成员数发生变更 b，订阅主题数发生变更 c，定阅主题分区数发生变更
- （3）影响：Rebalance 的设计是要求所有consumer实例共同参与，全部重新分配所有用分区。并且Rebalance的过程比较缓慢，这个过程消息消费会中止。
我正在参与2023腾讯技术创作特训营第三期有奖征文，组队打卡瓜分大奖！
