Добиться параллелизма у потребителей Kafka

Question

Мы работаем над распараллеливанием нашего потребителя Kafka, чтобы обработать большее количество записей для обработки пиковой нагрузки.Один из способов, который мы уже предпринимаем, заключается в том, чтобы увеличить число потребителей в пределах одной и той же группы потребителей.

Наш Потребитель занимается синхронным вызовом API-интерфейса.Мы чувствовали, что выполнение этого вызова API асинхронно увеличит нагрузку на нашего потребителя.Следовательно, мы пытаемся сделать вызов API асинхронным, и в его ответе мы увеличиваем смещение.Однако мы видим проблему с этим:

Делая вызов API асинхронным, мы можем получить ответ для последней записи первым, и ни один из вызовов API предыдущей записи не был инициирован или не выполнен к тому времени.Если мы фиксируем смещение, как только получим ответ от последней записи, смещение будет изменено на последнюю запись.В то же время, если потребитель перезапустит или перебалансирует раздел, мы не получим никакой записи до последней записи, в которой мы зафиксировали смещение.При этом мы пропустим необработанные записи.

На данный момент у нас уже есть 25 разделов.Мы с нетерпением ждем, чтобы понять, если кто-то достиг параллелизма без увеличения или увеличения количества разделов, это единственный способ добиться параллелизма (чтобы избежать проблем смещения).

Answer 1

Вы должны посмотреть на обработку кафки batch. В двух словах: вы можете установить огромный batch.size с небольшим числом (или даже одним) partitions. Что касается целых batch из messages, потребляемых на стороне consumer (т. Е. В оперативной памяти) - вы можете распараллелить эти сообщения любым способом.

Я бы очень хотел поделиться ссылками, но их число катится через веб-дыру.

UPDATE

С точки зрения фиксации смещений - вы можете сделать это для всего batch. В целом, kafka не достигает целевых требований к производительности, злоупотребляя числом разделов, а полагается на обработку batch.

Я уже видел много проектов, страдающих от масштабирования разделов (вы можете увидеть проблемы позже, например, во время перебалансировки). Основное правило - сначала посмотрите на все доступные настройки batch.

Answer 2

Во-первых, вам необходимо отделить (если только сначала) чтение сообщений от обработки этих сообщений.Далее рассмотрим, сколько одновременных вызовов вы можете сделать с вашим API, поскольку нет смысла вызывать его чаще, чем сервер может обработать, асинхронно или нет.Если количество одновременных вызовов API примерно равно количеству разделов в вашей теме, то нет смысла вызывать API асинхронно.

Если число разделов значительно меньше максимального числа возможных одновременных вызовов API, у вас есть несколько вариантов.Вы можете попытаться сделать максимальное количество одновременных вызовов API с меньшим количеством потоков (по одному на каждого потребителя), вызвав асинхронный вызов API, как вы предлагаете, или вы можете создать больше потоков и выполнять ваши вызовы синхронно.Конечно, тогда вы столкнетесь с проблемой того, как ваши потребители могут передавать свою работу большему количеству общих потоков, но это именно то, что потоковые платформы исполнения, такие как Flink или Storm, делают для вас.Потоковые платформы (такие как Flink), которые предлагают обработку контрольных точек, также могут решить проблему обработки коммитов со смещением, когда сообщения обрабатываются не по порядку.Вы можете свернуть свою собственную обработку контрольных точек и свою собственную систему управления общими потоками, но вам действительно нужно избегать использования платформы потокового исполнения.

Наконец, у вас может быть больше потребителей, чем максимально возможных одновременных вызовов API, но тогда я бы посоветовал вам просто иметь меньше потребителей и разделять разделы, а не потоки вызовов API.

И, изКонечно, вы всегда можете изменить количество тематических разделов, чтобы сделать предпочитаемый вами вариант выше более подходящим.

В любом случае, чтобы ответить на ваш конкретный вопрос, вы хотите посмотреть, как Flink выполняет обработку контрольных точек с фиксацией смещения Kafka.Чтобы упростить (потому что я не думаю, что вы хотите бросить свой собственный), потребители kafka должны помнить не только смещения, которые они только что зафиксировали, но они должны держаться за предыдущие смещения, зафиксированные, и это определяет блок сообщений.течет хоть ваше приложение.Либо этот блок сообщений полностью обрабатывается полностью, либо необходимо откатить состояние обработки каждого потока до точки, где было обработано последнее сообщение в предыдущем блоке.Опять же, это значительное упрощение, но так оно и есть.