Ecco cosa ho trovato mentre cercavo di rispondere a questa identica domanda. Probabilmente non è completo e potrebbe anche essere impreciso su alcuni punti.
In breve, RQ è progettato per essere tutto più semplice. Il sedano è progettato per essere più robusto. Sono entrambi eccellenti.
- Documentazione. La documentazione di RQ è completa senza essere complessa e rispecchia la semplicità generale del progetto:non ti senti mai perso o confuso. Anche la documentazione di Celery è completa, ma aspettati di rivisitarla parecchio quando imposti le cose per la prima volta poiché ci sono troppe opzioni da interiorizzare
-
Monitoraggio. Celery's Flower e la dashboard RQ sono entrambi molto semplici da configurare e ti forniscono almeno il 90% di tutte le informazioni che vorresti mai
-
Supporto del broker. Il sedano è il chiaro vincitore, RQ supporta solo Redis. Ciò significa meno documentazione su "cos'è un broker", ma significa anche che non puoi cambiare broker in futuro se Redis non funziona più per te. Ad esempio, Instagram ha considerato sia Redis che RabbitMQ con Celery. Questo è importante perché diversi broker hanno garanzie diverse, ad es. Redis non può (al momento della scrittura) garantisci al 100% che i tuoi messaggi vengano consegnati.
-
Code prioritarie. Il modello della coda di priorità di RQ è semplice ed efficace:i lavoratori leggono dalle code in ordine. Il sedano richiede la rotazione di più lavoratori da consumare da code diverse. Entrambi gli approcci funzionano
-
Supporto per il sistema operativo. Celery è il chiaro vincitore qui, poiché RQ funziona solo su sistemi che supportano
forkper esempio. Sistemi Unix -
Supporto linguistico. RQ supporta solo Python, mentre Celery ti consente di inviare attività da una lingua a una lingua diversa
-
API. Il sedano è estremamente flessibile (backend di risultati multipli, bel formato di configurazione, supporto per la tela del flusso di lavoro) ma naturalmente questa potenza può creare confusione. Al contrario, l'API RQ è semplice.
-
Supporto per sottoattività. Celery supporta attività secondarie (ad es. creazione di nuove attività da attività esistenti). Non so se RQ lo fa
-
Comunità e stabilità. Il sedano è probabilmente più affermato, ma sono entrambi progetti attivi. Al momento della scrittura, Celery ha ~ 3500 stelle su Github mentre RQ ne ha ~ 2000 ed entrambi i progetti mostrano uno sviluppo attivo
Secondo me, Celery non è così complesso come la sua reputazione potrebbe farti credere, ma dovrai RTFM.
Quindi, perché qualcuno dovrebbe essere disposto a scambiare il sedano (probabilmente più completo) con RQ? Nella mia mente, tutto si riduce alla semplicità. Limitandosi a Redis+Unix, RQ fornisce una documentazione più semplice, una base di codice più semplice e un'API più semplice. Ciò significa che tu (e i potenziali contributori al tuo progetto) potete concentrarvi sul codice a cui tenete, invece di dover conservare i dettagli sul sistema della coda delle attività nella memoria di lavoro. Abbiamo tutti un limite al numero di dettagli che possono essere nella nostra testa contemporaneamente e, eliminando la necessità di mantenere i dettagli della coda delle attività lì, RQ consente di tornare al codice che ti interessa. Tale semplicità va a scapito di funzionalità come code di attività interlinguistiche, ampio supporto del sistema operativo, garanzie di messaggi affidabili al 100% e capacità di cambiare facilmente broker di messaggi.
