Dit is wat ik heb gevonden terwijl ik probeerde exact dezelfde vraag te beantwoorden. Het is waarschijnlijk niet volledig en kan op sommige punten zelfs onnauwkeurig zijn.
Kortom, RQ is ontworpen om overal eenvoudiger te zijn. Selderij is ontworpen om robuuster te zijn. Ze zijn allebei uitstekend.
- Documentatie. De documentatie van RQ is uitgebreid zonder complex te zijn en weerspiegelt de algehele eenvoud van het project - u voelt zich nooit verloren of verward. De documentatie van Celery is ook uitgebreid, maar verwacht dat je er vaak naar zult kijken als je voor het eerst dingen instelt, want er zijn te veel opties om te internaliseren
-
Toezicht houden. Celery's Flower en het RQ-dashboard zijn beide zeer eenvoudig in te stellen en geven u ten minste 90% van alle informatie die u ooit zou willen
-
Ondersteuning makelaar. Celery is de duidelijke winnaar, RQ ondersteunt alleen Redis. Dit betekent minder documentatie over "wat is een makelaar", maar betekent ook dat u in de toekomst niet van makelaar kunt wisselen als Redis niet langer voor u werkt. Instagram heeft bijvoorbeeld zowel Redis als RabbitMQ overwogen met Celery. Dit is belangrijk omdat verschillende makelaars verschillende garanties hebben, b.v. Redis kan niet (op het moment van schrijven) garanderen 100% dat uw berichten worden afgeleverd.
-
Prioritaire wachtrijen. Het prioriteitswachtrijmodel van RQ is eenvoudig en effectief - werknemers lezen op volgorde uit wachtrijen. Selderij vereist het draaien van meerdere werknemers om uit verschillende wachtrijen te consumeren. Beide benaderingen werken
-
OS-ondersteuning. Celery is hier de duidelijke winnaar, aangezien RQ alleen draait op systemen die
forkondersteunen bijv. Unix-systemen -
Taalondersteuning. RQ ondersteunt alleen Python, terwijl je met Celery taken van de ene taal naar een andere taal kunt sturen
-
API. Celery is extreem flexibel (backends met meerdere resultaten, mooi configuratieformaat, ondersteuning voor workflowcanvas) maar deze kracht kan natuurlijk verwarrend zijn. Daarentegen is de RQ api eenvoudig.
-
Ondersteuning van subtaken. Celery ondersteunt subtaken (bijvoorbeeld het maken van nieuwe taken vanuit bestaande taken). Ik weet niet of RQ dat doet
-
Gemeenschap en stabiliteit. Selderij is waarschijnlijk meer ingeburgerd, maar het zijn beide actieve projecten. Op het moment van schrijven heeft Celery ~3500 sterren op Github, terwijl RQ ~2000 heeft en beide projecten laten een actieve ontwikkeling zien
Naar mijn mening is Celery niet zo complex als zijn reputatie je doet vermoeden, maar je zult RTFM moeten doen.
Dus waarom zou iemand bereid zijn om de (aantoonbaar meer complete) Celery in te ruilen voor RQ? In mijn ogen komt het allemaal neer op de eenvoud. Door zich te beperken tot Redis+Unix, biedt RQ eenvoudigere documentatie, eenvoudigere codebase en een eenvoudigere API. Dit betekent dat u (en potentiële bijdragers aan uw project) zich kunnen concentreren op de code waar u om geeft, in plaats van dat u details over het taakwachtrijsysteem in uw werkgeheugen moet bewaren. We hebben allemaal een limiet aan het aantal details dat tegelijk in ons hoofd kan zijn, en door de noodzaak om de details van de taakwachtrij daarin te bewaren, kunt u met RQ terugkeren naar de code waar u om geeft. Die eenvoud gaat ten koste van functies zoals taakwachtrijen tussen verschillende talen, brede OS-ondersteuning, 100% betrouwbare berichtgaranties en de mogelijkheid om gemakkelijk van berichtmakelaar te wisselen.