kafka消费者组概念

最新推荐文章于 2024-07-17 17:31:15 发布

qq_18219755

最新推荐文章于 2024-07-17 17:31:15 发布

阅读量1.4k

点赞数 2

分类专栏： kafka

本文链接：https://blog.csdn.net/qq_18219755/article/details/98965946

版权

kafka 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

https://blog.csdn.net/cgs666/article/details/85257819

应用程序使用 KafkaConsumer向 Kafka 订阅主题，并从订阅的主题上接收消息。从 Kafka 读取数据不同于从其他悄息系统读取数据，它涉及一些独特的概念和想法。如果不先理解这些概念，就难以理解如何使用消费者 API。所以我们接下来先解释这些重要的概念，然后再举几个例子，横示如何使用消费者 API 实现不同的应用程序。

消费者和消费者群组

假设我们有一个应用程序需要从-个 Kafka主题读取消息井验证这些消息，然后再把它们保存起来。应用程序需要创建一个消费者对象，订阅主题并开始接收消息，然后验证消息井保存结果。过了一阵子，生产者往主题写入消息的速度超过了应用程序验证数据的速度，这个时候该怎么办?如果只使用单个消费者处理消息，应用程序会远跟不上消息生成的速度。显然，此时很有必要对消费者进行横向伸缩。就像多个生产者可以向相同的主题写入消息一样，我们也可以使用多个消费者从同一个主题读取消息，对消息进行分流。

Kafka 消费者从属于消费者群组。一个群组里的消费者订阅的是同一个主题，每个消费者接收主题一部分分区的消息。

假设主题 T1 有 4 个分区，我们创建了消费者 C1 ，它是群组 G1 里唯一的消费者，我们用它订阅主题 T1。消费者 Cl1将收到主题 T1全部 4个分区的消息，如图 4-1 所示。

在这里插入图片描述

如果在群组 G1 里新增一个消费者 C2，那么每个消费者将分别从两个分区接收消息。我假设消费者 C1接收分区 0 和分区 2 的消息，消费者 C2 接收分区 1 和分区 3 的消息，如图 4-2 所示。

在这里插入图片描述

如果群组 G1 有 4 个消费者，那么每个消费者可以分配到一个分区，如图 4-3 所示。

在这里插入图片描述

如果我们往群组里添加更多的消费者，超过主题的分区数量，那么多出的消费者就会被闲置，不会接收到任何消息。

往群组里增加消费者是横向伸缩消费能力的主要方式。 Kafka 消费者经常会做一些高延迟的操作，比如把数据写到数据库或 HDFS，或者使用数据进行比较耗时的计算。在这些情况下，单个消费者无法跟上数据生成的速度，所以可以增加更多的消费者，让它们分担负载，每个消费者只处理部分分区的消息，这就是横向伸缩的主要手段。我们有必要为主题创建大量的分区，在负载增长时可以加入更多的消费者。不过要性意，不要让消费者的数量超过主题分区的数量，多余的消费者只会被闲置。

除了通过增加消费者来横向伸缩单个应用程序外，还经常出现多个应用程序从同一个主题读取数据的情况。实际上， Kafka 设计的主要目标之一，就是要让 Kafka 主题里的数据能够满足企业各种应用场景的需求。在这些场景里，每个应用程序可以获取到所有的消息，而不只是其中的一部分。只要保证每个应用程序有自己的消费者群组，就可以让它们获取到主题所有的消息。不同于传统的消息系统，横向伸缩 Kafka消费者和消费者群组并不会对性能造成负面影响。

在上面的例子里，如果新增一个只包含一个消费者的群组 G2，那么这个消费者将从主题 T1 上接收所有的消息，与群组 G1 之间互不影响。群组 G2 可以增加更多的消费者，每个消费者可以消费若干个分区，就像群组 G1 那样，如图 4-5 所示。总的来说，群组 G2 还是会接收到所有消息，不管有没有其他群组存在。

简而言之，为每一个需要获取一个或多个主题全部消息的应用程序创建一个消费者群组，然后往群组里添加消费者来伸缩读取能力和处理能力，群组里的每个消费者只处理一部分消息。

在这里插入图片描述

消费者群组和分区再均衡

