kafka消费者组概念

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]

那么按照上面的算法：
C0消费者消费P0的数据
C1消费者消费P1的数据
C2消费者消费P2的数据
C3消费者消费P3的数据
C4消费者消费P4的数据

C5消费者消费P5的数据

C6消费者消费P6的数据
C7消费者消费P7的数据

但是partition只有P0-P5根本就没有P6和P7，所以这两个消费者相当于是会被闲置的，就相当于占用资源，却没什么用，所以在这里真正起到作用的就是C0-C5。
如果这个消费组里面的消费者少于partition数量呢（比如5个）？
那么还是依葫芦画瓢，根据上面的算法：

A=6/5=1.2
M=2
C0=[P(2*0),P((0+1)2-1)]=[P0,P1]
C1=[P(21),P((1+1)2-1)]=[P2,P3]
C2=[P(22),P((2+1)*2-1)]=[P4,P5]

C3=[P(2*3),P((3+1)2-1)]=[P6,P7]
C4=[P(24),P((4+1)*2-1)]=[P8,P9]

同上面一样C3和C4没有起到任何作用。

总结：
1.按照如上的算法，所以如果kafka的消费组需要增加组员，最多增加到和partition数量一致，超过的组员只会占用资源，而不起作用；

2.kafka的partition的个数一定要大于消费组组员的个数，并且partition的个数对于消费组组员取模一定要为0，不然有些消费者会占用资源却不起作用；

3.如果需要增加消费组的组员个数，那么也需要根据上面的算法，调整partition的个数

通过上面的介绍可以知道。针对一个分组中分区和消费者实际是有对应关系的。不是说增加了分区，就一定可以增加并发。具体情况需要多多分析。

注意：消费组就是group.id不同。kafka中，同一个topic下，消息会给下面每一个group发送消息（如果有十个，那个这十个group都会接受到这个消息）。但是分区每个消息只有一个分区获取。

kafka消费者组概念相关推荐

【Kafka】Kafka消费者组三种分区分配策略roundrobin，range，StickyAssignor
文章目录 1. 分配策略 1.1 Range(默认策略) 1.2 RoundRobin RoundRobin的两种情况 1.3 StickyAssignor 2. Range策略演示参考相关文章 ...
【Kafka】kafka 消费者组静态成员（static consumer member)
1.概述转载:https://www.cnblogs.com/huxi2b/p/11386847.html Kafka 2.3发布后官网的Consumer参数中增加了一个新的参数:group.ins ...
kafka | 消费者组到底是什么？
消费者组,即 Consumer Group,应该算是 Kafka 比较有亮点的设计了.那么何谓 Consumer Group 呢?用一句话概括就是:Consumer Group 是 Kafka 提供的 ...
Kafka 消费者组 Rebalance 详解
Rebalance作用 Rebalance 本质上是一种协议,主要作用是为了保证消费者组(Consumer Group)下的所有消费者(Consumer)消费的主体分区达成均衡. 比如:我们有10个分 ...
kafka消费者组消费数据问题
前言在上一篇的消费者代码中,里面提到了一个很重要的点,那就是在代码中必须要指明消费者组,为什么要这样呢? 这个跟kafka自身在架构设计时是有一定的关系的,通过之前的学习我们知道,kafka天生就是 ...
kafka 消费者组
每个分区只能由同一个消费者组内的一个 Consumer 实例来消费 Consumer Group 下可以有一个或多个 Consumer 实例.这里的实例可以是一个单独的进程, 也可以是同一进程下的线程 ...
Kafka 消费者组重平衡（Rebalance）
Kafka Consumer Reblance 消费者组的重平衡就组内的消费者,对消费那些主题分区达成一致的过程,Kafka会尽量保证分配的均匀. consumer group 的rebalance ...
Kafka消费者组三种分区分配策略roundrobin，range，StickyAssignor
一个consumer group中有多个consumer,一个 topic有多个partition,所以必然会涉及到partition的分配问题,即确定那个partition由哪个consumer来消 ...
Kafka 消费者组管理模块（六）：GroupCoordinator 处理成员入组
Rebalance 的流程大致分为两大步:加入组(JoinGroup)和组同步(SyncGroup). 加入组,是指消费者组下的各个成员向 Coordinator 发送 JoinGro ...

kafka消费者组概念

kafka消费者组概念相关推荐

最新文章

热门文章