Avantages et inconvénients d'utiliser Celery vs RQ [fermé]

Actuellement, je travaille sur un projet python qui nécessite la mise en œuvre de certains travaux d'arrière-plan (principalement pour l'envoi d'e-mails et les mises à jour de la base de données). J'utilise Redis pour le courtier de tâches. Donc, sur ce point, j'ai deux candidats: Céleri et RQ . J'ai eu une certaine expérience avec ces files d'attente de travail, mais je veux vous demander de partager votre expérience de l'utilisation de ces outils. Alors.

1. Quels avantages et inconvénients utiliser Celery vs RQ.
2. Tous les exemples de projets / tâches appropriés pour utiliser Celery vs RQ.

Le céleri a l'air assez compliqué mais c'est une solution complète. En fait, je ne pense pas avoir besoin de toutes ces fonctionnalités. De l'autre côté, RQ est très simple (par exemple configuration, intégration), mais il semble qu'il lui manque certaines fonctionnalités utiles (par exemple, révocation de tâches, rechargement automatique du code)

Voici ce que j'ai trouvé en essayant de répondre exactement à la même question. Ce n'est probablement pas exhaustif et peut même être inexact sur certains points.

En bref, RQ est conçu pour être plus simple partout. Le céleri est conçu pour être plus robuste. Ils sont tous les deux excellents.

• Documentation. La documentation de RQ est complète sans être complexe et reflète la simplicité globale du projet - vous ne vous sentez jamais perdu ou confus. La documentation de Celery est également complète, mais attendez-vous à la revoir beaucoup lorsque vous configurez les choses pour la première fois car il y a trop d'options à internaliser

• Surveillance. La fleur de céleri et le tableau de bord RQ sont tous deux très simples à configurer et vous donnent au moins 90% de toutes les informations que vous souhaiteriez

• Soutien aux courtiers. Celery est clairement le gagnant, RQ ne prend en charge que Redis. Cela signifie moins de documentation sur «ce qu'est un courtier», mais signifie également que vous ne pourrez plus changer de courtier à l'avenir si Redis ne fonctionne plus pour vous. Par exemple, Instagram a considéré à la fois Redis et RabbitMQ avec du céleri . Ceci est important car différents courtiers ont des garanties différentes, par exemple Redis ne peut (au moment de la rédaction) garantir à 100% que vos messages sont livrés.

• Files d'attente prioritaires. Le modèle de file d'attente prioritaire de RQ est simple et efficace: les travailleurs lisent les files d'attente dans l'ordre . Le céleri nécessite la rotation de plusieurs travailleurs pour consommer à partir de différentes files d'attente. Les deux approches fonctionnent

• Prise en charge du système d'exploitation. Celery est clairement le gagnant ici, car RQ ne fonctionne que sur des systèmes prenant en charge forkpar exemple les systèmes Unix

• Support linguistique. RQ ne prend en charge que Python, tandis que Celery vous permet d'envoyer des tâches d'une langue à une autre langue

• API. Celery est extrêmement flexible (backends de résultats multiples, format de configuration agréable, support de canevas de workflow) mais naturellement cette puissance peut être déroutante. En revanche, l'API RQ est simple.

• Prise en charge des sous-tâches. Celery prend en charge les sous-tâches (par exemple, la création de nouvelles tâches à partir de tâches existantes). Je ne sais pas si RQ fait

• Communauté et stabilité. Le céleri est probablement plus établi, mais ce sont tous deux des projets actifs. Au moment d'écrire ces lignes, Celery a ~ 3500 étoiles sur Github tandis que RQ en a ~ 2000 et les deux projets montrent un développement actif

À mon avis, le céleri n'est pas aussi complexe que sa réputation pourrait vous le laisser croire, mais il vous faudra du RTFM.

Alors, pourquoi quelqu'un serait-il prêt à échanger le céleri (sans doute plus complet) contre RQ? Dans mon esprit, tout se résume à la simplicité. En se limitant à Redis + Unix, RQ fournit une documentation plus simple, une base de code plus simple et une API plus simple. Cela signifie que vous (et les contributeurs potentiels à votre projet) pouvez vous concentrer sur le code qui vous tient à cœur, au lieu d'avoir à garder des détails sur le système de file d'attente de tâches dans votre mémoire de travail. Nous avons tous une limite sur le nombre de détails qui peuvent être dans notre tête à la fois, et en supprimant le besoin de conserver les détails de la file d'attente de tâches là-dedans, RQ permet de revenir au code qui vous tient à cœur. Cette simplicité se fait au détriment de fonctionnalités telles que les files d'attente de tâches inter-langues, une large prise en charge du système d'exploitation, des garanties de messages fiables à 100% et la possibilité de changer facilement d'agent de messages.

Le céleri n'est pas si compliqué. À la base, vous effectuez la configuration étape par étape à partir de tutorials, créez une celeryinstance, décorez votre fonction avec, @celery.taskpuis exécutez la tâche avec my_task.delay(*args, **kwargs).

À en juger par votre propre évaluation, il semble que vous deviez choisir entre des caractéristiques (clés) manquantes ou un excès qui traîne. Ce n'est pas un choix trop difficile dans mon livre.