静态会员是对当前再平衡协议的一种增强，旨在减少由一般Apache Kafka®客户实现的过度和不必要的再平衡造成的停机时间。这适用于Kafka消费者、Kafka Connect和Kafka流。为了更好地理解再平衡协议，我们将深入研究这个概念并解释它的含义。如果你已经知道卡夫卡平衡是什么，请直接跳到下面的章节来节省时间:我们什么时候触发不必要的平衡?

对于Kafka来说，“再平衡”意味着什么?

Kafka再平衡是一种分布式协议，用于客户端应用程序在一个动态组中处理一组公共资源。本议定书的两个主要目标是:

• 组织资源分配
• 会员更改捕获

以卡夫卡消费者为例。一组Kafka使用者通过订阅从Kafka读取输入数据，主题分区是他们的共享任务单元。三个消费者(C1、C2和C3)、两个主题(T1和T2)，每个主题有三个分区，订阅如下所示:

C1: T1, T2
C2: T2
C3: T1

重新平衡协议确保C1和C2从主题T2*获得不重叠的分配，对于T1的C1和C3也是如此。一个有效的赋值是这样的:

C1: t1-p1, t2-p1
C2: t2-p2, t2-p3
C3: t1-p2, t1-p3

*注意，消费者不会检查转让人返回的赋值是否遵守这些规则。如果您的自定义的assignor将分区分配给多个所有者，它仍然会被静默地接受并导致双重抓取。严格地说，只有内置的再平衡分配程序才遵守此资源隔离规则

但是，下面的分配是不允许的，因为它引入了重叠分配:

 

C1: t1-p1, t2-p1
C2: t2-p1, t2-p2, t2-p3
C3: t1-p2, t1-p3

再平衡协议还需要妥善处理成员国变化。对于上述情况，如果新成员C4订阅T2加入，再平衡协议将尝试调整组内负载:

C1: t1-p1, t2-p1
C2: t2-p3
C3: t1-p2, t1-p3
C4: t2-p2

总之，再平衡协议需要在扩展时“平衡”客户机组中的负载，同时保证任务所有权的安全。与大多数分布式共识算法相似，Kafka采用了两阶段的方法。为了简单起见，我们将坚持使用卡夫卡消费者。

消费者调整演示

使用者提交进度的端点称为组协调器，它托管在指定的代理上。它还作为集团再平衡的中央管理者。当组开始再平衡时，组协调器首先将其状态切换为再平衡，以便通知所有交互的使用者重新加入组。在所有成员重新加入或协调器等待足够长的时间并达到再平衡超时之前，组继续进入另一个称为sync的阶段，该阶段正式宣布有效使用者组的形成。为了区分在此过程中退出组的成员，每个成功的再平衡都会增加一个名为generation ID的计数器，并将其值传播给所有加入的成员，以便可以隔离下一代成员。

在同步阶段，组协调器用最新的生成信息答复所有成员。具体地说，它指定其中一个成员作为leader，并用已编码的成员资格和订阅元数据对leader进行应答。

领导根据成员和主题元数据信息完成任务，并将任务信息回复协调员。在此期间，所有追随者都需要发送一个同步组请求，以获得他们的实际任务，并进入一个等待池，直到leader完成对协调器的任务传输。在接收到分配后，协调器将组从同步转换到稳定。所有未决的和即将到来的追随者同步请求将回答与个人分配。

这里，我们描述两个演示用例:一个是实际的再平衡演练，另一个是高级状态机。注意，在同步阶段，如果触发了再平衡条件，比如添加新成员、主题分区扩展等，我们总是可以切换到再平衡模式。

再平衡协议在实时平衡任务处理负载和允许用户自由伸缩应用程序方面非常有效，但它也是一个相当重的操作，需要整个消费组暂时停止工作。成员被期望撤销正在进行的任务，并在每次重新平衡开始和结束时初始化新的任务。这样的操作会带来开销，特别是对于有状态的操作，其中任务需要在提供服务之前首先从其备份主题恢复本地状态。

从本质上讲，当满足以下条件时，再平衡就开始了:

• 组成员变更，例如新成员加入
• 成员订阅更改，例如一个使用者更改订阅的主题
• 资源更改，例如向订阅主题添加更多分区

我们什么时候触发不必要的再平衡?

在现实世界中，有许多场景中，组协调器会触发不必要的重新平衡，这对应用程序性能有害。第一种情况是临时成员超时。要理解这一点，我们需要首先介绍两个概念:使用者心跳和会话超时。

消费者心跳和会话超时

Kafka使用者维护一个后台线程，定期向协调器发送心跳请求，以表明它的活性。使用者配置称为session.timeout。ms定义了协调器在成员最后一次心跳之后等待多长时间，然后才假定该成员失败。当此值设置得过低时，网络抖动或长时间垃圾收集(GC)可能会导致活性检查失败，从而导致组协调器删除此成员并开始重新平衡。解决方案很简单:与其使用缺省的10秒会话超时，不如将其设置为更大的值，以极大地减少由故障引起的暂态重平衡。

