Celery: Vorschlag, Redis als Broker-Support einzustellen. [Hat abgelehnt]

Heutzutage gibt es Alternativen zu Sellerie, zB huey und rq die sich explizit auf die Unterstützung von Redis als Broker konzentrieren. Als Sellerie freigesetzt wurde, gab es nichts.

@ask, was halten Sie davon, auch den SQL-Broker-Support einzustellen? Ich bezweifle, dass es viele Leute gibt, die eine SQL-Datenbank in der Produktion verwenden. Selbst wenn sie es tun, sollten sie es eigentlich nicht.
Wir haben auch Docker, was bedeutet, dass die Bereitstellung von rabbitmq buchstäblich einen Befehl entfernt ist. Es ist nicht mehr _so_ schwer.

Ich habe gerade die Unterstützung für SQL als Broker eingestellt, einschließlich aller anderen Broker außer RabbitMQ / Redis / SQS / Qpid :)

(Duplikat)

Ich bin nicht so eng mit der Sellerie-Community verbunden; ungeachtet meiner 0,02 $:

• Redis ist wirklich beliebt - ungefähr so ​​beliebt wie alle anderen unterstützten Broker _kombiniert_ , wenn Sie denken, dass Google Trends repräsentativ ist
• Es kann ein wirklich guter Broker _und_ Backend sein (RabbitMQ aber auch)
• Es wird einzigartig von den großen Cloud-Anbietern als vollständig verwalteter Service angeboten
• Wir verwenden Redis viel!

Ich kann Ihre Meinung zu den Wartungsproblemen nachempfinden, und diese Art von Maßnahmen ist ein Schritt in Richtung Nachhaltigkeit. Aber gibt es noch andere „Amputationen“, die Sie vornehmen könnten?

Haben Sie auf der "Angebotsseite" der Gleichung irgendwelche Gedanken, warum die Community nicht mehr zum Sellerie beiträgt?
Ein flüchtiger Blick auf die Commits & PRs deutet darauf hin, dass Sellerie hauptsächlich das Werk einer Person ist, im Vergleich zu einigen Open-Source-Bibliotheken, zu denen ich beisteuere

@MaximilianR Ich spreche nur für mich:

1. Dies ist eine beträchtliche Codebasis, in die man hineingehen kann
2. Vor allem, wenn Sie kein Experte für Kombu und Ayncio sind
3. Und Sie haben keine Ahnung von der Tiefe der gemeldeten Probleme

Allerdings verwende ich Sellerie, wenn ich also irgendwie nützlich sein kann, helfe ich gerne.

@MaximilianR , Es gab zahlreiche Mitwirkende, aber definitiv habe ich viel Arbeit geleistet. Das Projekt wuchs zu schnell und irgendwann hatte ich die Wahl zwischen der Behebung von Fehlern oder der Unterstützung von Benutzern auf IRC/E-Mail/StackOverflow usw. Besonders Dinge wie das Multiprocessing-Pool-Deadlock-Problem brauchten weit über 6 Monate fokussiertes Programmieren, als ich es hätte tun sollen Mentoren von Menschen. Wir hatten zu diesem Zeitpunkt fast die Größe von RabbitMQ in Downloads, aber wo 8 Leute Vollzeit arbeiteten, war ich der einzige.

Es gibt wahrscheinlich noch andere Dinge zu amputieren, aber ich glaube nicht, dass etwas so zeitaufwendig ist wie Redis.

Die Arbeit der Portierung von amqp/kombu auf volles Asyncio war ebenfalls eine große Zeitfresser, aber notwendig, um eine Reihe von Problemen zu lösen. Es wurde jedoch nie abgeschlossen.

@ask Bedeutet Ihre obige Nachricht, dass Sie immer noch daran interessiert sind, sich um SQS zu bemühen? Mir ist aufgefallen, dass es hier nur ein offenes SQS-Ticket gibt, aber ich sehe immer noch die Warnung "Experimental" in den Dokumenten. Können Sie uns zum aktuellen Stand und zukünftigen Bedarf für SQS beraten?

Wir würden Celery + SQS in der Produktion verwenden, also kann ich vielleicht etwas dazu beitragen, aber ich möchte nicht wirklich in diese Situation geraten, wenn SQS nicht Teil Ihres langfristigen Plans für das Projekt ist.

