Kafka Java消费者被标记为群体死亡

Question

我正在使用Java使用者来使用来自主题（kafka版本0.10.0.1）的消息，如果我在docker容器之外运行它们，它可以正常工作。 但是，当我在docker容器中执行它们时，那​​些组被标记为dead with message

Marking the coordinator local.kafka.com:9092 (id: 2147483647 rack: null) dead for group my-group

我的消费者配置如下： -

metadata.max.age.ms = 300000
partition.assignment.strategy =[org.apache.kafka.clients.consumer.RangeAssignor]
reconnect.backoff.ms = 50
sasl.kerberos.ticket.renew.window.factor = 0.8
max.partition.fetch.bytes = 1048576
bootstrap.servers = [192.168.115.128:9092, 192.168.115.128:9093]
ssl.keystore.type = JKS
enable.auto.commit = true
sasl.mechanism = GSSAPI
interceptor.classes = null
exclude.internal.topics = true
ssl.truststore.password = null
client.id = consumer-1
ssl.endpoint.identification.algorithm = null
max.poll.records = 2147483647
check.crcs = true
request.timeout.ms = 40000
heartbeat.interval.ms = 3000
auto.commit.interval.ms = 5000
receive.buffer.bytes = 65536
ssl.truststore.type = JKS
ssl.truststore.location = null
ssl.keystore.password = null
fetch.min.bytes = 1
send.buffer.bytes = 131072
value.deserializer = class org.apache.kafka.common.serialization.StringDeserializer
group.id = my-group
retry.backoff.ms = 100
sasl.kerberos.kinit.cmd = /usr/bin/kinit
sasl.kerberos.service.name = null
sasl.kerberos.ticket.renew.jitter = 0.05
ssl.trustmanager.algorithm = PKIX
ssl.key.password = null
fetch.max.wait.ms = 500
sasl.kerberos.min.time.before.relogin = 60000
connections.max.idle.ms = 540000
session.timeout.ms = 30000
metrics.num.samples = 2
key.deserializer = class org.apache.kafka.common.serialization.StringDeserializer
ssl.protocol = TLS
ssl.provider = null
ssl.enabled.protocols = [TLSv1.2, TLSv1.1, TLSv1]
ssl.keystore.location = null
ssl.cipher.suites = null
security.protocol = PLAINTEXT
ssl.keymanager.algorithm = SunX509
metrics.sample.window.ms = 30000
auto.offset.reset = earliest

auto.commit属性设置为false ， poll.timeout设置为10000 。 有人可以指出我错在哪里吗？

Answer 1

它可能是您的advertised.listener（代理配置）或缺少在消费者的boostrap.servers第一次发现调用后返回消费者的错误URL。

这可能导致使用者对其余RPC调用使用不正确的URL。

Answer 2

简而言之，这意味着代理消费者之间的通信不活跃 - 在AbstractConsumer ，连接终止。

在Spark流中引用我的实际实现。

在应用程序中，我们的批次可以持续长达五分钟，因此我们在这些设置下调整了Kafka属性：

"heartbeat.interval.ms" -> "30000"
"session.timeout.ms" -> "90000"
"request.timeout.ms" -> "120000"

对于间隔，这是原始默认值的五倍，在文档中据说适合半分钟批次; 注意你必须考虑极长的批次（那些滞后的）。

另外两个比这更大，因为卡夫卡要求如此。

相关配置是：

spark.streaming.kafka.consumer.poll.ms

关于这个，将它设置得相当小，如10秒，可能是有意义的，理由是如果出现问题，那么设置有大量Spark任务重新尝试：

spark.task.maxFailures

将涵盖这一点。

我总是发现KafkaSpark的配置相当令人生畏，特别是在Kafka方面。

经验法则总是：使用默认值，并且仅在严格需要时才覆盖。

Answer 3

尝试将心跳间隔和会话超时设置为更高的数字。 当您的消费者花费更长时间发送心跳时，这将标志着协调员死亡。