Подходит ли Apache Kafka для использования в качестве неупорядоченной очереди задач?

Kafka разбивает входящие сообщения на разделы в соответствии с разделом, назначенным производителем. Сообщения из разделов затем потребляются потребителями в разных группах потребителей.

Эта архитектура заставляет меня опасаться использования Kafka как очереди работы/задачи, потому что я должен указать раздел во время производства, что косвенно ограничивает, какие потребители могут работать над ним, потому что раздел отправляется только одному потребителю в потребительской группы. Я бы предпочел не указывать раздел раньше времени, так что любой потребитель, доступный для выполнения этой задачи, может это сделать. Есть ли способ структурировать разделы/производители в архитектуре Kafka, где задачи могут быть вытащены следующим доступным потребителем, без необходимости разделить работу заблаговременно, выбрав раздел при создании работы?

Использование только одного раздела для этой темы поставит все задачи в одну очередь, но тогда количество потребителей ограничено 1 на группу потребителей, поэтому каждый потребитель должен быть в другой группе. Затем вся задача распределяется по каждой группе потребителей, но это не та рабочая очередь, которую я ищу.

Является ли Apache Kafka подходящим для использования в качестве очереди задач?

Ответ 1

Использование Kafka для очереди задач - плохая идея. Вместо этого используйте RabbitMQ, он делает это намного лучше и элегантнее.

Хотя вы можете использовать Kafka для очереди задач - у вас возникнут некоторые проблемы: Kafka не позволяет потреблять один раздел многим потребителям (по замыслу), поэтому, если, например, один раздел заполнен многими задачами, а потребитель - владельцем раздел занят, задачи в этом разделе получат "голодание". Это также означает, что порядок потребления задач в теме не будет идентичен порядку, в котором были созданы задачи, что может вызвать серьезные проблемы, если задачи нужно использовать в определенном порядке (в Kafka для полного достижения этого необходимо иметь только одного потребителя и один раздел - это означает последовательное потребление только одним узлом. Если у вас есть несколько потребителей и несколько разделов, порядок потребления задач не будет гарантирован на уровне темы).

На самом деле - темы Кафки не являются очередями в информатике. Очередь означает "первым пришел - первым вышел" - это не то, что вы получаете в Kafka на уровне темы.

Другая проблема заключается в том, что трудно изменить количество разделов динамически. Добавление или удаление новых работников должно быть динамичным. Если вы хотите убедиться, что новые работники получат задания в Kakfa, вам нужно установить максимально возможное число разделов. Это не достаточно элегантно.

Итак, суть - используйте RabbitMQ или другие очереди.

Сказав все это - Samza (от имени) использует kafka как своего рода очередь задач на основе потоковой передачи: Samza

Изменение: соображения масштаба: я забыл упомянуть, что Kakfa является инструментом больших данных/большого масштаба. Если у вас очень высокий уровень занятости, то Кафка может быть хорошим вариантом для вас. Если мы говорим о меньших масштабах (скажем, до нескольких десятков/сотен рабочих мест в секунду), то снова Kafka - плохой выбор по сравнению с RabbitMQ.

Ответ 2

Я бы сказал, что это зависит от масштаба. Сколько задач вы ожидаете за единицу времени?

То, что вы описываете как свою конечную цель, в основном состоит в том, как работает Kafka по умолчанию. Когда вы создаете сообщения, опция по умолчанию (наиболее широко используется) заключается в использовании произвольного разделителя, который выбирает разделы в циклическом режиме, поддерживая разделение равномерно (таким образом, можно избежать указания раздела). Основная цель разделов - распараллеливать обработку сообщений, поэтому вы должны использовать их таким образом.
Другие обычно используемые "вещи", для которых используются разделы, гарантируют, что некоторые сообщения будут потребляться в том же порядке, в каком они созданы (тогда вы указываете ключ разделения таким образом, чтобы все такие сообщения попадали в один и тот же раздел. Например, используя userId в качестве ключа обеспечит, чтобы все пользователи обрабатывались таким образом).

Ответ 3

Есть два основных препятствия при попытке использовать Kafka в качестве очереди сообщений:

как описано в Ofer answer, вы можете потреблять только один раздел от одного потребителя, а порядок обработки гарантируется только внутри раздела. Поэтому, если вы не можете распределить задачи довольно по разделам, это может быть проблемой
по умолчанию вы можете только подтвердить обработку всех сообщений до заданной точки (смещение). В отличие от традиционных очередей сообщений, вы не можете делать выборочное подтверждение, а в случае сбоя - выборочные повторы. Это может быть адрес с помощью kmq, который добавляет отдельные возможности acks с помощью дополнительной темы (отказ от ответственности: я автор кмк).

RabbitMQ - это, конечно, альтернатива, но она также дает разные (более низкие) характеристики производительности и репликации. Короче говоря, RabbitMQ docs заявляет, что брокер не терпимо к разделу. См. Также наше сравнение очередей сообщений с репликацией данных, mqperf.

Ответ 4

В этой теме много дискуссий, посвященных порядку выполнения задач в работе или очереди задач. Я бы выдвинул идею о том, что порядок выполнения не должен быть особенностью рабочей очереди.

Рабочая очередь - это средство управления использованием ресурсов путем применения контролируемого количества рабочих потоков для выполнения отдельных задач. Применение порядка обработки для задач в очереди означает, что вы также применяете порядок выполнения для задач в очереди, что фактически означает, что задачи в очереди всегда будут обрабатываться последовательно, а следующая задача обрабатывается только после КОНЦА предыдущей задачи. Это фактически означает, что у вас есть однопоточная очередь задач.

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

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

Я также рассматривал kafka как основу для рабочей очереди, но чем больше я исследую ее, тем меньше она выглядит как нужная платформа.

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

Другая область, которая, на мой взгляд, важна в рабочей очереди, - это поддержка приоритизации задач. Например, если у меня в очереди 20 задач, и прибывает новая задача с более высоким приоритетом, я хочу, чтобы эта задача перешла к началу строки, которая будет найдена следующим доступным работником. Кафка не допустит этого.