Вы правы, что в документации указано, что потребители Kafka не являются поточно-ориентированными.Однако в нем также говорится, что вы должны запускать потребителей в отдельных потоках , а не в процессах.Это совсем другое.Смотрите здесь ответ с более подробной информацией, ориентированной на Java / JVM: https://stackoverflow.com/a/15795159/236528
В общем, у вас может быть столько потребителей, сколько вы хотите по теме Kafka.Некоторые из них могут иметь общий идентификатор группы , и в этом случае все разделы для этой темы будут распределены по всем активным потребителям в любой момент времени.
Там гораздо больше подробностейJavadoc для потребителя Kafka, связанный в нижней части этого ответа, но я скопировал две модели потока / потребителя, предложенные в документации ниже.
1.Один потребитель на поток
Простой способ - предоставить каждому потоку свой собственный экземпляр клиента.Вот плюсы и минусы этого подхода:
PRO: Это самый простой способ реализации
PRO: Это часто самый быстрыймежпотоковая координация не требуется
PRO: Это позволяет очень легко реализовать обработку заказов для каждого раздела (каждый поток обрабатывает сообщения только в том порядке, в котором он получаетих).
CON: Чем больше потребителей, тем больше TCP-соединений с кластером (по одному на поток).В общем, Kafka очень эффективно обрабатывает соединения, поэтому это, как правило, небольшая стоимость.
CON: Несколько потребителей означают, что на сервер отправляется больше запросов и немного меньше пакетных данных, что может привести к некоторому падению пропускной способности ввода-вывода.
CON: Количество общих потоков во всех процессах будет ограничено общим числом разделов.
2.Отключение потребления и обработки
Другая альтернатива - иметь один или несколько потоков-потребителей, которые выполняют все потребление данных, и передавать экземпляры ConsumerRecords в очередь блокировки, потребляемую пулом потоков процессора, которые фактически обрабатывают обработку записей.,Эта опция также имеет свои плюсы и минусы:
PRO: Эта опция позволяет независимо масштабировать количество потребителей и процессоров.Это позволяет иметь одного потребителя, который подает много потоков процессора, избегая каких-либо ограничений на разделы.
CON: Гарантия порядка на процессорах требует особой осторожности, поскольку потоки будут независимо выполнятьболее ранняя порция данных может фактически быть обработана после более поздней порции данных просто из-за удачи времени выполнения потока.Для обработки, которая не имеет требований к оформлению заказа, это не проблема.
CON: Ручная фиксация позиции становится все труднее, поскольку требуется, чтобы все потоки координировали свою работу, чтобы гарантировать, что обработка для этого раздела завершена.Есть много возможных вариантов этого подхода.Например, каждый поток процессора может иметь свою собственную очередь, а потоки-потребители могут хэшировать эти очереди, используя TopicPartition, чтобы обеспечить потребление по порядку и упростить фиксацию.
По моему опыту, вариант № 1лучше всего начать, и вы можете перейти на второй вариант, только если он вам действительно нужен.Вариант № 2 - единственный способ извлечь максимальную производительность от потребителя кафки, но его реализация более сложна.Итак, сначала попробуйте вариант № 1 и посмотрите, достаточно ли он подходит для вашего конкретного случая использования.
Полный Javadoc доступен по этой ссылке: https://kafka.apache.org/23/javadoc/index.html?org/apache/kafka/clients/producer/KafkaProducer.html