apache kafka

消费者重新平衡决定哪个消费者负责某个主题的所有可用分区的哪个子集。 例如，您可能有一个包含20个分区和10个使用者的主题。 在重新平衡结束时，您可能希望每个使用者都从2个分区中读取数据。 如果关闭了这些使用者中的10个，则可能会期望每个使用者在重新平衡完成后具有1个分区。 消费者重新平衡是可以由Kafka自动处理的动态分区分配。

组协调员是负责与消费者进行通信以实现消费者之间平衡的经纪人之一。在早期版本中，Zookeeper存储了元数据详细信息，但最新版本存储在经纪人上。消费者协调员收到了所有消费者组消费者的心跳和轮询，因此他了解每个消费者心跳和管理者在分区上的偏移量。

小组组长：消费者组的一位消费者担任小组组长，由小组协调员选出，负责代表小组中的所有消费者做出分区分配决定。

重新平衡方案：

1. 消费者组订阅任何主题
2. 消费者实例无法使用session.heart.beat时间间隔发送心跳。
3. 消费者的长时间流程超出了轮询超时
4. 消费群体中的消费者通过例外
5. 添加了新分区。
6. 扩大消费者规模。 添加了新使用者或手动删除了现有使用者

消费者再平衡

消费者重新平衡是在消费者请求加入组或离开组时启动的。 小组负责人从小组协调员那里收到所有活跃消费者的名单。 组负责人使用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} 

参考：

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

翻译自: https://www.javacodegeeks.com/2020/06/apache-kafka-consumer-rebalance.html

apache kafka