Pro e contro nell'utilizzo di Celery vs. RQ [chiuso]


101

Attualmente sto lavorando a un progetto Python che richiede l'implementazione di alcuni processi in background (principalmente per l'invio di e-mail e gli aggiornamenti del database pesante). Uso Redis per il task broker. Quindi a questo punto ho due candidati: Celery e RQ . Ho avuto una certa esperienza con queste code di lavoro, ma voglio chiedere a voi ragazzi di condividere la vostra esperienza nell'utilizzo di questi strumenti. Così.

  1. Quali pro e contro usare Celery vs. RQ.
  2. Eventuali esempi di progetti / attività adatti all'uso di Celery vs. RQ.

Il sedano sembra piuttosto complicato ma è una soluzione completa. In realtà non credo di aver bisogno di tutte queste funzionalità. Dall'altro lato RQ è molto semplice (es. Configurazione, integrazione), ma sembra che manchi di alcune funzioni utili (es. Revoca di attività, ricaricamento automatico del codice)


3
Sfortunatamente, questo tipo di domanda non si adatta al formato di questo sito, vedi le FAQ . Domande come queste tendono a portare a risposte vaghe che sono anche obsolete molto rapidamente. Se possiamo aiutarti con un problema specifico, sentiti libero di pubblicare un'altra domanda!
Martijn Pieters

A proposito, mi sembra che tu possa revocare le attività, anche con rq-dashboard
Peter Kilczuk,

Risposte:


141

Ecco cosa ho trovato cercando di rispondere alla stessa identica domanda. Probabilmente non è completo e potrebbe anche essere impreciso su alcuni punti.

In breve, RQ è progettato per essere più semplice tutto intorno. Il sedano è progettato per essere più robusto. Sono entrambi eccellenti.

  • Documentazione. La documentazione di RQ è completa senza essere complessa e rispecchia la semplicità complessiva del progetto: non ti senti mai perso o confuso. Anche la documentazione di Celery è completa, ma aspettati di rivederla spesso quando imposti le cose per la prima volta poiché ci sono troppe opzioni da interiorizzare
  • Monitoraggio. Celery's Flower e il dashboard RQ sono entrambi molto semplici da configurare e ti danno almeno il 90% di tutte le informazioni che vorresti

  • Supporto del broker. Celery è il chiaro vincitore, RQ supporta solo Redis. Ciò significa meno documentazione su "cosa è un broker", ma significa anche che non puoi cambiare broker in futuro se Redis non lavora più per te. Ad esempio, Instagram ha considerato sia Redis che RabbitMQ con Celery . Questo è importante perché diversi broker hanno garanzie diverse, ad esempio Redis non può (al momento della scrittura) garantire al 100% che i tuoi messaggi vengano consegnati.

  • Code prioritarie. Il modello di coda di priorità di RQ è semplice ed efficace: i lavoratori leggono dalle code in ordine . Il sedano richiede la rotazione di più lavoratori per consumare da diverse code. Entrambi gli approcci funzionano

  • Supporto OS. Celery è il chiaro vincitore qui, poiché RQ funziona solo su sistemi che supportano, forkad esempio, sistemi Unix

  • Supporto linguistico. RQ supporta solo Python, mentre Celery ti consente di inviare attività da una lingua a una lingua diversa

  • API. Celery è estremamente flessibile (più backend dei risultati, bel formato di configurazione, supporto per la tela del flusso di lavoro) ma naturalmente questo potere può creare confusione. Al contrario, l'API RQ è semplice.

  • Supporto per sottoattività. Celery supporta le sottoattività (ad esempio, la creazione di nuove attività dall'interno di attività esistenti). Non so se RQ lo fa

  • Comunità e stabilità. Il sedano è probabilmente più consolidato, 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, il sedano non è così complesso come la sua reputazione potrebbe farti credere, ma dovrai fare RTFM.

Quindi, perché qualcuno dovrebbe essere disposto a scambiare il sedano (probabilmente più completo) con RQ? Nella mia mente, tutto si riduce alla semplicità. Limitando se stesso 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) puoi concentrarti sul codice che ti interessa, invece di dover mantenere i dettagli sul sistema della coda delle attività nella tua memoria di lavoro. Abbiamo tutti un limite al numero di dettagli che possono essere nella nostra testa contemporaneamente e, rimuovendo la necessità di mantenere i dettagli della coda delle attività in RQ, torniamo al codice che ti interessa. Questa 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.


1
Subtask support. Celery supports subtasks (e.g. creating new tasks from within existing tasks). I don't know if RQ does Per quanto riguarda il 24.05.2019, RQ supporta anche le attività secondarie (chiamata interna per la coda).
eserdk

1

Il sedano non è così complicato. Fondamentalmente, esegui la configurazione passo passo da tutorials, crei celeryun'istanza, decori la tua funzione con @celery.taskquindi esegui l'attività con my_task.delay(*args, **kwargs).

A giudicare dalla tua valutazione, sembra che tu debba scegliere tra caratteristiche (chiave) mancanti o avere qualche eccesso in giro. Non è una scelta troppo difficile nel mio libro.


46
Sono totalmente in disaccordo con la tua valutazione. Ho lottato per un paio di settimane per far funzionare Celery con successo sul mio server Debian, anche dopo aver letto gran parte della documentazione e numerosi post sul blog. Il problema principale che ho avuto è stato che se hai sbagliato qualcosa nella tua configurazione, Celery non ha fornito alcun feedback su quale potrebbe essere il problema. E quando finalmente l'ho fatto funzionare, ho iniziato a ottenere qualche tipo di OSError OS in fondo allo stack Celery. Ho pubblicato un problema su GitHub ma nessuno mi ha aiutato. Non toccherei mai più Celery con un palo di dieci piedi.
Ray

2
Effin 'OSError man. No such file or directory. Non ho idea da dove cominciare. Proverò RQ per la prima volta stasera.
MiniGunnR
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.