@ask danke, dass hast . Ich kann verstehen, woher du kommst. Ich hoffe, durch diese / andere Ansätze kann Sellerie leichter gepflegt werden und seinen Erfolg fortsetzen ...

Tun Sie auf jeden Fall das Beste für Ihr Projekt, aber ich werde auf jeden Fall darauf drängen, Celery intern loszuwerden, wenn die Redis-Unterstützung eingestellt wird. Ich werde es privat erläutern, wenn Sie wirklich wissen möchten, warum wir RabbitMQ nicht verwenden werden, aber ich möchte nicht wirklich andere Projekte öffentlich anprangern.

Verwandte: Dies deutet darauf hin, dass es sich um einen einzigen Befehl handelt, da dies für Sie auf Docker die Art und Weise ist, wie Sie entwickeln, möglicherweise für Sie funktioniert, aber der Rest von uns stellt nicht unbedingt so bereit.

@nicksloan SQS wird jetzt in den Master-Dokumenten als unterstützter Transport aufgeführt: http://docs.celeryproject.org/en/master/getting-started/brokers/index.html

Die Arbeit, den SQS-Transport in die Verwendung von asynchroner E/A umzuschreiben, wurde für etwas mehr als 1000 US-Dollar gesponsert.

@scoates Der Redis-Transport befindet sich in einer schlimmeren Situation, da er wirklich zusammengehackt wurde, um asynchrone E/A zum Lesen von Nachrichten zu verwenden, aber die Veröffentlichung ist immer noch synchron. Die Python-Redis-Bibliothek ist synchron, daher gibt es selbst beim Lesen von Nachrichten noch mehrere Herausforderungen und eine Menge Unsicherheit darüber, wie das funktioniert. Fehler können sich dort leicht verstecken, und alle Änderungen an der redis-py-Bibliothek können drastische Auswirkungen haben, wenn wir sie auf nicht-orthodoxe Weise verwenden.

Ich möchte Redis unterstützen, das tue ich wirklich. Ich habe darum gekämpft, als ich bei RabbitMQ/Pivotal arbeitete, da ich der Meinung war, dass wir eine gemeinsame Lösung in Python für die Muster brauchen, die Celery implementiert. Aber wenn die Community und die Unternehmen, die es nutzen, nicht in die Aufrechterhaltung des Betriebs investieren, werde ich die Brandbekämpfung zurücklassen und schlimmstenfalls jetzt nicht in der Lage sein, ernsthafte Probleme mit dem Transport zu beheben, die dazu führen, dass das Projekt kritisiert wird. Das macht mein Leben noch unglücklicher und mindert die Moral.

Dies mag angesichts der Geschichte von Sellerie zu radikal sein, aber haben Sie darüber nachgedacht, nur Redis gegenüber RabbitMQ zu behalten?

@MaximilianR Ich habe es in Betracht gezogen, aber meine Leidenschaft liegt in der Nachrichtenweitergabe und dem Aufbau korrekter verteilter Systeme. Redis hat uns noch keine Implementierung von BRPOPLPUSH zur Verfügung gestellt, die für die Implementierung von Nachrichtenbestätigungen funktioniert, und mit der Enthüllung der Unfähigkeit zu akzeptieren, dass es unmöglich ist, sich in verteilten Systemen auf die Wanduhrzeit zu verlassen, eine grundlegende Tatsache, bin ich vorsichtiger. RabbitMQ greift zumindest den Problemraum ernsthaft an, und es gibt andere Spieler wie Kafka und NSQ. Viele Bibliotheken behandeln Aufgabenwarteschlangen als einfache Listenoperation, aber ich weigere mich, dass Celery einer von ihnen wird :)

@scoates : Ich habe nicht darüber gesprochen, wie ich mich entwickle oder so. Ich sagte, dass es Unsinn ist, im Jahr 2016 zu sagen, "rabbitmq ist schwer zu implementieren". Auch wenn Sie nichts darüber wissen, etwas irgendwo bereitzustellen, gibt es Docker, das wirklich hilft. Bitte machen Sie keine falschen Annahmen.

