top hashtags architecture message-queue apache-kafka

architecture - top - building hashtags



¿Apache Kafka es apropiado para usar como una cola de tareas? (4)

Kafka divide los mensajes entrantes en particiones, de acuerdo con la partición asignada por el productor. Los mensajes de las particiones son consumidos por los consumidores en diferentes grupos de consumidores.

Esta arquitectura me hace desconfiar de usar Kafka como una cola de trabajo / tarea, porque tengo que especificar la partición en el momento de la producción, lo que limita indirectamente qué consumidores pueden trabajar en ella porque una partición se envía a un solo consumidor en un grupo de consumidores. Preferiría no especificar la partición antes de tiempo, de modo que el consumidor que esté disponible para realizar esa tarea pueda hacerlo. ¿Hay una manera de estructurar particiones / productores en una arquitectura Kafka donde las tareas puedan ser realizadas por el siguiente consumidor disponible, sin tener que dividir el trabajo por adelantado al elegir una partición cuando se produce el trabajo?

Usar solo una partición para este tema pondría todas las tareas en la misma cola, pero luego el número de consumidores se limita a 1 por grupo de consumidores, por lo que cada consumidor tendría que estar en un grupo diferente. Sin embargo, toda la tarea se distribuye a cada grupo de consumidores, que no es el tipo de cola de trabajo que estoy buscando.

¿Apache Kafka es apropiado para usar como una cola de tareas?


Existe mucha discusión en este tema que gira en torno al orden de ejecución de las tareas en una cola de trabajo o tarea. Propondría la idea de que el orden de ejecución no debería ser una característica de una cola de trabajo.

Una cola de trabajo es un medio para controlar el uso de recursos mediante la aplicación de un número controlable de subprocesos de trabajo para completar tareas distintas. Hacer cumplir una orden de procesamiento en tareas en una cola significa que también está haciendo cumplir una orden de finalización en tareas en la cola, lo que efectivamente significa que las tareas en la cola siempre se procesarán secuencialmente y la siguiente tarea se procesará solo después del FIN de la tarea anterior. Esto efectivamente significa que tiene una sola cola de tareas de subproceso.

Si el orden de ejecución es importante en algunas de sus tareas, esas tareas deben agregar la siguiente tarea en la secuencia a la cola de trabajo una vez finalizada. O eso o usted admite un tipo de trabajo secuencial que cuando se procesa en realidad procesa una lista de trabajos secuencialmente en un trabajador.

De ninguna manera debería la cola de trabajo ordenar realmente ninguno de sus trabajos: el siguiente procesador disponible siempre debe realizar la siguiente tarea sin tener en cuenta lo que ocurrió antes o después de que finalice la tarea.

También pensaba en kafka como base para una cola de trabajo, pero cuanto más lo investigo, menos parece la plataforma deseada.

Veo que se utiliza principalmente como un medio para sincronizar recursos dispares y no tanto como un medio para ejecutar solicitudes de trabajo dispares.

Otra área que creo que es importante en una cola de trabajo es el soporte de una priorización de tareas. Por ejemplo, si tengo 20 tareas en la cola, y una nueva tarea llega con una prioridad más alta, quiero que esa tarea salte al principio de la línea para que sea recogida por el siguiente trabajador disponible. Kafka no lo permitiría.


Hay dos obstáculos principales al tratar de usar Kafka como una cola de mensajes:

  1. como se describe en la respuesta de Ofer , solo puede consumir una sola partición de un solo consumidor, y el orden de procesamiento está garantizado solo dentro de una partición. Entonces, si no puede distribuir las tareas de manera justa en las particiones, esto podría ser un problema.

  2. de forma predeterminada, solo puede confirmar el procesamiento de todos los mensajes hasta un punto determinado (desplazamiento). A diferencia de las colas de mensajes tradicionales, no puede realizar un reconocimiento selectivo y, en caso de error, reintentos selectivos. Esta dirección se puede realizar mediante el uso de kmq , que agrega la capacidad de acks individuales con la ayuda de un tema adicional (descargo de responsabilidad: soy el autor de kmq).

Por supuesto, RabbitMQ es una alternativa, pero también ofrece diferentes (menores) garantías de rendimiento y replicación. En resumen, los documentos de RabbitMQ indican que el intermediario no es tolerante a la partición . Vea también nuestra comparación de colas de mensajes con replicación de datos, mqperf .


Usar Kafka para una cola de tareas es una mala idea. En su lugar, use RabbitMQ, lo hace mucho mejor y de manera más elegante.

Aunque puede usar Kafka para una cola de tareas, obtendrá algunos problemas: Kafka no permite el consumo de una sola partición por parte de muchos consumidores (por diseño), por lo que si, por ejemplo, una sola partición se llena con muchas tareas y el consumidor que posee la partición está ocupada, las tareas en esa partición obtendrán "inanición". Esto también significa que el orden de consumo de las tareas en el tema no será idéntico al orden en el que se produjeron las tareas, lo que podría causar serios problemas si las tareas se deben consumir en un orden específico (en Kafka para lograrlo por completo). tenga solo un consumidor y una partición, lo que significa que el consumo en serie será por un solo nodo. Si tiene varios consumidores y varias particiones, no se garantizará el orden de consumo de tareas en el nivel de tema).

De hecho, los temas de Kafka no son colas en la informática. Cola significa Primero en Primero en salir, esto no es lo que obtienes en Kafka en el nivel de tema.

Otro problema es que es difícil cambiar el número de particiones dinámicamente. Agregar o eliminar nuevos trabajadores debe ser dinámico. Si desea asegurarse de que los nuevos trabajadores obtendrán tareas en Kakfa, deberá establecer el número de partición en el máximo posible de trabajadores. Esto no es lo suficientemente elegante.

Así que la línea de fondo: use RabbitMQ u otras colas en su lugar.

Habiendo dicho todo eso, Samza (por linkedin) está utilizando kafka como una especie de cola de tareas basada en transmisión: Samza


Yo diría que esto depende de la escala. ¿Cuántas tareas anticipas en una unidad de tiempo?

Lo que usted describe como su objetivo final es básicamente cómo funciona Kafka de forma predeterminada. Cuando genera mensajes, la opción predeterminada (la más utilizada) es utilizar un particionador aleatorio, que elige las particiones de forma por turnos, manteniendo las particiones uniformemente utilizadas (por lo que es posible evitar la especificación de una partición).
El propósito principal de las particiones es paralelizar el procesamiento de mensajes, por lo que debe usarlo de esa manera.
Otra "cosa" comúnmente utilizada para la cual se usan las particiones es asegurar que ciertos mensajes se consuman en el mismo orden en que se producen (luego se especifica la clave de partición de tal manera que todos esos mensajes terminen en la misma partición. Por ejemplo, use userId como clave aseguraría que todos los usuarios sean procesados ​​de tal manera).