我们已经从上一个小节了解到，群组里的消费者共同读取主题的分区。一个新的消费者加入群组时，它读取的是原本由其他消费者读取的消息。当一个消费者被关闭或发生崩溃时，它就离开群组，原本由它读取的分区将由群组里的其他消费者来读取。在主题发生变化时，比如管理员添加了新的分区，会发生分区重分配。

分区的所有权从一个消费者转移到另一个消费者，这样的行为被称为再均衡。再均衡非常重要，它为消费者群组带来了高可用性和伸缩性(我们可以放心地添加或移除消费者)，不过在正常情况下，我们并不希望发生这样的行为。在再均衡期间，消费者无法读取消息，造成整个群组一小段时间的不可用。另外，当分区被重新分配给另一个消费者时，消费者当前的读取状态会丢失，它有可能还需要去刷新缓存，在它重新恢复状态之前会拖慢应用程序。我们将在本章讨论如何进行安全的再均衡，以及如何避免不必要的再均衡。

消费者通过向被指派为群组协调器的 broker (不同的群组可以有不同的协调器)发送心跳来维持它们和群组的从属关系以及它们对分区的所有权关系。只要消费者以正常的时间间隔发送心跳，就被认为是活跃的，说明它还在读取分区里的消息。消费者会在轮询消息 (为了获取消息)或提交偏移量时发送心跳。如果消费者停止发送心跳的时间足够长，会话就会过期，群组协调器认为它已经死亡，就会触发一次再均衡。

如果一个消费者发生崩溃，井停止读取消息，群组协调器(broker)会等待几秒钟，确认它死亡了才会触发再均衡。在这几秒钟时间里，死掉的消费者不会读取分区里的消息。在清理消费者时，消费者会通知协调器它将要离开群组，协调器会立即触发一次再均衡，尽量降低处理停顿。在本章的后续部分，我们将讨论一些用于控制发送心跳频率和会话过期时间的配置参数，以及如何根据实际需要来配置这些参数。

分配分区是怎样的一个过程

当消费者要加入群组时，它会向群组协调器发送一个 JoinGroup 请求。第一个加入群组的消费者将成为“群主”。群主从协调器那里获得群组的成员列表(列表中包含了所有最近发送过心跳的消费者，它们被认为是活跃的)，并负责给每一个消费者分配分区。它使用一个实现了 PartitionAssignor接口的类来决定哪些分区应该被分配给哪个消费者。

Kafka 内置了两种分配策略，在后面的配置参数小节我们将深入讨论。分配完毕之后，群主把分配情况列表发送给群组协调器，协调器再把这些信息发送给所有消费者。每个消费者只能看到自己的分配信息，只有群主知道群组里所有消费者的分配信息。这个过程会在每次再均衡时重复发生。

https://blog.csdn.net/wobuaizhi/article/details/80950387
kafka分区（partition）和和分组（group）
2018年07月07日 12:37:37 现役码农一个阅读数 6140
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wobuaizhi/article/details/80950387
下面是自己在使用过程中的总结。欢迎拍砖

每个consumer只能消费指定的几个分区。那么消息如果没有发到监听的分区，那么那个消费者就不能获取到这次发送的消息。

下面的例子一定要注意对分区和分组的理解，不然会不知道为什么会得出那样的结论
消费组中的消费者会怎么取kafka的数据，看下方的介绍----来自网络
1.其中 broker有两个，也就是服务器有两台。
2.partition有6个，按照哈希取模的算法分配。
3.消费者有8个，他们属于同一个消费组。

那么这一个消费组中的消费者会怎么取kafka的数据呢？
其实kafka的消费端有一个均衡算法，算法如下：

1.A=(partition数量/同分组消费者总个数)
2.M=对上面所得到的A值小数点第一位向上取整
3.计算出该消费者拉取数据的patition合集：Ci = [P(M*i ),P((i + 1) * M -1)]

A=6/8=0.75
M=1

C0=[P(1*0),P((0+1)1-1)]=[P0,P0]
同理：
C1=[P(11),P((1+1)1-1)]=[P1,P1]
C2=[P(12),P((2+1)1-1)]=[P2,P2]
C3=[P(13),P((3+1)1-1)]=[P3,P3]
C4=[P(14),P((4+1)1-1)]=[P4,P4]
C5=[P(15),P((5+1)1-1)]=[P5,P5]
C6=[P(16),P((6+1)1-1)]=[P6,P6]
C7=[P(17),P((7+1)*1-1)]=[P7,P7]