Danke @ask, dass eingecheckt hast . Sellerie ist ein großartiges Produkt und angesichts der begrenzten Ressourcen, die Sie (und die Community) haben, denke ich, dass es die beste Entscheidung ist, sich auf das Kernprodukt zu konzentrieren. Ich kann mir vorstellen, wie schwierig es sein muss, die gleichen großartigen Funktionen mit vielen verschiedenen inkompatiblen Systemen anzubieten. Aus Sicht des Verbrauchers trägt es meiner Meinung nach zur Komplexität des Produkts bei, so viele Optionen zu haben. Ich bin mir sicher, dass dies einige Ihrer Benutzer verärgern wird, aber ich denke, es ist das Richtige für das Produkt, sich an weniger Broker zu halten. Ich würde gerne den Fokus auf AMQP als Standard, gut akzeptiertes Protokoll sehen und ich denke, Rabbitmq ist eine sehr gute Implementierung davon.

Schade, dass da wirklich nicht viel zu tun ist, aber wenn man all die Transporte und Features zusammenzählt, ist das mit ein paar Stunden pro Woche nicht nachhaltig.

Da das Redis-Protokoll so einfach ist, muss es nicht so schwierig sein, den Transport so umzuschreiben, dass er vollständig asynchron ist. Ich habe eine Ebene erstellt, die es Celery ermöglicht, jede Tornado-Bibliothek zu unterstützen, das gleiche könnte für asyncio und Twisted erstellt werden, sodass wir möglicherweise sogar Clients haben, die wir wiederverwenden können.

Python ändert sich drastisch mit asyncio in stdlib. Wir brauchen neue Web-Frameworks, neue Netzwerkbibliotheken und so ziemlich das gesamte Ökosystem muss sich anpassen. Es erleichtert unsere Arbeit ein wenig, da wir unsere eigene Event-Schleife nicht mehr pflegen müssen, aber der Übergang wird einiges an Arbeit erfordern.

Ich möchte auch einen neuen Worker in Go oder ähnlichem schreiben, da wir jetzt ein neues Nachrichtenprotokoll mit Unterstützung für mehrere Sprachen haben. Redis ist nicht die beste Wahl für die Messaging-Interoperabilität, da es keine Nachrichtenheader, Eigenschaften usw. implementiert. Das AMQP-Protokoll hat dort definitiv die Oberhand, da es einer der ursprünglichen Anwendungsfälle war.

@ask Mein Ansatz bestand darin, zu versuchen, Unternehmen dazu zu bringen, ihre Broker zu pflegen. Versuchen wir also, mit jemandem aus den Redis-Labors zu sprechen und zu sehen, ob wir Anklang finden.
Das gleiche gilt für MongoDB und andere Dienste.
Was SQL-Broker angeht, sind sie meiner Meinung nach keine sehr gute Idee und wir sollten sie nicht unterstützen.
Wir können den Code extrahieren, anstatt ihn zu entfernen, und nach jemandem suchen, der ihn pflegt. Wenn das Interesse nicht ausreicht, braucht es sie nicht.
Die einzige SQL-Datenbank, die eine Art Broker sein kann, ist Postgres, da sie über Pub/Sub-Funktionen verfügt, die jedoch derzeit sowieso nicht implementiert ist.

Ich denke, wir können es einfach ablehnen und sehen, was passiert. Vielleicht setzt sich jemand dafür ein, indem er die Wartung übernimmt oder eine Patenschaft übernimmt. Wenn nicht, haben wir ein Produkt, das die Leute brauchen, aber niemand unterstützen möchte, was zu diesem Zeitpunkt mit insgesamt 18 Stimmen wahrscheinlich ist. Ich glaube nicht, dass das Redis Labs allein beeinflussen wird :)

Aber wenn die Community und die Unternehmen, die es nutzen, nicht in die Aufrechterhaltung des Betriebs investieren, werde ich die Brandbekämpfung zurücklassen und schlimmstenfalls jetzt nicht in der Lage sein, ernsthafte Probleme mit dem Transport zu beheben, die dazu führen, dass das Projekt kritisiert wird. Das macht mein Leben noch unglücklicher und mindert die Moral.

Wir verwenden Sellerie mit dem Redis-Broker bei mehreren Projekten und sind davon abhängig, aber ich stimme dieser Meinung voll und ganz zu. Wenn Sie es nicht auf einem hohen Qualitätsniveau halten können, wird es Sellerie nur einen schlechten Ruf geben und alle unglücklich machen – Sie _und_ die Benutzer.

