Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。

Consumer Group特性:

Consumer Group 下可以有一个或多个 Consumer 实例。这里的实例可以是一个单独的进程,也可以是同一进程下的线程。在实际场景中,使用进程更为常见一些。
Group ID 是一个字符串,在一个 Kafka 集群中,它标识唯一的一个 Consumer Group。
Consumer Group 下所有实例订阅的主题的单个分区,只能分配给组内的某个 Consumer 实例消费。这个分区当然也可以被其他的 Group 消费。

Kafka 仅仅使用 Consumer Group 这一种机制,
却同时实现了传统消息引擎系统的两大模型:

如果所有实例都属于同一个 Group,那么它实现的就是消息队列模型;
如果所有实例分别属于不同的 Group,那么它实现的就是发布 / 订阅模型。

理想情况下,Consumer 实例的数量应该等于该 Group 订阅主题的分区总数。

新版本的 Consumer Group 将位移保存在 Broker 端的内部主题中。__consumer_offsets

Rebalance 重平衡
Rebalance 本质上是一种协议,规定了一个 Consumer Group 下的所有 Consumer 如何达成一致,来分配订阅 Topic 的每个分区。
Consumer Group 何时进行 Rebalance 呢?Rebalance 的触发条件有 3 个。

组成员数发生变更。比如有新的 Consumer 实例加入组或者离开组,抑或是有 Consumer 实例崩溃被“踢出”组。
订阅主题数发生变更。Consumer Group 可以使用正则表达式的方式订阅主题,比如 consumer.subscribe(Pattern.compile(“t.*c”)) 就表明该 Group 订阅所有以字母 t 开头、字母 c 结尾的主题。在 Consumer Group 的运行过程中,你新创建了一个满足这样条件的主题,那么该 Group 就会发生 Rebalance。
订阅主题的分区数发生变更。Kafka 当前只能允许增加一个主题的分区数。当分区数增加时,就会触发订阅该主题的所有 Group 开启 Rebalance。

Rebalance 发生时,Group 下所有的 Consumer 实例都会协调在一起共同参与。你可能会问,每个 Consumer 实例怎么知道应该消费订阅主题的哪些分区呢?这就需要分配策略的协助了。
Kafka 默认提供了 3 种分配策略,每种策略都有一定的优势和劣势

在 Rebalance 过程中,所有 Consumer 实例都会停止消费,等待 Rebalance 完成。这是 Rebalance 为人诟病的一个方面。
目前 Rebalance 的设计是所有 Consumer 实例共同参与,全部重新分配所有分区。其实更高效的做法是尽量减少分配方案的变动。

最好的解决方案是避免 Rebalance 的发生。