Domanda Pro e contro per usare Celery vs. RQ [chiuso]


Attualmente sto lavorando su un progetto Python che richiede l'implementazione di alcuni lavori in background (principalmente per l'invio di e-mail e gli aggiornamenti di database). Io uso Redis per il task broker. Quindi a questo punto ho due candidati: Sedano e RQ. Ho avuto qualche esperienza con queste code di lavoro, ma voglio chiederti ragazzi di condividere la tua esperienza sull'uso di questi strumenti. Così.

  1. Quali sono i pro e i contro di 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 penso di aver bisogno di tutte queste funzionalità. Dall'altro lato RQ è molto semplice (ad esempio configurazione, integrazione), ma sembra che manchi di alcune funzioni utili (ad esempio revoca delle attività, ricaricamento automatico del codice)


58
2017-11-18 14:04


origine


risposte:


Ecco cosa ho trovato mentre cercavo di rispondere a questa stessa identica domanda. Probabilmente non è completo e potrebbe anche essere impreciso su alcuni punti.

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

  • Documentazione. La documentazione di RQ è completo senza essere complesso e rispecchia la semplicità generale del progetto - non ti senti mai perso o confuso. La documentazione di Celery è anche completo, ma aspettatevi di rivederlo parecchio quando si impostano le cose per la prima volta poiché ci sono troppe opzioni per interiorizzare
  • Monitoraggio. Il fiore di sedano 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 "che cos'è un broker", ma significa anche che non puoi cambiare broker in futuro se Redis non funziona più per te. Per 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) garantisce al 100% che i tuoi messaggi vengano consegnati.

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

  • Supporto OS. Celery è il chiaro vincitore qui, poiché RQ funziona solo su sistemi che supportano fork per 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 di risultati, bel formato di configurazione, supporto per il workflow canvas) ma naturalmente questo potere può essere fonte di confusione. Al contrario, l'API RQ è semplice.

  • Supporto per sottotask. Celery supporta le attività secondarie (ad esempio creando nuove attività all'interno delle attività esistenti). Non so se RQ lo fa

  • Comunità e stabilità. Probabilmente il sedano è più consolidato, ma entrambi sono progetti attivi. Al momento della scrittura, Celery ha ~ 3500 stelle su Github mentre RQ ha ~ 2000 ed entrambi i progetti mostrano lo sviluppo attivo

Secondo me, Celery non è così complesso come la sua reputazione potrebbe portarti a credere, ma dovrai RTFM.

Quindi, perché qualcuno dovrebbe essere disposto a scambiare il sedano (probabilmente più completo) per 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 potenziali contributori al tuo progetto) puoi concentrarti sul codice che ti interessa, invece di dover mantenere i dettagli sul sistema delle code delle attività nella tua memoria di lavoro. Abbiamo tutti un limite al numero di dettagli che possono esserci nella nostra testa in una sola volta e, eliminando la necessità di mantenere i dettagli della coda delle attività, RQ consente di tornare al codice che ti interessa. Questa semplicità viene a scapito di funzionalità come code di attività interlinguistiche, ampio supporto del sistema operativo, garanzie di messaggi affidabili al 100% e possibilità di cambiare facilmente i broker di messaggi.


73
2018-04-24 02:54



Il sedano non è così complicato. Al suo interno, si esegue la configurazione passo passo dal tutorials, creare un celery Ad esempio, decorare la tua funzione con @celery.task quindi eseguire l'attività con my_task.delay(*args, **kwargs).

A giudicare dalla tua valutazione, sembra che tu debba scegliere tra carenza di funzionalità (chiave) o eccesso di spazio. Non è una scelta troppo difficile nel mio libro.


1
2017-11-18 16:05