Hi. Ich arbeite für Redis Labs und war bis vor kurzem Sellerie. @thedrow hat mich darauf aufmerksam gemacht und wir haben dies intern besprochen. Wir sind bereit, Ihnen zu helfen, wir denken, dass es wichtig ist, Redis als Teil von Sellerie zu behalten. Ich bin mir noch nicht sicher, ob ich das persönlich oder jemand anders mache, aber lasst uns die Diskussion darüber in Gang bringen, was getan werden muss.

Wie @dvirsky wird meine Arbeit für Redis vollständig von Redis Labs gesponsert, und wenn wir mit diesem Backend helfen können (hoffentlich ja), werde ich daran beteiligt sein, die besten Lösungen auf der Redis-Seite zu finden, und möglicherweise sogar Erweiterung der Redis-Messaging-Unterstützung, um bestimmte Dinge bei der Implementierung zu erleichtern. Wir könnten auch die Fähigkeit des Backends betonen, Sentinel / Redis Cluster irgendwann zu verwenden, um eine HA-fähige Erfahrung zu machen. Ich hoffe, dass wir so schnell wie möglich gute Nachrichten haben, da wir derzeit die erforderlichen Anstrengungen bewerten.

Das sind wirklich gute Nachrichten! Ich verstehe vollkommen, dass Sie die damit verbundene Arbeit kennen möchten, bevor Sie sich dazu verpflichten :)

Es ist jetzt 3 Uhr morgens hier und ich habe keine Liste mit Problemen gesammelt, aber hier sind einige kurze Anmerkungen:

Celery definiert keine Reihe von Funktionen, die mit einer Schnittstelle zu Redis implementiert werden, stattdessen
Es verwendet die AMQP-API, um Messaging auf generische Weise zu verwenden. Name-to-Queue-Messaging, Pub/Sub- und Topic-Routing. Das Themen-Routing ist keine strikte Anforderung, aber der Rest ist entscheidend für die Hauptfunktionen von Celery 1) die Verarbeitung von Aufgabennachrichten, 2) das Senden/Empfangen von Überwachungsereignissen und 3) das Senden von Nachrichten an die Mitarbeiter, um diese zu verwalten (z. B. Herunterfahren/Erhöhen der Parallelität usw.). ).

1) Muss asynchron sein, damit der Worker für keinen Vorgang blockiert wird

Die aktuelle Version verwendet die redis-py-Bibliothek, die synchron ist. Ich habe das gehackt, um es zu machen
es konsumiert Nachrichten asynchron, aber ich vermute, dass es immer noch Fehler gibt, da wir nicht genau wissen, was im Client passiert. Möglicherweise sind bereits asynchrone Redis-Clients verfügbar für
Tornado/Asyncio, die wir verwenden könnten, oder im schlimmsten Fall, da wir nicht viel brauchen, um es roh zu machen, möglicherweise nicht
so knifflig sein.

2) Verbindungsmanagement

Wir haben eine Verbindung, die Aufgaben verbraucht, und eine Verbindung, die Pubsub erledigt, dann einen Pool
von Verbindungen, um Out-of-Band-Operationen durchzuführen, wie das Bestätigen von Nachrichten oder das Wiederherstellen nicht bestätigter Nachrichten. Es gibt hier einige Verwirrung bezüglich der Fehlerbehandlung, und wir schließen möglicherweise nicht alle Verbindungen nach der Verwendung.

3) Nachrichtenbestätigung

Nachrichten werden erst vom Server entfernt, nachdem sie bestätigt wurden und wir haben ein Sichtbarkeits-Timeout, bei dem alle Nachrichtenkonsumenten versuchen, Nachrichten wiederherzustellen. Nun, es ist ein Durcheinander,
Dies kann ich später genauer beschreiben.

Danke @ask , zu Punkt "1" kann es sinnvoll sein, die minimale asynchrone Redis-Unterstützung, die wir für die wenigen Befehle benötigen, die wir direkt im Broker senden, direkt zu implementieren, anstatt von einer externen Bibliothek abzuhängen.

