RabbitMQ: Was bietet Sellerie, dass Pika nicht?

Question

Ich habe daran gearbeitet, einige verteilte Aufgaben über RabbitMQ zu erledigen.

Ich verbrachte einige Zeit damit, Sellerie zu bekommen, was ich wollte und es nicht funktionieren lassen konnte.

Dann habe ich versucht, mit Pika und die Dinge haben funktioniert, einwandfrei, und innerhalb weniger Minuten.

Gibt es etwas, das ich verpasse, indem ich Pika anstelle von Sellerie verwende?

Answer 1

Was Pika bietet, ist nur ein kleiner Teil dessen, was Sellerie macht. Pika ist eine Python-Bibliothek für die Interaktion mit RabbitMQ. RabbitMQ ist ein Nachrichtenbroker; im Kern sendet es nur Nachrichten an/empfängt Nachrichten von Warteschlangen. Es kann als Aufgabenwarteschlange verwendet werden, aber es kann auch nur dazu verwendet werden, Nachrichten zwischen Prozessen zu übergeben, ohne "Arbeit" zu verteilen.

Sellery implementiert eine Warteschlange für verteilte Aufgaben, optional mit RabbitMQ als Broker für IPC. Anstatt nur eine Möglichkeit zum Senden von Nachrichten zwischen Prozessen bereitzustellen, stellt es ein System zum Verteilen tatsächlicher Aufgaben/Jobs zwischen Prozessen bereit. Hier ist, wie Sellerie Website beschreibt:

Task-Warteschlangen als Mechanismus verwendet werden, die Arbeit über Threads oder Maschinen zu verteilen.

Eine Aufgabe Warteschlange ist eine Einheit der Arbeit, genannt eine Aufgabe, dedizierte Arbeiter Prozesse dann ständig überwachen die Warteschlange für neue Arbeit zu durchführen.

Sellerie kommuniziert über Nachrichten, in der Regel mit einem Vermittler zu vermitteln zwischen Kunden und Arbeitnehmern. Um eine Aufgabe zu initiieren, legt ein Client eine Nachricht in die Warteschlange, und der Broker übergibt die Nachricht dann an einen Mitarbeiter.

Ein Sellerie-System kann aus mehreren Arbeitern und Maklern bestehen, die Weg zu hoher Verfügbarkeit und horizontaler Skalierung geben.

Sellerie hat eine ganze Reihe von eingebauten Funktionen, die außerhalb von Pikas Umfang liegen. Sie können an den Celery docs einen Blick eine Vorstellung von der Art von Dingen, um es zu tun, aber hier ist ein Beispiel:

>>> from proj.tasks import add 

>>> res = add.chunks(zip(range(100), range(100)), 10)() 
>>> res.get() 
[[0, 2, 4, 6, 8, 10, 12, 14, 16, 18], 
[20, 22, 24, 26, 28, 30, 32, 34, 36, 38], 
[40, 42, 44, 46, 48, 50, 52, 54, 56, 58], 
[60, 62, 64, 66, 68, 70, 72, 74, 76, 78], 
[80, 82, 84, 86, 88, 90, 92, 94, 96, 98], 
[100, 102, 104, 106, 108, 110, 112, 114, 116, 118], 
[120, 122, 124, 126, 128, 130, 132, 134, 136, 138], 
[140, 142, 144, 146, 148, 150, 152, 154, 156, 158], 
[160, 162, 164, 166, 168, 170, 172, 174, 176, 178], 
[180, 182, 184, 186, 188, 190, 192, 194, 196, 198]] 

