首页 文章

Kafka 消费者，非常长的重新 balancer

提问于
浏览 次
9

我们正在运行一个3经纪人Kafka 0.10.0.1集群 . 我们有一个java应用程序，它产生许多消费者线程，消费来自不同的主题 . 对于每个主题，我们都指定了不同的消费者群体 .

很多时候，我发现每当重新启动此应用程序时，一个或多个CG需要超过5分钟来接收分区分配 . 直到那个时间消费者不会消费任何东西 . 如果我去Kafka经纪人并运行consumer-groups.sh并描述那个特定的CG，我发现它正在重新 balancer . 在server.log中我看到这样的行

准备稳定群体otp-sms-consumer稳定群体otp-sms-consumer

在这两个原木之间通常存在约5分钟或更长的间隙 . 在消费者方面，当我打开跟踪级别日志时，在此暂停时间内几乎没有任何活动 . 几分钟后，很多活动开始了 . 在该主题中存储时间关键数据，如otp-sms，我们不能容忍这种长时间的延迟 . 这种长期再 balancer 的原因是什么？

这是我们的消费者配置

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

请帮忙 .

apache-kafka

2 回答

  • 0

    您的消费者配置似乎合理 . 我建议尝试三件事：

    • 尝试生成单个使用者线程，并仅为其分配一个获取所有数据的主题 .

    • 一旦验证了它的工作原理，就会生成一个消费者线程，并为其分配您尝试使用的所有主题 . 执行相同的验证打印出消息 .

    • 最后，如果工作正常，请逐个开始添加使用者线程，并查看在使用时是否开始暂停 .

    这应该可以让您确定问题所在 . 如果您能够使用单个线程使用所有内容，但不能使用多个线程，那么您的线程机制/池可能会出现问题 .

    回复于
  • 0

    检查磁盘上的 __consumer_offsets 分区大小 . 我们遇到了类似的问题，这是由于压缩错误造成的 . 这导致很长的再 balancer . 有关详细信息，请参阅https://issues.apache.org/jira/browse/KAFKA-5413（自kafka 0.10.2.2 / 0.11以来已解决）另一个选项是您的代理配置不正确，压缩已关闭， log.cleaner.enable （如果为false） . __consumer_offsets 是一个压缩的主题，因此如果禁用log.cleaner，它将不会被压缩并导致相同的症状 .

    回复于

相关问题