¿Apache Kafka es apropiado para su uso como cola de tareas?

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

Lo que describes como tu objetivo final es básicamente cómo funciona Kafka por defecto. Cuando produce mensajes, la opción predeterminada (la más utilizada) es usar el particionador aleatorio, que elige particiones en la forma de round robin, manteniendo las particiones uniformemente utilizadas (por lo que es posible evitar especificar una partición).
El propósito principal de las particiones es paralelizar el procesamiento de mensajes, por lo que deberías usarlo de esa manera.
Otra "cosa" comúnmente utilizada para la que 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 estos mensajes terminen en la misma partición. Por ejemplo, usar userId como clave aseguraría que todos los usuarios se procesen de esa manera).

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

1. Como se describe en 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 entre las particiones, esto podría ser un problema

2. De forma predeterminada, solo puede reconocer el procesamiento de todos los mensajes hasta un punto determinado (desplazamiento). A diferencia de lo tradicional colas de mensajes, no se puede hacer reconocimiento selectivo y en caso de fallo, reintentos selectivos. Esto se puede abordar usando kmq, que agrega la capacidad individual de acks con la ayuda de un tema adicional (descargo de responsabilidad: Soy el autor de kmq).

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

Hay 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. Yo plantearía la idea de que el orden de ejecución no debe 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 las tareas de una cola significa que también está haciendo cumplir una orden de finalización en las tareas de la cola que efectivamente significa que las tareas en la cola siempre se procesarán secuencialmente con la siguiente tarea procesándose solo después del FINAL de la tarea anterior. Esto significa efectivamente que tiene una sola cola de tareas con subprocesos.

Si el orden de ejecución es importante en algunas de sus tareas, entonces esas tareas deben agregar la siguiente tarea en la secuencia a la cola de trabajo al completarla. Eso o admite un tipo de trabajo secuencial que, cuando se procesa, procesa una lista de trabajos secuencialmente en un trabajador.

De ninguna manera la cola de trabajo debería ordenar su trabajo - el siguiente procesador disponible siempre debería tomar la siguiente tarea sin importar lo que haya ocurrido antes o después de que la tarea se complete.

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

Lo veo principalmente como un medio de sincronizar recursos dispares y no tanto como un medio de ejecución de 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 inicio de la línea para que la recoja el siguiente trabajador disponible. Kafka no lo permitiría.