apache-kafka - 启动大量 kafka 流会严重加载列表中的第一个 kafka 代理

Question

我有 15 个节点的 kafka 集群: kafka1.com:9092,kafkaN.com:9092...,kafka10.com:9092

我还有 10 个节点的应用程序，消耗大约 100 个主题(从 2 到 240 个分区)。对于每个主题应用程序都会使用一些转换逻辑创建单独的 KafkaStreams 对象实例。

在拥有如此数量的消费者节点之前，我没有遇到任何问题，但随着部署期间节点数量的增加，该应用程序开始大量加载 kafka 集群。但是，如果整个集群在部署期间平均损失约 2% 的 CPU，代理列表中的第一个节点 kafka1.com:9092 会损失大约 50-60% 的 CPU 和关键指标平均时间比例请求处理程序线程空闲 对于该经纪人来说变得非常低。

如果 kafka 在负载下(巨大的吞吐量)，或者根本没有处理任何消息，这种行为绝对相同。

我尝试过设置，但每次我看到相同的指标 =( 我什至将 kafka-clients 更新到 2.3.0 版本 代理是 1.1.1 版本

我认为它可能与元数据获取有关，因为我看不到 Kafka Streams(消费者、生产者、管理客户端)从列表中的第一个代理请求其他数据的其他方式。

但是为什么它对代理负载如此之大？

Answer 1

如果没有具体的细节和监控指标，很难判断根本原因到底是什么。

但是，从经验来看，这些是Kafka负载分布不均匀的主要原因:

1. Kafka Broker 节点之间的分区分布不均匀

   这种情况其实在official Kafka documentation中有描述。 。尽管描述的是扩展集群的情况，但在大集群的正常运行期间也可能发生这种情况。基本上，Kafka 在代理节点之间分配分区的可能性很大。

   因此，kafka1.com:9092 可能是集群中大部分分区的领导者，因此增加了 CPU/磁盘/网络使用率(因为最大部分消费者连接到它+复制上花费的开销)。

   这个问题的解决办法是 explicitly reassigning partitions .

2. 领导者选举不均匀(以及重复的领导者重新平衡)

   这通常与分区分布不均匀一起发生。基本上，如果领导者节点不堪重负，卡夫卡将决定重新选举领导者。然而，由于分区分布不均匀 - 它没有帮助，导致更多的领导者重新选举，从而增加集群的负载。

   这个问题的解决办法是 increasing replication factor (与 partition reassignment 一起)。

   这可能看起来违反直觉(因为增加复制因子会增加复制开销)。然而，这暗示 Kafka 在更多节点之间分发数据，从而帮助卸载不堪重负的节点。

3. 分区(以及相应的代理节点)之间的消息分布不均匀

   基本上，如果应用程序使用 DefaultPartitioner (通常是这种情况)，您可能无法在分区之间获得消息的循环分配。根据卡夫卡常见问题解答:if there are fewer producers than partitions, at a given point of time, some partitions may not receive any data 。因此，某些分区(以及相应的代理节点)可能数据过载，而其他分区则负载不足。

此外，如果在没有实际输入消息时集群整体繁忙 - 这通常是由于 Kafka 尝试使用偏移量和 ACK 同步所有副本而引起的。