Avantages et inconvénients de l'utilisation du céleri par rapport au RQ

Question

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

1. Quels sont les avantages et les inconvénients d'utiliser le céleri par rapport au RQ.
2. Des exemples de projets/tâches adaptés à l'utilisation de Celery vs. RQ.

Celery 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 manque certaines fonctionnalités utiles (par exemple, la révocation des tâches, le rechargement automatique du code).

Answer 1

Voici ce que j'ai trouvé en essayant de répondre à cette 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 dans tous les domaines. Celery est conçu pour être plus robuste. Ils sont tous deux excellents.

• Documentation. Documentation du RQ est complet sans être complexe, et reflète la simplicité globale du projet - vous ne vous sentez jamais perdu ou confus. Documentation du céleri est également complet, mais attendez-vous à y revenir souvent lors de la mise en place initiale, car il y a trop d'options à assimiler.

• Surveillance. Fleur de céleri y el Tableau de bord RQ sont tous deux très simples à configurer et vous donnent au moins 90 % de toutes les informations dont vous pourriez avoir besoin.

• Soutien aux courtiers. Celery est le vainqueur incontesté, RQ ne prend en charge que Redis. Cela signifie moins de documentation sur "ce qu'est un courtier", mais aussi que vous ne pourrez pas changer de courtier à l'avenir si Redis ne vous convient plus. Par exemple, Instagram a considéré à la fois Redis et RabbitMQ avec Celery . Ceci est important car les différents brokers ont des garanties différentes, par exemple Redis ne peut pas (au moment de la rédaction du présent document) garantissent à 100 % la livraison de vos messages.

• Les files d'attente prioritaires. Le modèle de file d'attente prioritaire de RQs est simple et efficace - les travailleurs lisent les files d'attente dans l'ordre . Celery nécessite la mise en place de plusieurs travailleurs pour consommer à partir de différentes files d'attente. Les deux approches fonctionnent

• Support OS. Celery est le grand vainqueur dans ce domaine, car RQ ne fonctionne que sur les systèmes qui prennent en charge les éléments suivants fork Par 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'un langage vers un autre langage.

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

• Soutien aux 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 le fait

• Communauté et stabilité. Celery est probablement plus établi, mais ce sont tous deux des projets actifs. Au moment de la rédaction de cet article, Celery compte environ 3 500 étoiles sur Github, tandis que RQ en compte environ 2 000, et les deux projets sont en développement actif.

À mon avis, le céleri n'est pas aussi complexe que sa réputation pourrait le laisser croire, mais vous devrez faire la démarche RTFM.

Alors, pourquoi quelqu'un serait-il prêt à échanger le Celery (sans doute plus complet) contre RQ ? À mon avis, 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 intéresse, au lieu de devoir garder les détails du système de file d'attente des tâches dans votre mémoire de travail. Nous avons tous une limite sur le nombre de détails que nous pouvons avoir en tête en même temps, et en supprimant la nécessité de garder les détails de la file d'attente des tâches, RQ permet de revenir au code qui vous intéresse. Cette simplicité se fait au détriment de fonctionnalités telles que les files d'attente de tâches inter-langues, le support d'un grand nombre de systèmes d'exploitation, des garanties de messages 100% fiables et la possibilité de changer facilement de courtier de messages.

Answer 2

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

À en juger par votre propre évaluation, il semble que vous deviez choisir entre l'absence de fonctionnalités (essentielles) et la présence d'un surplus. Ce n'est pas un choix trop difficile à mon avis.