【问题标题】:Why does my Kafka consumer poll so quickly?为什么我的 Kafka 消费者投票这么快?
【发布时间】:2021-03-28 15:34:33
【问题描述】:

我的 Kafka 消费者的轮询速度比我预期的要快。我可以更改一些配置以使其在fetch.max.wait.ms 中一直等待吗?

我将 fetch.max.wait.ms 设置为某个秒数 (5)。我将fetch.min.bytes 设置为一些大量字节(99,988,800)。

我阅读了文档(但可能遗漏了一些东西):

https://kafka.apache.org/documentation/

  • fetch.min.bytes

  • 服务器应为获取请求返回的最小数据量。如果可用数据不足,则请求将在响应请求之前等待累积那么多数据。 1 字节的默认设置意味着只要有一个字节的数据可用或获取请求超时等待数据到达,就会响应获取请求。将此设置为大于 1 的值将导致服务器等待大量数据累积,这可以稍微提高服务器吞吐量,但会增加一些延迟。

  • fetch.max.wait.ms

  • 如果没有足够的数据立即满足 fetch.min.bytes 给出的要求,服务器将在响应 fetch 请求之前阻塞的最长时间。

fetch.max.wait.ms=5000,
fetch.min.bytes=99988800

根据我的配置选项和数据集,我希望对 poll 的调用在返回任何记录之前总是阻塞 5 秒。

相反,对poll 的调用有时会在不到一秒的时间内解决,并且总是有一些少量记录。

这是一个示例运行的输出:

// send 100 records
// doesn't matter how

// timestamp -> records received
// (date, hour and minute are not shown, just the relevant seconds.millis)

32.475 -> 10
33.392 -> 12
34.116 -> 16
37.477 -> 16
38.395 -> 18
39.118 -> 17
42.479 -> 7
43.397 -> 4

没有延迟真的接近5s。

【问题讨论】:

  • 我不确定,我们正在使用它,它对我们有用。所以我会确定,如果你的设置被放在首位?私有 Map jsonConsumerConfigs() { Map props = new HashMap(); props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 200); props.put(ConsumerConfig.FETCH_MAX_WAIT_MS_CONFIG, 10000); props.put(ConsumerConfig.FETCH_MIN_BYTES_CONFIG, 2147483647);返回道具; }
  • @xerige2 你能让这个为 spring-kafka 工作吗?还有 Martin 为 spring-kafka 或 kafka 消费类设置了配置?

标签: java apache-kafka kafka-consumer-api spring-kafka


【解决方案1】:

对于fetch.max.wait.ms=5000 属性,您说过:“即使没有足够的数据来获取,也不要等待超过 5 秒”。您没有指定执行轮询之前的最小秒数。您可以通过启动 2 个 kafka 消费者来测试此行为,并在其中一个中设置 fetch.max.wait.ms=20000 并在另一个中保留默认值。您会看到,在使用默认设置的消费者中,您几乎会立即收到消息,而在使用 fetch.max.wait.ms=20000 的消费者中,您将不得不稍等片刻。我在我的机器上尝试了设置fetch.max.wait.ms=20000,有时接收记录需要15秒,有时需要10秒等,但从来没有超过20秒。

【讨论】:

    【解决方案2】:

    您还需要调整 max.partition.fetch.bytes、message.max.bytes 和 max.message.bytes。 如果每条记录的大小在 100KB 左右,则 10 条记录将触发投递。这可能就是您在案例中看到的情况。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2020-09-13
      • 1970-01-01
      • 2016-05-25
      • 1970-01-01
      • 2015-09-06
      • 2016-10-22
      • 1970-01-01
      相关资源
      最近更新 更多