Наш брокер получает большое количество сообщений (около 15-30 МБ / с), и мы хотели бы принять эти сообщения в режиме реального времени и выполнить некоторую обработку.Каждое сообщение занимает несколько сотен килобайт.
Наши конвейеры обработки используют пулы потоков, поэтому мы хотели бы, чтобы записи, загружаемые из одного опроса, содержали большой пакет сообщений, так что наши пулы потоков не должнычасто занимайтесь обработкой небольших партий и рискуйте исчерпать потоки.В настоящее время мы контролируем это, изменяя конфигурации fetch.min.bytes, receive.buffer.bytes и max.partition.fetch.bytes нашего Kafka Consumer.
В настоящее время у нас нет возможности иметь единого потребителя, который мог бы демультиплексировать сообщения вразные трубопроводы.Таким образом, мы назначаем одного потребителя конвейеру, а каждому потребителю присваивается его собственная группа.
Проблема, с которой мы сталкиваемся, заключается в том, что, как только мы начинаем принимать несколько конвейеров, каждый из которых имеет своего потребителя в своей группе, наш коэффициент потребления начинает отставать от производителя.Что интересно, когда у нас работает один конвейер, у нас нет проблемы с задержкой.Наше приложение предназначено для анализа в реальном времени или почти в реальном времени, поэтому, в конечном счете, мы бы хотели, чтобы задержка была равна 0 или была как можно ближе к 0.
Каков наилучший способ настройки потребителей, напримерчто, когда они работают в разных группах одновременно, мы можем максимально уменьшить лаги?