Avantages et inconvénients D'utiliser le céleri vs. RQ [fermé]

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

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

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

• La 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 voudriez

• Soutien courtier. Céleri est le gagnant clair, RQ ne supporte que Redis. Cela signifie moins de documentation sur "qu'est ce qu'un courtier", mais signifie également que vous ne pouvez pas 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 pas (au moment de l'écriture) garantir à 100% que vos messages sont livrés.

• Files D'attente prioritaires. Le modèle de file d'attente prioritaire RQs est simple et efficace- les travailleurs lisent à partir des files d'attente dans l'ordre. Céleri nécessite spinning jusqu'à plusieurs travailleurs à consommer de différentes files d'attente. Les deux approches fonctionnent

• Support du système D'exploitation. Céleri est le gagnant clair ici, car RQ ne fonctionne que sur les systèmes qui prennent en charge fork, par exemple les systèmes Unix

• Support linguistique. RQ ne supporte que Python, alors 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 workflow canvas) mais naturellement cette puissance peut être déroutante. Par en revanche, l'api RQ est simple.

• Support de la sous-tâche. 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 ils sont tous deux des projets actifs. Au moment de l'écriture, Celery a ~3500 étoiles sur Github tandis que RQ 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 mener à croire, mais vous devrez RTFM.

Alors, pourquoi quelqu'un serait 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 intéresse, au lieu d'avoir à garder les détails sur le système de file d'attente des tâches dans votre mémoire de travail. Nous avons tous un limite sur le nombre de détails peut être dans notre tête à la fois, et en supprimant la nécessité de garder les détails de la file d'attente des tâches là-bas 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 large du système D'exploitation, les garanties de message fiables à 100% et la possibilité de changer facilement de courtier de messages.