Vor- und Nachteile der Verwendung von Sellerie vs. RQ [geschlossen]

Derzeit arbeite ich an einem Python-Projekt, für das einige Hintergrundjobs implementiert werden müssen (hauptsächlich für das Senden von E-Mails und umfangreiche Datenbankaktualisierungen). Ich benutze Redis als Task Broker. In diesem Punkt habe ich zwei Kandidaten: Sellerie und RQ . Ich hatte einige Erfahrungen mit diesen Job-Warteschlangen, aber ich möchte Sie bitten, Ihre Erfahrungen mit der Verwendung dieser Tools mitzuteilen. So.

1. Welche Vor- und Nachteile hat Sellerie vs. RQ?
2. Alle Beispiele für Projekte / Aufgaben, die für die Verwendung von Sellerie vs. RQ geeignet sind.

Sellerie sieht ziemlich kompliziert aus, ist aber eine voll ausgestattete Lösung. Eigentlich glaube ich nicht, dass ich all diese Funktionen brauche. Von der anderen Seite ist RQ sehr einfach (z. B. Konfiguration, Integration), aber es scheint, dass einige nützliche Funktionen fehlen (z. B. Aufheben von Aufgaben, automatisches Neuladen von Code).

Folgendes habe ich gefunden, als ich versucht habe, genau dieselbe Frage zu beantworten. Es ist wahrscheinlich nicht umfassend und kann in einigen Punkten sogar ungenau sein.

Kurz gesagt, RQ ist rundum einfacher gestaltet. Sellerie ist robuster ausgelegt. Sie sind beide ausgezeichnet.

• Dokumentation. Die Dokumentation von RQ ist umfassend, ohne komplex zu sein, und spiegelt die allgemeine Einfachheit des Projekts wider - Sie fühlen sich nie verloren oder verwirrt. Die Dokumentation von Celery ist ebenfalls umfassend, aber Sie können davon ausgehen, dass Sie sie beim ersten Einrichten häufig erneut besuchen, da es zu viele Optionen zum Verinnerlichen gibt

• Überwachung. Celery's Flower und das RQ-Dashboard sind beide sehr einfach einzurichten und bieten Ihnen mindestens 90% aller Informationen, die Sie jemals benötigen würden

• Maklerunterstützung. Sellerie ist der klare Gewinner, RQ unterstützt nur Redis. Dies bedeutet weniger Dokumentation zu "Was ist ein Broker?", Aber es bedeutet auch, dass Sie in Zukunft nicht mehr den Broker wechseln können, wenn Redis nicht mehr für Sie arbeitet. Zum Beispiel hat Instagram sowohl Redis als auch RabbitMQ mit Sellerie in Betracht gezogen . Dies ist wichtig, da verschiedene Broker unterschiedliche Garantien haben, z. B. kann Redis (zum Zeitpunkt des Schreibens) nicht 100% garantieren, dass Ihre Nachrichten zugestellt werden.

• Prioritätswarteschlangen. Das Prioritätswarteschlangenmodell von RQ ist einfach und effektiv - Mitarbeiter lesen der Reihe nach aus den Warteschlangen . Sellerie erfordert das Hochfahren mehrerer Arbeiter, um aus verschiedenen Warteschlangen zu konsumieren. Beide Ansätze funktionieren

• Betriebssystemunterstützung. Sellerie ist hier der klare Gewinner, da RQ nur auf Systemen ausgeführt wird, die forkz. B. Unix-Systeme unterstützen

• Sprachunterstützung. RQ unterstützt nur Python, während Sie mit Celery Aufgaben von einer Sprache in eine andere Sprache senden können

• API. Sellerie ist extrem flexibel (Backends mit mehreren Ergebnissen, schönes Konfigurationsformat, Unterstützung für Workflow-Canvas), aber diese Leistung kann natürlich verwirrend sein. Im Gegensatz dazu ist die RQ-API einfach.

• Subtask-Unterstützung. Sellerie unterstützt Unteraufgaben (z. B. das Erstellen neuer Aufgaben aus vorhandenen Aufgaben heraus). Ich weiß nicht, ob RQ es tut

• Gemeinschaft und Stabilität. Sellerie ist wahrscheinlich etablierter, aber beide sind aktive Projekte. Zum Zeitpunkt des Schreibens hat Sellerie ~ 3500 Sterne auf Github, während RQ ~ 2000 hat und beide Projekte eine aktive Entwicklung zeigen

Meiner Meinung nach ist Sellerie nicht so komplex, wie sein Ruf vermuten lässt, aber Sie müssen RTFM.

Warum sollte jemand bereit sein, den (wohl umfassenderen) Sellerie gegen RQ zu tauschen? In meinen Augen kommt es auf die Einfachheit an. Durch die Beschränkung auf Redis + Unix bietet RQ eine einfachere Dokumentation, eine einfachere Codebasis und eine einfachere API. Dies bedeutet, dass Sie (und potenzielle Mitwirkende an Ihrem Projekt) sich auf den Code konzentrieren können, der Ihnen wichtig ist, anstatt Details zum Task-Warteschlangensystem in Ihrem Arbeitsspeicher aufbewahren zu müssen. Wir alle haben eine Begrenzung, wie viele Details gleichzeitig in unserem Kopf sein können. Wenn Sie nicht mehr die Details der Aufgabenwarteschlange behalten müssen, können Sie mit RQ zu dem Code zurückkehren, der Ihnen wichtig ist. Diese Einfachheit geht zu Lasten von Funktionen wie sprachübergreifenden Aufgabenwarteschlangen, umfassender Betriebssystemunterstützung, 100% zuverlässigen Nachrichtengarantien und der Möglichkeit, Nachrichtenbroker einfach zu wechseln.

Sellerie ist nicht so kompliziert. Im Kern führen Sie die schrittweise Konfiguration aus tutorials, erstellen eine celeryInstanz, dekorieren Ihre Funktion mit @celery.taskund führen dann die Aufgabe mit aus my_task.delay(*args, **kwargs).

Nach Ihrer eigenen Einschätzung scheint es, dass Sie sich zwischen fehlenden (Schlüssel-) Merkmalen oder einem Übermaß entscheiden müssen. Das ist in meinem Buch keine allzu schwere Wahl.