注意，会话超时设置的时间越长，用户实际失败时部分不可用的时间就越长。我们将在后面关于如何选择静态成员关系的部分中解释如何选择此值。

滚动反弹过程

有时，我们需要重新启动应用程序、部署新代码或执行回滚等。在最坏的情况下，这些操作可能导致大量的重新平衡。当一个使用者实例关闭时，它向组协调器发送一个请假组请求，让它自己从组中删除，然后触发另一次再平衡。当这个消费者在一次反弹后恢复时，它会向组协调器发送一个加入组请求，从而触发另一次再平衡。

在滚动弹跳过程中，连续的重新平衡被触发，实例被关闭和恢复，分区被来回重新分配。最终的赋值结果是完全随机的，并且会为任务变换和重新初始化付出很大代价。

让成员选择不离开小组怎么样?也不是一个选择。要理解其中的原因，我们需要先讨论一下成员ID。

消费者会员ID

当新成员加入组时，请求不包含成员信息。组协调器将为该成员分配一个统一惟一标识符(UUID)，作为其成员ID，将该ID放入缓存中，并将该信息嵌入到对该成员的响应中。在这个使用者的生命周期内，它可以重用相同的成员ID，而不需要协调器在重新加入时触发再平衡，除非在诸如leader重新加入这样的边缘情况下。

回到滚动反弹的情况下,重新启动成员将删除内存中的会员信息和加入该组织成员ID或生成ID。自从加入消费者会被认为是一个全新的组的成员,该组织协调并不能保证其旧任务分配方案。如您所见，成员离开组并不是造成不必要任务变换的根本原因—丢失身份才是。

什么是静态会员?

与动态成员关系不同，静态成员关系旨在跨组的多个代保持成员身份。这里的目标是重用相同的订阅信息，并使协调器“可识别”旧成员。静态成员关系引入了一个名为group.instance的新的使用者配置。id，由用户配置，以惟一地标识其使用者实例。尽管在重启过程中丢失了协调器分配的成员ID，但是协调器仍然将根据join请求中提供的组实例ID识别该成员。因此，保证了相同的赋值。

静态成员关系对于云应用程序的设置非常友好，因为现在Kubernetes等部署技术对于管理应用程序的运行状况非常自包含。为了修复死去的或性能不佳的用户，Kubernetes可以很容易地关闭相关实例，然后使用相同的实例ID启动一个新的实例。

下面是静态成员关系如何工作的快速演示。

如何选择成为静态会员

自从Apache Kafka 2.3发布以来，静态成员已经成为社区的普遍可用性。如果你想成为一个阿尔法用户，这里有说明:

• 将您的代理升级到2.3或更高。具体来说，您需要升级inter.broker.protocol。版本升级到2.3或更高，以启用此特性。
• 在客户端:
  • 将客户端库升级到2.3或更高版本。
  • 定义较长且合理的会话超时。如前所述，紧张的会话超时值可能会使组不稳定，因为成员会由于缺少单个心跳而被逐出组。您应该根据部分不可用的业务容忍度将会话超时设置为合理的值。例如，对于能够容忍15分钟不可用的业务，将会话超时设置为10分钟是合理的，而将其设置为5秒则不合理。
  • 设置group.instance。id配置为用户的惟一id。如果你是Kafka流的用户，对你的流实例使用相同的配置。
• 将新代码部署到应用程序中。静态会员将在您的下一次滚动反弹中生效。

静态成员只有在遵循这些指令的情况下才能正常工作。尽管如此，我们还是采取了一些预防措施，以减少人为失误的潜在风险。

错误处理

有时用户可能会忘记升级代理。当使用者首次启动时，它获得指定代理的API版本。如果客户端配置了组实例ID，并且代理是旧版本的，那么应用程序将立即崩溃，因为代理还不支持静态成员关系。

如果用户未能惟一地配置组实例ID，这意味着有两个或多个成员使用相同的实例ID配置，则需要使用隔离逻辑。当一个已知的静态成员没有一个成员ID,协调器生成一个新的UUID回复这个成员作为其新成员ID。与此同时,该组织协调维护映射实例ID的最新成员分配ID。如果一个已知的静态成员和一个有效的成员ID不匹配的缓存ID,它会立即被协调坚固的回应。这消除了重复静态成员并发处理的风险。

在第一个版本中，我们预计会出现一些错误，这些错误可能会使处理语义失效或阻碍防护逻辑。其中一些问题已经在主干中得到了解决，比如KAFKA-8715，我们仍在积极寻找更多问题。

原文：https://www.confluent.io/blog/kafka-rebalance-protocol-static-membership/

本文：http://jiagoushi.pro/node/1116

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】