迁移到 Kafka 流 2.6

时间:2021-01-28 16:42:31

标签: apache-kafka apache-kafka-streams

我的问题是:从 v2.3 -> v2.6 迁移(离线)现有的 Kafka 流应用程序时,您是否需要更改配置中的任何内容?

Kafka Brokers 在 Kafka 服务器 2.6 上运行

我们的 Kafka Streams 应用程序在将 Kafka Streams 库从 v2.3 升级到 v2.6 后似乎没有其他变化。我们只是使用新的 kafka 流 2.6 库构建应用程序,没有其他更改。

我希望它的行为与 2.3 库相同,但事实并非如此。

我们正在使用来自 30 个分区的主题的 3 个 pod 的消息,然后我们执行 .mapValues(),每条消息可能需要大约 10-500 毫秒,这很多但没什么了不起的。我们试图通过使用以下参数来让它工作,但我们没有成功。

session.timeout.ms=30000
max.poll.records=20
num.stream.threads=10

一段时间(10 - 15)之后,消费者组可能会稳定几秒钟,但只有 5 或 6 名成员,然后显然又开始重新平衡。 我们目前不使用 kafka 流静态成员资格。首先,我们想让它稳定。

消费者配置值是:

    allow.auto.create.topics = true
    auto.commit.interval.ms = 5000
    auto.offset.reset = latest
    bootstrap.servers = [pp5-kafka-acc-headless.pp5-acc:9092]
    check.crcs = true
    client.dns.lookup = default
    client.id = HeadEndPushServiceLowNetinium-211cbe23-50b2-4942-95f1-b93567d145c2-StreamThread-8-consumer
    client.rack = 
    connections.max.idle.ms = 540000
    default.api.timeout.ms = 60000
    enable.auto.commit = false
    exclude.internal.topics = true
    fetch.max.bytes = 200000
    fetch.max.wait.ms = 500
    fetch.min.bytes = 1
    group.id = HeadEndPushServiceLowNetinium
    group.instance.id = null
    heartbeat.interval.ms = 3000
    interceptor.classes = []
    internal.leave.group.on.close = false
    isolation.level = read_uncommitted
    key.deserializer = class org.apache.kafka.common.serialization.ByteArrayDeserializer
    max.partition.fetch.bytes = 1048576
    max.poll.interval.ms = 300000
    max.poll.records = 5
    metadata.max.age.ms = 300000
    metric.reporters = []
    metrics.num.samples = 2
    metrics.recording.level = INFO
    metrics.sample.window.ms = 30000
    partition.assignment.strategy = [org.apache.kafka.streams.processor.internals.StreamsPartitionAssignor]
    receive.buffer.bytes = 65536
    reconnect.backoff.max.ms = 1000
    reconnect.backoff.ms = 50
    request.timeout.ms = 30000
    retry.backoff.ms = 100
    sasl.client.callback.handler.class = null
    sasl.jaas.config = null
    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.login.callback.handler.class = null
    sasl.login.class = null
    sasl.login.refresh.buffer.seconds = 300
    sasl.login.refresh.min.period.seconds = 60
    sasl.login.refresh.window.factor = 0.8
    sasl.login.refresh.window.jitter = 0.05
    sasl.mechanism = GSSAPI
    security.protocol = PLAINTEXT
    send.buffer.bytes = 131072
    session.timeout.ms = 30000
    ssl.cipher.suites = null
    ssl.enabled.protocols = [TLSv1.2, TLSv1.1, TLSv1]
    ssl.endpoint.identification.algorithm = https
    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 = null
    ssl.truststore.password = null
    ssl.truststore.type = JKS
    value.deserializer = class org.apache.kafka.common.serialization.ByteArrayDeserializer

使用 v2.3,我们可以轻松地每秒处理 800 条消息。使用 v2.6,我们每秒只能处理 50 条消息,因为它在不断地重新平衡。

更新:在设置 session.timeout.ms = 180000(3 分钟)并引入 group.instance.id(=POD_NAME)后,应用程序似乎变得更加稳定,总共有 30 个线程。 有时删除 Pod 后只需 2 分钟即可稳定。有时可能需要 10 分钟才能稳定下来。但是最后好像稳定了,再平衡的时候吞吐量比以前高了。

0 个答案:

没有答案