max.poll.records 与 fetch.min.bytes 结合使用

Question

我正在阅读这个max.poll.records 如何影响消费者投票，以及 apache kafka docs，我仍然不确定是否fetch.min.bytes没有改变，默认为 1，kafka broker 是否有义务返回max.poll.records记录，如果有多少可用，或者没有？

根据我们的测试，即使某个主题中有足够的可用数据，它也不会总是返回那么多，并且文档中对该参数的解释及其纯粹的名称并不意味着它应该返回，但有些人倾向于相反的想法。我们还增加了可能防止这种情况发生的限制，例如message.max.bytes、max.message.bytes、max.partition.fetch.bytes和fetch.max.bytes（我们实际上不必增加，因为默认值相当高，50 MB），但这并没有改变任何事情。

我们也没有改变fetch.max.wait.ms，默认是500，也就是半秒，所以，如果fetch.min.bytes没有设置为大于1字节的东西，那么这个设置就生效了，即它决定了实际返回了多少条记录？这意味着如果max.poll.records返回的少于 then ，那是因为获取那么多需要 500 多毫秒？

Answer 1

这两种配置可能会令人困惑，虽然乍一看它们看起来很相似，但它们的工作方式却截然不同。

• fetch.min.bytes：该值是 Fetch Requests 的字段之一（min_bytes位于http://kafka.apache.org/protocol#The_Messages_Fetch）。代理使用此值来决定何时将 Fetch Response 发送回客户端。当代理收到 Fetch Request 时，fetch.max.wait.ms如果没有fetch.min.bytes可用的字节（例如，消费者位于日志的末尾或要消费的消息添加到小于该大小），它可以将其保留最多。

• max.poll.records：此设置仅在消费者中使用，永远不会发送给经纪人。在后台（异步），消费者客户端主动从代理获取记录并缓冲它们，以便在poll()被调用时返回已经获取的记录。顾名思义，这个设置控制最多poll()可以从消费者缓冲区返回多少条记录。