Kafka Connect Rebalance协议解析：Eager Rebalance VS Imcremental Cooperative Rebalance
- Eager Rebalance
-
- 第一个新成员加入时
- 其他新成员加入时
- 组成员离开时
- Imcremental Cooperative Rebalance
-
- 第一个组成员加入时
- 其他新成员加入时
- 普通成员离开时
- Leader离开时
- Leader离开后又马上返回时
- 总结
- 参考文档
在Kafka Connect的配置中有
connect.protocol
配置，可用于配置同一组Kafka Connect在Rebalance中的表现。
Kafka Connect的Rebalance的基础也是依赖于Kafka Group Membership协议，但它自身有两种协议根据协议的不同，Rebalance的过程也有很大的不同。这篇文章对Kafka Connect的两种Rebalance协议：Eager Rebalance和Imcremental Cooperative Rebalance进行分析，让大家明白在各种场景下如何选择合适的
connect.protocol
。
Eager Rebalance
Kafka Connect组在Rebalance的时候跟Kafka Consumer组一样，也是需要一个Kafka broker作为Coordinator来进行Rebalance的协调，如下图所示。
而Kafka Connect的Eager Rebalance在Rebalance过程中表现的行为跟Kafka Consumer组是一样的，只要触发Rebalance，所有的同一组Kafka Connect都重新开始：重新加入组，选择Leader，Leader重新计算Assignment，Coordinator向每个Kafka Connect发送Assignment结果，Kafka Connect根据新的Assignment运行分配的Connectors和Tasks。
下面用几个场景进行举例。假设一组Kafka Connect运行两个Connectors，ConnectotA和ConnectorB，简写为（和AC0
）。AC0的任务数为2，简写为BC0
、AT1
。BC0的任务数为1，简写为AT2
。一组有3个Kafka Connect，以BT1
、W1
、W2
分别表示。W3
第一个新成员加入时
当同一组只有一个Kafka Connect的时候，这个Kafka Connect就自然而然的成为组的Leader，并且所有Connectors和Tasks都在它上面运行。
其他新成员加入时
如上图所示，当W2加入组时。Coordinator会触发Rebalance，会通知W1重新加入组。当W1重新请求加入组后，Coordinator会在W1、W2中选择一个Leader，Leader重新计算Assignment分配Connectors和Tasks。
组成员离开时
在Eager Rebalance协议下，无论是普通成员还是Leader的离开都会立即触发Rebalance。这个Rebalance的过程也跟前面一样，所有剩余的组成员重新加入组，一切都重新开始。
从上述场景的分析可以知道Kafka Connect的Eager Rebalance协议，只要同一组的成员发生变化（成员离开加入，Connectors配置变化，Tasks配置变化等），都会立即触发Rebalance过程，而且这个Rebalance的过程是完全重新开始。对于Kafka Consumer来说，这种方式的Rebalance可能影响不太大，应为同一组的Kafka Consumer都做的是同一件事情，变化没有Kafka Connect那么多。Kafka Connect提供了一种机制让处理异构资源的Connectors和Tasks都能在一起运行。对于一组有很多Connectors和Tasks的Kafka Connect组来说，其中一个Connector的变化就会导致Rebalance，就会影响其他正常运行的Connecotrs。还有Kafka Connect中Connector的插件进行滚动升级的场景下，一个Kafka Connect只是短暂的离开，但也会造成整个组完全的Rebalance过程。这些情况对Kafka Connect的正常运行带来了极大的影响。因此Kafka社区也意识到了这个问题，在KIP-415提出了新的兼容性Rebalance协议Imcremental Cooperative Rebalance，并且在Kafka 2.3.0开始提供。
Imcremental Cooperative Rebalance
Imcremental Cooperative Rebalance作为新的connect protocol并不是完全使用另一套协议，而是扩展当前存在的协议，通过在当前消息格式中添加可选的新字段。Kafka Connect在加入组的时候会带上当前已经运行的Assignment信息，并且引入了一个延迟时间延后Rebalance过程。Imcremental Cooperative Rebalance能与Eager Rebalance的时间触发过程兼容，而又能解决Eager Rebalance对Kafka Connect造成的影响。
第一个组成员加入时
这种情况Imcremental Cooperative Rebalance能与Eager Rebalance的过程都是一样的。只是W1发送加入请求的时候会带上Assignment信息。
其他新成员加入时
当W2、W3请求加入组后，W1重新成为Leader后对Assignment的计算和分配不是像Eager Rebalance那样完全重新计算。而是会考虑当前已经运行的Assignment情况。如上图所示，所有的Connectors和Tasks本来都在W1上运行，W1先要撤销一部分Connectors和Tasks才能分配个W2，W3，并且重新分配过程中不会中断Connector AC0和Task AT1的运行。
普通成员离开时
W2离开后，W1重新被选择作为Leader后，没有立即将W2的任务瓜分，而是维持原来W1和W3的Assignment，并且加入了一个延时d。只有在这个延时超时后，重新进行Rebalance的时候才会瓜分W2原来的任务，这一过程对W1、W3原先运行的Assignment没有任何影响。如果在延时d到达之前，W2又返回来了，处理过程如下图所示。
Leader离开时
当Leader离开的情况下，Rebalance重新选择Leader，新的Leader会立即瓜分W1原来的任务不会引入延时时间，但是W2,W3原先运行的Assignment不会受到影响。
Leader离开后又马上返回时
如上图所示，如果Leader离开时，还处在延迟时间的情况下。新的Leader不会立即分配Leader的任务。如果Leader在延迟时间结束前回来，重新加入组，这时候由于延迟时间存在，也不会立即被分配任务。直到延长时间接受，同组成员再走加入组的流程，新的Leader会将没有分配的任务分配到各个成员上。在上图过程中，W2,W1的离开始终不会影响W3的Task BT1的运行。
总结
本文分析了Kafka Connect的两种Rebalance protocol：Eager Rebalance和Imcremental Cooperative Rebalance。根据不同的场景分析了这两种protocol的区别。一般来说，如果一组Kafka Connect运行很多不同的Connectors和滚动升级插件的情况下，更适合Imcremental Cooperative Rebalance。但是Eager Rebalance也不是没有完全没有用武之地，Eager Rebalance可以让Kafka Connect组立即达到负载均衡的状态，可参考这个问题，但是应该用于变化不大的场景下。
参考文档
Apache Kafka Rebalance Protocol, or the magic behind your streams applications.
Kafka消费组(consumer group)
KIP-415: Incremental Cooperative Rebalancing in Kafka Connect