Question

我有两个流：

[topicA]-> processingA-> [topicB]-> processingB-> [topicC]

登录到我的应用程序后，我注意到在将处理A的输出发送到主题B以及从主题B提取消息进行处理B之间，每次花费的时间都超过100毫秒（而不是150毫秒）。它可能不多，但会累积，最后，相当简单的处理级联将花费几乎第二个时间。

我可以调整卡夫卡以使这些延迟尽可能接近零吗？哪些配置参数会影响这些延迟？

我主要使用默认配置。会导致延迟的commit.interval.ms吗？我已经从更高的默认值更改了它...

StreamsConfig values: 
    application.id = app
    application.server = 
    bootstrap.servers = [localhost:9092]
    buffered.records.per.partition = 1000
    cache.max.bytes.buffering = 10485760
    client.id = 
    commit.interval.ms = 100
    connections.max.idle.ms = 540000
    default.deserialization.exception.handler = class org.apache.kafka.streams.errors.LogAndContinueExceptionHandler
    default.key.serde = class org.apache.kafka.common.serialization.Serdes$StringSerde
    default.production.exception.handler = class org.apache.kafka.streams.errors.DefaultProductionExceptionHandler
    default.timestamp.extractor = class org.apache.kafka.streams.processor.FailOnInvalidTimestamp
    default.value.serde = class org.apache.kafka.common.serialization.Serdes$StringSerde
    metadata.max.age.ms = 300000
    metric.reporters = []
    metrics.num.samples = 2
    metrics.recording.level = INFO
    metrics.sample.window.ms = 30000
    num.standby.replicas = 0
    num.stream.threads = 1
    partition.grouper = class org.apache.kafka.streams.processor.DefaultPartitionGrouper
    poll.ms = 100
    processing.guarantee = exactly_once
    receive.buffer.bytes = 32768
    reconnect.backoff.max.ms = 1000
    reconnect.backoff.ms = 50
    replication.factor = 1
    request.timeout.ms = 40000
    retries = 0
    retry.backoff.ms = 100
    rocksdb.config.setter = null
    security.protocol = PLAINTEXT
    send.buffer.bytes = 131072
    state.cleanup.delay.ms = 600000
    state.dir = /tmp/kafka-streams
    topology.optimization = none
    upgrade.from = null
    windowstore.changelog.additional.retention.ms = 86400000

Answer 1

在您的情况下，100到150ms似乎很正常，因为您已设置commit.interval.ms = 100（这也是processing.guarantee = fully_once的默认值）。对于处理一次，处理B仅读取已在[topicB]中提交的消息，而处理A仅在（至少）100毫秒之后提交。

无需重新架构系统，就可以调整commit.interval.ms以获得更好的延迟，但是如果降低该值，那么吞吐量也将降低。

请参见this post（流性能暗示），它描述了这种折衷。

Answer 2

您的消费者/处理方式是什么？

尝试减少这种情况，以便您的处理器快速消耗数据

，并且您的poll.ms设置为100毫秒也可以减少这种情况，看看是否有帮助。

调整卡夫卡流以提高速度

2 个答案: