“再平衡”在阿帕奇 · 卡夫卡的语境中意味着什么？

我是卡夫卡的新用户，现在已经试用了2-3周。我相信现在我已经很好地理解了大部分卡夫卡是如何工作的，但是在尝试为我自己的卡夫卡消费者提供适合的 API 之后(这是模糊的，但是我正在遵循新的卡夫卡消费者的指导方针，它应该是0.9版本的，在’主干’回购自动取款机上) ，如果我有多个拥有相同 groupID 的消费者，我就会遇到延迟问题。

在这个设置中，我的控制台始终记录有关“再平衡触发”的问题。当我将新的消费者添加到一个消费者组时，是否会发生重新平衡? 是否会触发重新平衡以确定相同 groupID 中的哪个消费者实例将获得哪个分区，或者重新平衡完全用于其他用途？

我也偶然发现了这段来自 https://cwiki.apache.org/confluence/display/KAFKA/Kafka+0.9+Consumer+Rewrite+Design的文章，但我似乎无法理解它，所以如果有人能帮助我理解它，我将不胜感激:

重新平衡是一组使用者实例 (属于同一集团)协调拥有一个相互排斥的 组订阅的主题的一组分区 一个消费群体成功的再平衡操作的结束 所有订阅主题的分区将由单个使用者拥有 重新平衡的工作方式如下。 集合的子集选择每个代理作为协调器 消费者组。组的协调代理负责 协调消费者群体成员的再平衡操作 更改或分区更改所订阅的主题 负责通信产生的分区所有权 组的所有消费者进行再平衡配置 行动。

94486 次浏览
小开
最佳答案

当一个新的消费者加入一个消费者组时，这组消费者尝试“重新平衡”负载，以便为每个消费者分配分区。如果在进行这种分配时使用者集合发生更改，则重新平衡将失败并重试。此设置控制放弃前的最大尝试次数。

这个命令是: rebalance.max.retry，默认设置为4。

此外，如果以下情况属实，这种情况也可能发生:

动物管理员会话超时。如果消费者在这段时间内没有向 ZooKeeper 发送心跳，则认为它已经死亡，将发生重新平衡。

希望这个能帮上忙！

小开

ReBalance 是在给定的消费者组内的消费者之间重新分配分区所有权。请记住，消费者群体中的每个使用者都被分配一个或多个主题分区 独家。

再平衡发生在以下情况:

  • 一个消费者加入了这个团体
  • 消费者干净利落地关门
  • 群组协调员认为消费者已经死亡。这可能发生在崩溃之后，或者当使用者忙于长时间运行的处理时，这意味着在配置的会话间隔内，使用者没有同时向组协调器发送任何心跳
  • 添加新的分区

作为为一个消费者组指定的 小组协调员(集群中的代理之一)和 组长(加入一个组的第一个消费者) ，再平衡可以或多或少地描述如下:

  • 组中所有消费者的列表 组协调器 (这将包括所有发送了 心跳，因此被认为是活的) 负责为每个使用者分配一个分区子集。
  • 在决定分区分配之后(卡夫卡有一对内置的分区分配策略) ，组长发送 分配给 小组协调员的任务列表，它发送这个 向所有消费者提供资料。

这适用于卡夫卡0.9，但我相信新版本仍然有效。

小开

使用者再平衡决定哪个使用者负责某个主题的所有可用分区的哪个子集。 例如，您可能有一个包含20个分区和10个使用者的主题; 在重新平衡结束时，您可能希望每个使用者从2个分区中读取内容。如果关闭其中的10个消费者，您可能希望在重新平衡完成之后，每个消费者拥有1个分区。消费者再平衡是一个动态分区分配，可以自动处理卡夫卡。

组协调器 是负责与消费者通信以实现消费者之间重新平衡的代理之一。在早期版本中，Zookeep 存储元数据详细信息，但在最新版本中，它存储在代理上。使用者协调器接收来自使用者组的所有使用者的心跳和轮询，因此要了解每个使用者的心跳，并在分区上管理它们的偏移量。

组长: 消费者组中的一个消费者作为组长工作，组长由组协调员选择，负责代表组中的所有消费者做出分区分配决策。

