Я читаю этот вопрос Увеличьте количество сообщений, прочитанных потребителем Kafka в одном опросе , и я хотел бы знать, прав ли я относительно того, насколько на самом деле вводит в заблуждение и бесполезен этот вопрос, учитывая количество полученных голосов и общепринятая мудрость, которую он способствовал формированию. Прежде всего, следует стремиться минимизировать общее время, затрачиваемое на проведение опросов, а не максимизировать количество записей, возвращаемых в каждом опросе. Конечно, люди ставят последнюю цель, имея в виду первую, не задумываясь о том, насколько они коррелированы. Но даже если мы принимаем последнюю цель как легитимную саму по себе, вопрос заключается в том, как параметры, которые управляют извлечением записей из посредника в локальный буфер, фактически позволяют выполнить эту цель, чтобы иметь возможность опрашивать большее количество записей каждый раз из локального буфера. Хотя мы увеличили значения max.partition.fetch.bytes, message.max.bytes и max.message.bytes со значения по умолчанию 1 МБ до 8 МБ, это не привело к значительному увеличению пропускной способности, поэтому мы могли заметить какие-либо различия в отношении сколько раз мы опрашиваем меньше чем max.poll.records. Это были столь же редкие случаи после того, как мы увеличили эти лимиты, как и раньше, но они не прекратились. Все, что было после того, как мы увеличили max.poll.records со значения по умолчанию 500 до 3000. Я также подвергаю сомнению причины этого изменения, а также общепринятую мудрость, которая была установлена из-за ранее упомянутого вопроса, который говорит, что если вы увеличите max. poll.records, вы должны также увеличить max.partition.fetch.bytes.
Позвольте мне просто добавить, что я не полностью понял асинхронность и паралелизм, связанные с пользовательским API-интерфейсом kafka, и роль параметра max.poll.records, до того как я получил ответ от Микаэля Мейсона, в этом смежном вопросе max.poll.records в сочетании с fetch.min.bytes . Самым важным для меня пониманием этого потока является то, что количество записей, фактически возвращаемых методом опроса, не ограничено параметрами, которые контролируют выборку записей из посредника. У нас по умолчанию были 1 МБ message.max.bytes и max.message.bytes, и мы по-прежнему могли опрашивать большую часть времени более чем 3 МБ данных (так как каждая запись была немного больше 1 КБ), потому что эти записи выбирались несколькими пакетами из брокер, и доставлен в одном опросе. Таким образом, остается вопрос, будет ли достаточное увеличение fetch.min.bytes (в нашем случае более 3 МБ) фактически вызвать проблему, чтобы опрос никогда не возвращал меньше ожидаемого max.poll.records.