我是Kafka的新用户,现在已经试用了大约2-3周。我相信目前我已经很好地理解了Kafka在大多数情况下的工作方式,但在尝试为我自己的Kafka消费者设计API之后(这是模糊不清的,但我遵循新KafkaConsumer的指导方针,即应该可用于v 0.9,它出现在' trunk' repo atm上)如果我有多个拥有相同groupID的消费者,我会从主题中消耗延迟问题。
在此设置中,我的控制台始终记录有关“重新平衡触发”的问题。当我向消费者群体添加新的消费者时,是否会发生重新平衡,并且为了找出同一个群组ID中的哪个消费者实例将获得哪些分区或者是完全用于其他内容的重新平衡,它们会被触发?
我也从https://cwiki.apache.org/confluence/display/KAFKA/Kafka+0.9+Consumer+Rewrite+Design看到了这段话,我似乎无法理解它,所以如果有人能帮助我理解它,那将非常感激:
重新平衡是一组消费者实例的过程 (属于同一组)协调拥有互斥 该组订阅的主题分区集。在 每个消费者群体的成功再平衡操作的结束 所有订阅主题的分区将由单个消费者拥有 组内的实例。重新平衡的工作方式如下。 每个经纪人都被选为协调员的一部分 消费者群体。集团的协调经纪人负责 用于编排消费者组成员资格的重新平衡操作 订阅主题的更改或分区更改。也是 负责传达生成的分区所有权 配置给正在进行重新平衡的组的所有消费者 操作
答案 0 :(得分:40)
当新的消费者加入消费者群体时,消费者集合会尝试“重新平衡”负载,以便为每个消费者分配分区。如果在进行此分配时消费者集合发生更改,则重新平衡将失败并重试。此设置控制放弃前的最大尝试次数。
这个命令是:rebalance.max.retries,默认设置为4.
另外,如果以下情况属实,可能会发生:
ZooKeeper会话超时。如果消费者在这段时间内没有心跳到ZooKeeper,那么它就会被认为已经死亡,并且会发生重新平衡。
希望这有帮助!
答案 1 :(得分:25)
消费者组中的每个消费者都被分配了一个或多个主题分区, Rebalance 是消费者之间分配所有权的重新分配。
重新平衡在以下情况发生:
作为组协调员(集群中的一个代理)和组长(加入组的第一个消费者),为消费者组指定, Rebalance 可以或多或少地描述如下:
这适用于Kafka 0.9,但我很确定新版本仍然有效。
答案 2 :(得分:3)
消费者重新平衡决定哪个消费者负责某些主题的所有可用分区的哪个子集。 例如,您可能有一个包含20个分区和10个使用者的主题。在重新平衡结束时,您可能希望每个使用者都从2个分区中读取数据。如果关闭了这些使用者中的10个,则可能会期望每个使用者在重新平衡完成后具有1个分区。消费者重新平衡是可以由Kafka自动处理的动态分区分配。
组协调员是负责与消费者进行通信以实现消费者之间平衡的经纪人之一。在早期版本中,Zookeeper存储元数据详细信息,但最新版本存储在经纪人上。消费者协调员从接收者发出心跳和轮询消费者组的所有消费者,因此他了解每个消费者的心跳并管理其在分区上的偏移量。
小组组长: 消费者组的一位消费者担任组长,由组协调员选择,负责代表组中的所有消费者做出分区分配决定。
重新平衡方案:
耗时较长的进程超过了轮询超时
通过例外的消费者组的消费者
已添加新分区。
扩大消费者规模。为
消费平衡
当消费者请求加入一个小组或离开一个小组时,消费者重新平衡开始。小组负责人从小组协调员那里收到所有活跃消费者的名单。组负责人使用PartitionAssigner决定分配给每个使用者的分区。 一旦组长完成分区分配,它就会将分配列表发送给组协调器,组协调器将这些信息发送回所有使用者。组仅将适用的分区发送给其使用者,而不发送其他使用者分配的分区。只有组长知道所有使用者及其分配的分区。 重新平衡完成后,消费者开始将“心跳”发送到仍活跃的“组协调器”。 使用者向组协调器发送OffsetFetch请求,以获取为其分配的分区的最后提交的偏移量。 消费者开始消费新分配分区的消息。
状态管理
重新平衡时,组协调员将状态设置为“重新平衡”,并等待所有消费者重新加入组。
当组开始重新平衡时,组协调器首先将其状态切换为重新平衡,以便通知所有交互的消费者重新加入组。 重新平衡完成后,组协调器会创建新的ID,并通知所有消费者,然后该组继续进行同步阶段,在此阶段,消费者发送同步请求,并等待直到组长完成生成新的分配分区。一旦消费者收到新的分配分区,他们便进入稳定阶段。
静态成员身份
这些重新平衡操作相当繁琐,因为它需要停止所有使用者并等待获取新分配的分区。在每次重新平衡时,始终创建新一代id,这意味着刷新所有内容。为了解决此开销,Kafka 2.3+引入了静态成员资格以减少不必要的重新平衡。 KIP-345
在“静态成员身份”中,消费者状态将保持不变,在“重新平衡”中,将应用相同的分配。它使用新的group.instance.id来保留成员身份。因此,即使在最坏的情况下,成员ID也会被改组以分配新的分区,但是相同的使用者实例ID仍将获得相同的分区分配
instanceId: A, memberId: 1, assignment: {0, 1, 2}
instanceId: B, memberId: 2, assignment: {3, 4, 5}
instanceId: C, memberId: 3, assignment: {6, 7, 8}
重启后:
instanceId: A, memberId: 4, assignment: {0, 1, 2}
instanceId: B, memberId: 2, assignment: {3, 4, 5}
instanceId: C, memberId: 3, assignment: {6, 7, 8}
参考:
答案 3 :(得分:0)
消费者组、消费者和分区重新平衡 Kafka Consumer 可以消费/订阅多个主题并开始接收消息。 Kafka 消费者通常是消费者群体的一部分。当多个消费者订阅一个主题并属于同一个消费者组时,组中的每个消费者都会收到来自主题中不同分区子集的消息。
因此消费者组中的消费者共享他们订阅的主题中的分区的所有权。当我们向组中添加一个新的消费者时,它开始消费来自另一个消费者先前消费的分区的消息。当消费者关闭或崩溃时也会发生同样的事情;它离开该组,它用于消费的分区将被剩余的消费者之一消费。当消费者组正在消费时,也会发生将分区重新分配给消费者的情况,例如添加新分区。
"将分区所有权从一个使用者转移到另一个使用者称为重新平衡" 在重新平衡期间,使用者不能使用消息,因此我们可以说重新平衡是对整个消费群体不可用。它还导致消费者方面的一些其他活动,例如当分区从一个消费者移动到另一个消费者时,消费者失去其当前状态,就像任何数据被缓存一样,然后它需要刷新其缓存,减慢整个应用程序,直到消费者被设置。再次进入状态。
heartbeat.interval.ms
消费者维护消费者组的成员资格,分配给他们的分区的所有权是通过向指定为组协调器的 Kafka 代理发送心跳来实现的,不同的消费者组会有所不同。只要消费者定期发送心跳,那么它就被认为是不活跃的,并继续处理来自指定分配分区的消息当消费者调用轮询方法(从分区检索记录)并提交记录时发送心跳消耗了。
如果消费者长时间停止发送心跳并且其会话将超时(由 session.timeout.ms 控制),则组协调器将认为它已死并因此触发重新平衡。如果消费者崩溃并且不处理消息,则组协调器将需要几秒钟没有心跳来确定它已死并触发重新平衡。干净地关闭消费者时,消费者会通知组协调器它正在离开组,协调器会立即触发重新平衡,减少消息不可用的时间。