我们正在运行3个经纪人Kafka 0.10.0.1集群。我们有一个Java应用程序，该应用程序产生了许多来自不同主题的使用者线程。对于每个主题，我们都指定了不同的消费者组。
很多时候，我看到只要重新启动此应用程序，一个或多个CG就需要5分钟以上的时间来接收分区分配。到那时为止，该主题的消费者什么都不消费。如果我去Kafka经纪人并运行consumer-groups.sh并描述该特定CG，我会看到它正在重新平衡。 在server.log中，我看到了这样的行
准备稳定otp-sms-consumer组 稳定组otp-sms-consumer
在这两个日志之间通常存在大约5分钟或更长时间的间隔。 在消费者方面，当我打开跟踪级别的日志时，在此暂停时间内实际上没有任何活动。几分钟后，开始大量活动。 像otp-sms这样的主题中存储着时间紧迫的数据，我们不能忍受这么长的延迟。如此长时间的重新平衡可能是什么原因。
这是我们的消费者配置
auto.commit.interval.ms = 3000
auto.offset.reset = latest
bootstrap.servers = [x.x.x.x:9092, x.x.x.x:9092, x.x.x.x:9092]
check.crcs = true
client.id =
connections.max.idle.ms = 540000
enable.auto.commit = true
exclude.internal.topics = true
fetch.max.bytes = 52428800
fetch.max.wait.ms = 500
fetch.min.bytes = 1
group.id = otp-notifications-consumer
heartbeat.interval.ms = 3000
interceptor.classes = null
key.deserializer = class org.apache.kafka.common.serialization.StringDeserializer
max.partition.fetch.bytes = 1048576
max.poll.interval.ms = 300000
max.poll.records = 50
metadata.max.age.ms = 300000
metric.reporters = []
metrics.num.samples = 2
metrics.sample.window.ms = 30000
partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RangeAssignor]
receive.buffer.bytes = 65536
reconnect.backoff.ms = 50
request.timeout.ms = 305000
retry.backoff.ms = 100
sasl.kerberos.kinit.cmd = /usr/bin/kinit
sasl.kerberos.min.time.before.relogin = 60000
sasl.kerberos.service.name = null
sasl.kerberos.ticket.renew.jitter = 0.05
sasl.kerberos.ticket.renew.window.factor = 0.8
sasl.mechanism = GSSAPI
security.protocol = SSL
send.buffer.bytes = 131072
session.timeout.ms = 300000
ssl.cipher.suites = null
ssl.enabled.protocols = [TLSv1.2, TLSv1.1, TLSv1]
ssl.endpoint.identification.algorithm = null
ssl.key.password = null
ssl.keymanager.algorithm = SunX509
ssl.keystore.location = null
ssl.keystore.password = null
ssl.keystore.type = JKS
ssl.protocol = TLS
ssl.provider = null
ssl.secure.random.implementation = null
ssl.trustmanager.algorithm = PKIX
ssl.truststore.location = /x/x/client.truststore.jks
ssl.truststore.password = [hidden]
ssl.truststore.type = JKS
value.deserializer = class org.apache.kafka.common.serialization.StringDeserializer
请帮助。
答案 0 :(得分：0)
您的消费者配置似乎合理。我建议尝试三件事：
这应该可以让您查明问题所在。如果您能够使用一个线程而不是多个线程来消耗所有东西，那么您的线程机制/池可能会出现问题。
答案 1 :(得分：0)
检查磁盘上的__consumer_offsets分区大小。我们遇到了由于压缩错误而导致的类似问题。这导致很长的重新平衡。
有关更多详细信息，请参见https://issues.apache.org/jira/browse/KAFKA-5413（自kafka 0.10.2.2 / 0.11起解决）
另一个选择是您的代理配置不正确，并且压缩已关闭；如果为false，则log.cleaner.enable。 __consumer_offsets是一个压缩的主题，因此，如果禁用log.cleaner，将不会对其进行压缩并导致相同的症状。
答案 2 :(得分：0)
我怀疑您的群集版本至少为0.10.1.0，正如我在此version中引入的使用者配置中看到的max.poll.interval.ms一样。
Kafka 0.10.1.0集成了KIP-62，它引入了设置为max.poll.interval.ms的重新平衡超时，其默认值为5分钟。
我想，如果您不想在重新平衡期间等待超时到期，则您的消费者需要通过调用close()方法来干净地离开消费者组。
答案 3 :(得分：0)
重新平衡超时等于max.poll.interval.ms（在您的情况下为5分钟）当一个组中开始重新平衡时，Kafka会撤消该组中的所有使用者。然后等待所有活动的使用者（发送心跳的使用者）进行poll（）并发送JoinGroupRequest。
此等待过程将以重新平衡超时结束，或者所有活动的使用方poll（）和Kafka将分区分配给这些使用方。
因此，在您的情况下，您的使用者中可能有一个运行很长时间的过程，而Kafka等待此过程完成以分配分区。
有关更多信息，您可以检查以下内容：
消费群体是卡夫卡的重要机制。他们允许 消费者通过动态分配来共享负载并弹性扩展 主题划分给消费者。在我们目前的模型中 消费者群体，每当发生重新平衡时， 小组经历停机时间-他们的poll（）调用会阻塞，直到每次 该组中的其他使用者调用poll（）。那是因为 在平衡的情况下，每个消费者都需要致电JoinGroup 为了确认它仍在组中。
今天，如果客户端已将
max.poll.interval.ms配置为较大 价值，集团协调经纪人将获得无限数量 加入组请求，因此重新平衡可能会持续 无限的时间。 （https://cwiki.apache.org/confluence/display/KAFKA/KIP-389%3A+Introduce+a+configurable+consumer+group+size+limit）
-
由于我们为客户提供了最多max.poll.interval.ms来处理 一批记录，这也是消费者可以使用的最长时间 预计在最坏的情况下会重新加入该小组。因此，我们 建议将Java客户端中的重新平衡超时设置为相同 使用max.poll.interval.ms配置的值。当重新平衡开始时， 后台线程将继续发送心跳。消费者 在处理完成并且用户之前，不会重新加入该组 调用poll（）。从协调员的角度来看，消费者将 直到1）他们的会话超时才从组中删除 过期而没有收到心跳，或者2）重新平衡超时 过期。