Kafka消费者组是什么？

ゞ浴缸里的玫瑰 2021-10-15 04:12 424阅读 0赞

## 一、Kafka消费者组是什么？ ##

Consumer Group 是Kafka提供的可扩展且具有容错性的消费者机制。在组内多个消费者实例(Consumer Instance ),它们共享一个公共的ID即 Group ID 。组内的所有消费者协调在一起消费订阅主题（Subscribed Topics）的所有分区(Partition)。当然一个分区只能有同一个消费者组的一个Consumer 实例消费。  
Consumer Group 有三个特性：

1.  Consumer Group 下可以有一个或多个Consumer 实例。 这里的实例可以是一个单独的进程，也可以是同一进程下的线程；
2.  Group ID 是一个字符串， 在Kafka集群中唯一标识，Consumer Group；
3.  Consumer Group  
    下所有实例订阅主体的单个分区，只能分配给组内某个Consumer实例消费。同一个分区消息可能被多个Group 消费。

## 二、Kafka消费者组解决了哪些问题？ ##

传统的消息系统中，有两种消息引擎模型：点对点模型（消息队列）、发布/订阅模型  
传统的两种消息系统各有优势，我们里对比一下：

*  传统的消息队列模型的缺陷在于消息一旦被消费，就会从队列中删除，而且只能被下游的一个Consumer消费。严格的说这不是它的缺陷，  
    这是它的一个特性。但很显然这种模型的伸缩性（Scalability）很差，因为下游的多个Consumer 都要“抢”  
    这个共享消息队列的消息；
 *  发布/订阅模型,允许消息被多个Consumer 消费，但它的问题也是伸缩性不高，因为订阅者都必须订阅所有主体的所有分区。

Kafka 为规避传统消息两种模型的缺点，引入了 Consumer Group 机制：

1.  当 Consumer Group 订阅多个主题后，组内的每个实例不要求一定要订阅主题的所有分区，它只会消费部分分区中的消息；
2.  Consumer Group 之间彼此队里，互不影响，它们可以订阅同一组主题而互不干涉。加上Broker端的消息留存机制，Kafka  
    的Consumer Group 完美的避开了伸缩性差的问题；
3.  kafka 是用Consumer Group  
    机制，实现了，传统两大消息引擎。如果所有实例属于同一个Group，那么它实现的就是消息队列模型；如果所有实例分别属于不同的Group，且订阅了相同的主题，那么它就实现了发布/订阅模型；

## 三、Consumer Group 实例数量多少才合理？ ##

最理想的情况是Consumer实例的数量应该等于该Group订阅主题的分区总数。例如：Consumer Group 订阅了 3个主题，分别是A、B、C，它们的分区数依次是1、2、3，那么通常情况下，为该Group 设置6个Consumer实例是比较理想的情形。

如果设置小于或大于6的实例可以吗？当然可以，如果你有3个实例，那么平均下来每个实例大约消费2个分区（6/3=2）;如果你设置了9个实例，那么很遗憾，有3个实例（9-6=3）将不会被分配任何分区，它们永远处于空闲状态。

## 四、消费位移 ##

消费者在消费的过程中要记录自己消费了多少数据，即消费位置信息，在Kafka中叫：位移（offset）。  
看上去该Offset就是一个数字而已，其实对于Consumer Group 而言，它是一组KV对，Key是分区，V对应Consumer 消费该分区的最新位移。  
老版本的Consumer Group把位移保存在Zookeeper中。将位移保存在Zookeeper外部系统显然好处是减少了Kafka Broker 端的状态保存开销。现在比较流行的提法是将服务器节点做成无状态的， 这样可以自由扩缩容，实现超强的伸缩性。不过在实际使用场景中，发现ZooKeeper 这类元框架并不是适合进行频繁的写更新，而Consumer Group 的位移更新却是一个非常频繁的操作。 这种大吞吐量的写操作极大的拖慢了ZooKeeper 集群的性能，在新版本的Consumer Group 中，Kafka 社区采用了将Consumer Group 位移保存在Broker 端的内部主题中。

## 五、Rebalance ##

Rebalance 本质上是一种协议，规定了一个Consumer Group 下所有Consumer 如何达成一致，来分配订阅Topic的每个分区。比如：某个Group 下有20个Consumer 实例， 它订阅了一个具有100个分区的Topic。正常情况下，Kafka 平均会为每个Consumer 分配5个分区。这个分配的过程叫Rebalance。  
Consumer Group触发 Rebalance有三种情况：

1.  组成员数量发生变化，比如有新的Consumer 实例加入组或离开组，抑或是有Consumer实例崩溃被“踢出”组。
2.  订阅主题数量发生变更。 Consumer Group 可以使用正则表达式订阅主题，比如  
    consumer.subscribe(Pattern.complile(“t.\*c”))就表明该Group订阅所有t开头，字母c结尾的主题。在Consumer  
    Group 运行时，新创建一个满足这样条件的主题，那么会触发订阅该主题所有Group 开始Rebalance。
3.  订阅主题分区数发生变化，Kakfka 一个主题，当分区数增加时，就会触发订阅该主题的所有Group开启Rebalance。

Consumer Group 发生Rebalance 的过程：某个 Consumer Group 下有两个Consumer ，比如A和B，当第三个成员C加入时，Kafka会触发Rebalance，并根据默认的分配策重新分配A、B、C分配分区，如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70]  
**注意：目前Rebalance 的设计是所有Consumer实例共同参与，全部重新分配所有分区，Rebalance过程所有Consumer 实例都会停止消费，等待Rebalance 完成。Rebalance 很慢，一个Group 内有几百个Consumer实例，成功进行一次Rebalance需要好几个小时。 目前社区没有终极解决方案，最好的解决方案是规避Rebalane的发生。**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70]: /images/20211015/618cefb4471b429fae742098a6672091.png