Beachten Sie, dass nur 2 und möglicherweise einige andere kleine Probleme bald gelöst werden müssen. Es funktioniert weitgehend, aber es gibt Fälle, in denen Nachrichten aufgrund der Nachrichtenbestätigung verloren gehen können, aber das ist ein Wunschlisteneintrag, da die Situation vor der Bestätigungsemulation viel schlimmer war. Der Worker kann vom synchronen Redis-Client blockiert werden, was zu schlechter Leistung und in seltenen Fällen zu hängenden Workern führt.

1) Muss asynchron sein, damit der Worker für keinen Vorgang blockiert wird

Als ich zuletzt überprüft habe, waren die asynchronen Redis-Clients nicht perfekt (es gibt ein paar für Tornado). In diesen Situationen habe ich oft einen Thread-Pool-Executor und Futures verwendet, damit sich redis-py wie ein asynchroner Client verhält. solange Sie nicht zu viele gleichzeitige Aufgaben haben und ein paar Threads ausreichen, funktioniert es besser als asynchrone Clients.

BEARBEITEN: Ich habe noch nicht direkt mit Pythons Asyncio gearbeitet, aber von dem, was ich gesehen habe, ist es Tornado ziemlich ähnlich, so dass dieses Muster wahrscheinlich einfach zu machen ist.

@dvirsky Wir dürfen keine Threads verwenden, da wir auch fork . Python unterstützt diesen Fall nicht, und selbst wenn ein Patch für cpython erstellt wurde, müssten wir vorhandene Python-Bibliotheken, zumindest die C-Erweiterungen, sorgfältig patchen, um auf diese Weise sicher zu sein. Dies wurde vor einiger Zeit auf dem Python-Bugtracker realisiert, und deshalb haben wir die Migration auf asynchrone I/O durchgeführt. Wir müssen uns auch im Allgemeinen dorthin bewegen, da dies in der Zukunft von Python jetzt mit asynchroner I/O-Core-Unterstützung liegt.

@antirez re:

Bei Punkt "1" kann es sinnvoll sein, die minimale asynchrone Redis-Unterstützung, die wir für die wenigen Befehle benötigen, die wir direkt im Broker senden, direkt zu implementieren, anstatt von einer externen Bibliothek abzuhängen.

Ich würde das nicht tun. Der größte Teil des Codes von redis-py dreht sich um Netzwerk- und Verbindungsmanagement, nicht um die Implementierung von Befehlen ...

@dvirsky Wir haben Generika für das Verbindungsmanagement, die dafür perfekt funktionieren würden, also sollte das keine Zeitfresser sein. Von Netzwerken haben wir nicht viel, aber ich denke, das meiste besteht darin, das Protokoll zu parsen, und wir tun dies bereits fast manuell oder binden uns in die vorhandenen Redis-Klassen ein.

@ask ja, es gibt Hiredis, eine dedizierte C-Erweiterung zum Parsen des Redis-Protokolls, IIRC, die auch mit einem asynchronen Client arbeiten kann. Welche Strategie haben Sie bisher gewählt, um Redis asynchron zu machen?

Wie auch immer, ich muss mir ansehen, was in letzter Zeit mit den asynchronen Clients passiert ist, ich habe in den letzten anderthalb Jahren nicht viel Python-Arbeit geleistet. Ich sehe, dass https://github.com/leporo/tornado-redis nicht sehr aktiv war.

Es gibt nicht viel Strategie, wir fügen den Socket in die Event-Schleife ein und senden zB BRPOP synchron, dann warten wir, bis der Socket lesbar ist und lesen die Antwort synchron ;)

Da wir während des Parsens der Antwort keine Möglichkeit haben, neu zu starten

@dvirsky Wenn wir Hiredis für etwas anderes als das Protokoll-Parsing verwenden, haben wir Kompatibilitätsprobleme mit gevent/eventlet (wenn es anstelle von Multiprocessing verwendet wird) und es wird auch Hiredis obligatorisch machen, welche Portabilitätsprobleme auftreten, wenn Celery auf PyPy ausgeführt wird.

@dvirsky Außerdem

Python wird meiner Meinung nach irgendwann einen anständigen asynchronen Redis-Client benötigen, daher wäre es keine schlechte Idee, etwas Richtiges zu starten. ZB Refactoring eines Teils des Protokoll-Parsing-Codes in redis-py.

verwendest du gerade gevent?

