Ventajas y desventajas de usar apio frente a RQ [cerrado]

Actualmente estoy trabajando en un proyecto de Python que requiere implementar algunos trabajos en segundo plano (principalmente para envío de correo electrónico y actualizaciones de bases de datos en gran medida). Utilizo Redis para el intermediario de tareas. Entonces en este punto tengo dos candidatos: Apio y RQ . Tenía algo de experiencia con estas colas de trabajo, pero quiero pedirles que compartan su experiencia con el uso de estas herramientas. Entonces.

1. Qué pros y contras de usar apio vs.RQ.
2. Cualquier ejemplo de proyectos / tareas adecuados para usar Celery vs. RQ.

El apio parece bastante complicado pero es una solución con todas las funciones. En realidad, no creo que necesite todas estas funciones. Por otro lado, RQ es muy simple (por ejemplo, configuración, integración), pero parece que carece de algunas características útiles (por ejemplo, revocación de tareas, recarga automática de código)

Esto es lo que encontré al intentar responder exactamente a esta misma pregunta. Probablemente no sea completo e incluso puede ser inexacto en algunos puntos.

En resumen, RQ está diseñado para ser más simple en todos los aspectos. El apio está diseñado para ser más robusto. Ambos son excelentes.

• Documentación. La documentación de RQ es completa sin ser compleja y refleja la simplicidad general del proyecto: nunca se siente perdido o confundido. La documentación de Apio también es completa, pero espere volver a visitarla mucho cuando configure las cosas por primera vez, ya que hay demasiadas opciones para internalizar

• Supervisión. La flor de apio y el tablero de RQ son muy simples de configurar y le brindan al menos el 90% de toda la información que alguna vez desearía

• Soporte del corredor. El apio es el claro ganador, RQ solo es compatible con Redis. Esto significa menos documentación sobre "qué es un corredor", pero también significa que no puede cambiar de corredor en el futuro si Redis ya no funciona para usted. Por ejemplo, Instagram consideró tanto Redis como RabbitMQ con Celery . Esto es importante porque los diferentes corredores tienen diferentes garantías, por ejemplo, Redis no puede (al momento de escribir) garantizar al 100% que sus mensajes se entregan.

• Colas de prioridad. El modelo de cola de prioridad de RQ es simple y efectivo: los trabajadores leen las colas en orden . El apio requiere la activación de varios trabajadores para consumir desde diferentes colas. Ambos enfoques funcionan

• Soporte de SO. El apio es el claro ganador aquí, ya que RQ solo se ejecuta en sistemas que admiten, forkpor ejemplo, sistemas Unix

• Ayuda de idioma. RQ solo es compatible con Python, mientras que Celery le permite enviar tareas de un idioma a otro idioma

• API. El apio es extremadamente flexible (backends de múltiples resultados, buen formato de configuración, soporte de lienzo de flujo de trabajo) pero, naturalmente, este poder puede ser confuso. Por el contrario, la API de RQ es simple.

• Soporte de subtareas. El apio admite subtareas (por ejemplo, crear nuevas tareas desde dentro de las tareas existentes). No se si RQ lo hace

• Comunidad y estabilidad. El apio probablemente esté más establecido, pero ambos son proyectos activos. Al momento de escribir, Celery tiene ~ 3500 estrellas en Github, mientras que RQ tiene ~ 2000 y ambos proyectos muestran un desarrollo activo.

En mi opinión, el apio no es tan complejo como su reputación te puede hacer creer, pero tendrás que usar RTFM.

Entonces, ¿por qué alguien estaría dispuesto a cambiar el apio (posiblemente más completo) por RQ? En mi mente, todo se reduce a la simplicidad. Al restringirse a Redis + Unix, RQ proporciona documentación más simple, una base de código más simple y una API más simple. Esto significa que usted (y los posibles contribuyentes a su proyecto) pueden concentrarse en el código que le interesa, en lugar de tener que mantener los detalles sobre el sistema de cola de tareas en su memoria de trabajo. Todos tenemos un límite en la cantidad de detalles que podemos tener en nuestra cabeza a la vez, y al eliminar la necesidad de mantener los detalles de la cola de tareas allí, RQ permite volver al código que le interesa. Esa simplicidad se obtiene a expensas de características como colas de tareas entre idiomas, amplia compatibilidad con el sistema operativo, garantías de mensajes 100% confiables y capacidad para cambiar de intermediario de mensajes fácilmente.

El apio no es tan complicado. En esencia, realiza la configuración paso a paso desde tutorials, crea una celeryinstancia, decora su función y @celery.taskluego ejecuta la tarea con my_task.delay(*args, **kwargs).

A juzgar por su propia evaluación, parece que tiene que elegir entre carecer de características (clave) o tener un exceso de cosas. Esa no es una elección demasiado difícil en mi libro.