再平衡情景:

  1. 用户组订阅任何主题

  2. Consumer 实例无法发送带有 session.hear.beat 时间间隔的心跳。

  3. 使用者长进程超过了轮询超时时间

  4. 例外消费群体的消费者

  5. 添加了新的分区。

  6. 增加新用户或手动删除现有用户

消费者再平衡

当消费者请求加入一个组或离开一个组时，就会启动消费者再平衡。团队负责人从团队协调员那里收到一份所有活跃消费者的名单。组长使用 PartitionAssigner 决定分配给每个使用者的分区。 一旦组长完成分区分配，它将分配列表发送给组协调器，组协调器将这些信息发送给所有使用者。组只向其使用者发送适用的分区，而不向其他使用者指定的分区发送适用的分区。只有组长知道所有使用者及其分配的分区。 在重新平衡完成之后，消费者开始将 Heartbeat 发送给组协调器，告诉它是活的。 消费者向组协调器发送一个 OffsetFetch 请求，以获取所分配分区的最后一个提交的偏移量。 消费者开始为新分配的分区使用消息传递。

国家管理

在重新平衡时，Group 协调器将其状态设置为 ReBalance，并等待所有使用者重新加入组。

当组开始重新平衡时，组协调器首先将其状态转换为重新平衡，以便通知所有交互的使用者重新加入组。 一旦重新平衡完成的组协调器创建新的一代 ID，并通知所有消费者和组进入同步阶段，消费者发送同步请求，并等待组领导完成生成新的分配分区。一旦使用者收到一个新分配的分区，他们就会转移到一个稳定的阶段。

enter image description here

静态成员

这种重新平衡是一个相当繁重的操作，因为它需要停止所有使用者并等待获得新分配的分区。在每次重新平衡时，总是创建新的一代 id 意味着刷新一切。为了解决这个开销，卡夫卡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}

参考:

  1. Https://www.confluent.io/blog/kafka-rebalance-protocol-static-membership

  2. Https://cwiki.apache.org/confluence/display/kafka/kip-345%3a+introduce+static+membership+protocol+to+reduce+consumer+rebalances

小开

消费者群体、消费者与分割再平衡 卡夫卡消费者可以使用/订阅多个主题并开始接收消息。卡夫卡消费者是典型的消费群体的一部分。当多个使用者订阅了一个主题并且属于同一个使用者组时，组中的每个使用者将从该主题中的不同分区子集接收消息。

因此，使用者组中的使用者共享他们订阅的主题中分区的所有权。当我们向组中添加一个新的使用者时，它开始使用来自另一个使用者以前使用的分区的消息。当使用者关闭或崩溃时也会发生同样的事情; 它离开组，并且它使用的分区将被剩余的使用者之一使用。当使用者组被修改时，如同添加了新的分区一样，也会发生将分区重新分配给使用者的情况。

“ 将分区所有权从一个消费者移动到另一个消费者称为再平衡”在重新平衡期间，消费者不能消费信息，所以我们可以说，重新平衡是整个消费者群体无法获得的一个短期窗口。它还会导致消费者端的其他活动，比如当分区从一个消费者转移到另一个消费者时，cosnumber 会丢失当前状态，比如如果有任何数据缓存，那么它就需要刷新缓存，从而减慢整个应用程序的速度，直到消费者再次设置其状态。

Heartbeat.interval.ms

消费者在一个消费者组中保持成员身份，并且分配给他们的分区的所有权是通过向被指定为组协调者的卡夫卡经纪人发送心跳来实现的，这对于不同的消费者组是不同的。只要使用者定期发送 heart，那么它就被认为是活的，并且继续处理来自指定分区的消息，当使用者调用 poll 方法(从分区检索记录)和提交它已经使用的记录时，就会发送 Heartbeat。

如果使用者长时间停止发送心跳，并且它的会话超时(由 Session.timeout.ms控制) ，那么组协调器将认为它死亡，并因此触发重新平衡。如果一个消费者崩溃并且不处理消息，那么没有心跳的组协调器将花费几秒钟的时间来判断它是否死亡并触发重新平衡。在干净地关闭使用者时，使用者将通知组协调器它正在离开组，协调器将立即触发重新平衡，从而减少消息不可用的时间。


提交答案