Dieser Code will jeden x + y hinzuzufügen, wobei x in range(0, 100) und y in range(0,100). Dazu wird eine Aufgabe mit der Bezeichnung add, die zwei Zahlen hinzufügt und die Arbeit des Hinzufügens von 1+1, 2+2, 3+3 usw. aufteilt, in 10er-Stücke aufgeteilt und jedes Stück an so viele Sellerie-Arbeiter verteilt, wie verfügbar sind. Jeder Arbeiter wird add auf seinem 10-Item-Chunk ausführen, bis alle Arbeit abgeschlossen ist. Dann werden die Ergebnisse durch den Anruf res.get() gesammelt. Ich bin mir sicher, dass Sie sich einen Weg vorstellen können, dies mit Pika zu tun, aber ich bin mir sicher, dass Sie sich auch vorstellen können, wie viel Arbeit nötig wäre. Sie erhalten diese Funktionalität mit Sellerie sofort aus der Verpackung.

Sie können sicherlich Pika verwenden, um eine verteilte Aufgabenwarteschlange zu implementieren, wenn Sie möchten, besonders wenn Sie einen recht einfachen Anwendungsfall haben. Sellery bietet nur eine "Batterien inklusive" -Lösung für die Aufgabenplanung, Verwaltung usw., die Sie manuell implementieren müssen, wenn Sie sich entscheiden, dass Sie sie mit Ihrer Pika-Lösung wünschen.

Answer 2

Ich werde hier eine Antwort hinzufügen, weil dies das zweite Mal ist, dass heute jemand Sellerie empfohlen hat, wenn er nicht benötigt wird, basierend auf dieser Antwort, vermute ich. Der Unterschied zwischen einer Warteschlange für verteilte Aufgaben und einem Broker besteht also darin, dass ein Broker nur Nachrichten weiterleitet. Nicht mehr, nicht weniger. Sellery empfiehlt, RabbitMQ als Standardbroker für IPC zu verwenden, und platziert diese zusätzlich, um Aufgaben/Warteschlangen mit Daemon-Prozessen zu verwalten. Dies ist besonders nützlich für verteilte Aufgaben, wo Sie sehr schnell etwas Generisches benötigen. Es ist nur Konstrukt für den Publisher/Consumer-Prozess. Bei tatsächlichen Aufgaben, bei denen Sie einen Arbeitsablauf definiert haben, den Sie durchlaufen müssen, und um sicherzustellen, dass die Nachrichten auf Ihre speziellen Anforderungen abgestimmt sind, sollten Sie lieber Ihren eigenen Verleger/Verbraucher schreiben, als sich auf Sellerie zu verlassen. Offensichtlich müssen Sie immer noch alle Haltbarkeitsprüfungen usw. durchführen. Bei den meisten Web-bezogenen Diensten kontrolliert man nicht die tatsächlichen "Arbeits" -Einheiten, sondern gibt sie an einen Dienst weiter. Daher ist es für eine Warteschlange für verteilte Aufgaben wenig sinnvoll, es sei denn, Sie treffen ein beliebiges API-Anruflimit basierend auf IP/geografischer Region oder Kontonummer ... oder etwas in dieser Richtung. Die Verwendung von Sellerie hindert Sie also nicht daran, den Statuscode oder die Verwaltung von Arbeitsabläufen usw. zu schreiben oder damit umzugehen, und es stellt das AMQP so zur Verfügung, dass Sie die Konstrukte des Publisher/Consumer-Codes nicht einfach schreiben können.

Kurz gesagt, wenn Sie eine einfache Aufgabenwarteschlange benötigen, um durch Arbeit zu kauen, und Sie sind nicht wirklich besorgt über die Nuancen der Leistung, die Feinheiten der Haltbarkeit durch Ihren Workflow oder die tatsächlichen Publish/Consume-Prozesse. Sellerie funktioniert. Wenn du nur Nachrichten an eine API oder einen Dienst übergibst, die du eigentlich nicht kontrollierst, könntest du Sellerie verwenden, aber du könntest genauso schnell deinen eigenen Verleger/Verbraucher mit Pika in ein paar Minuten aufpeitschen. Wenn Sie etwas Robustes benötigen oder sich an Ihre eigenen Haltbarkeitsszenarien halten, schreiben Sie Ihren eigenen Publish/Consumer-Code wie alle anderen auch.