@dvirsky Wir unterstützen Gevent, Eventlet und Multiprocessing (Prefork) mit async I/O. Aber wenn Sie einen unterstützen, haben Sie normalerweise die anderen.

Ja, es gibt Zeiten, in denen gevent für Aufgaben besser geeignet ist. zB wenn Aufgaben einfach in die Datenbank schreiben oder eine HTTP-Anfrage ausführen.
Es ist einfach genug, die FDs in gevent freizugeben und zu registrieren, aber das erfordert weitere Arbeit in py-hiredis.

@dvirsky Hier ist ein Beispiel dafür, wie es mit PyCurl gemacht wird. https://gist.github.com/GuoJing/5875326
Sie müssen die FD freigeben, um mit gevent zusammenzuarbeiten.

Ich wurde vor kurzem in das Problem der Sellerie-Unterstützung für Redis eingeführt und obwohl ich keine gründliche Analyse abgeschlossen habe, kann ich sagen, dass das Schreiben / Aktualisieren eines Python-Redis-Clients mit asyncio nach einer guten Idee klingt, aber nach den neuesten Benchmarks wäre das am besten zusätzlich zu asyncio+libuv implementiert, um so viel Leistung wie möglich zu erreichen.

Referenzen siehe

• https://github.com/MagicStack/uvloop
• https://github.com/saghul/pyuv
• http://magic.io/blog/uvloop-blazing-fast-python-networking/

Gegen diese Position – oder um die Sache noch komplizierter zu machen, möchte ich anmerken, dass aus meiner eigenen Erfahrung mit Redis-Clients als Entwickler und Benutzer das vollständige Vertrauen auf libuv den Client tatsächlich daran hindert, die maximale Leistung zu erzielen, und dafür ist Hiredis ein Muss. Es gibt eine Menge Dinge unter der Haube in libuv, die io in einigen Fällen tatsächlich verlangsamen, ioredis macht es über Node und es ist nicht wirklich performant.

Die Lösung, die ich mir vorstellen würde, hat also eine gemischte Hiredis-async-Implementierung. (Anders ausgedrückt, müssen eine Reihe von Alternativen mit Tonnen von Rosinenpickerei und Benchmarking ausprobiert werden)

@merl-dev Das Problem ist immer noch PyPy, wo Hiredis+cffi beim Parsen des Redis-Protokolls langsamer ist als die reine Python-Protokoll-Parser-Implementierung.
Zumindest hat meine Version auch einige Testfehler mit redis-py. Siehe https://github.com/redis/hiredis-py/pull/46

Es ist durchaus möglich, einen Hiredis-Client als CPython-Erweiterung zu schreiben. Bei CFFI bin ich mir noch nicht 100% sicher.

lass es uns holen

@thedrow das erinnert mich - haben Sie sich die neue Redis-Streams-Funktion angesehen? Es kann als ein viel robusterer Nachrichtenbroker verwendet werden als das aktuelle Zeug. Es wird bald GA sein.

Wir nicht. Wir haben derzeit nicht die Kapazität, den Redis-Broker umzugestalten.
Wir hatten gehofft, ihr hättet ein paar freie Hände dafür.

@thedrow wir könnten nur ... nichts versprechen, aber wir könnten mehr Ressourcen für die proaktive Unterstützung des Redis-Ökosystems bereitstellen.

@dvirsky du meinst diesen Vorschlag , oder? Sie könnten also TAPPEND zum Einreihen verwenden, TREAD + TACK zum Aussteigen, Verarbeiten und Bestätigen.

@georgepsarakis Es ist kein Vorschlag mehr, es funktioniert und das Präfix ist X, dh XADD. siehe https://www.youtube.com/watch?v=ELDzy9lCFHQ

Was ist also der letzte Aufruf zur Unterstützung von Redis-Brokern? Wird demnächst abgeschafft?

Nicht im Moment.

Ich konnte nicht sagen, in welche Richtung die Community tendiert, aber wir starten ein neues Projekt und ich zögere, mit Redis als Broker zu gehen, da ich daran denke, es abzulehnen. Die Gedanken?

Es ist davon auszugehen, dass der Redis-Broker auf absehbare Zeit bleiben wird. Zu viele Leute verlassen sich darauf.

Die ganze Zeit #301 / 601 werden abgestanden.

@ermik versucht zu helfen, dies in ein verwandtes Problem