Esto es lo que he encontrado al tratar de responder exactamente a esta misma pregunta. Probablemente no sea exhaustivo e incluso puede ser inexacto en algunos puntos.
En resumen, RQ está diseñado para ser más simple en todos los sentidos. 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 Celery también es completa, pero espere volver a visitarla mucho cuando esté configurando las cosas por primera vez, ya que hay demasiadas opciones para internalizar
-
Vigilancia. Celery's Flower y el panel de RQ son muy fáciles de configurar y le brindan al menos el 90% de toda la información que desearía
-
Soporte de corredores. El apio es el claro ganador, RQ solo es compatible con Redis. Esto significa menos documentación sobre "qué es un bróker", pero también significa que no puede cambiar de bróker en el futuro si Redis ya no funciona para usted. Por ejemplo, Instagram consideró Redis y RabbitMQ con Celery. Esto es importante porque diferentes corredores tienen diferentes garantías, p. Redis no puede (al momento de escribir) garantiza el 100% de que sus mensajes se entregarán.
-
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 hacer girar a varios trabajadores para consumir de diferentes colas. Ambos enfoques funcionan
-
Soporte del sistema operativo. El apio es el claro ganador aquí, ya que RQ solo se ejecuta en sistemas compatibles con
forkp.ej. 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. Celery es extremadamente flexible (múltiples backends de 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 RQ es simple.
-
Soporte de subtareas. Celery admite subtareas (p. ej., crear tareas nuevas a partir de tareas existentes). No sé 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, Celery no es tan complejo como su reputación podría hacerte creer, pero tendrás que usar RTFM.
Entonces, ¿por qué alguien estaría dispuesto a cambiar el Celery (posiblemente más completo) por RQ? En mi mente, todo se reduce a la simplicidad. Al restringirse a Redis+Unix, RQ proporciona una 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 colaboradores de su proyecto) pueden concentrarse en el código que les interesa, en lugar de tener que mantener 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 la 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 produce a expensas de funciones como colas de tareas entre idiomas, amplia compatibilidad con sistemas operativos, garantías de mensajes 100 % confiables y la capacidad de cambiar fácilmente de intermediario de mensajes.
