Code messaggi in Ruby on Rails

Question

Quali code di messaggi utilizzano le persone per le loro app Rails e quale è stata la forza trainante della decisione di sceglierlo. L'ultima pubblicità di Twitter sulla loro coda in casa, la caduta di Starling, influisce sulle decisioni di progettazione esistenti.

Sto lavorando a un'app che richiederà una coda di messaggi per elaborare alcune attività in background, non ho fatto molto di questo, e la maggior parte delle cose che ho visto in passato sono state su Starling e Workling, e per essere onesti, l'applicazione non è molto grande e questa soluzione probabilmente sarebbe sufficiente, ma mi piacerebbe avere esperienza nell'integrare la migliore soluzione possibile in quanto sono sicuro che a un certo punto ne integrerò una in un'applicazione più grande.

Quali code di messaggi suggeriresti per un'app Rails ???

EDIT: Grazie per i suggerimenti, ho intenzione di guardare alcuni di loro questo fine settimana.

MODIFICA Ancora: ho dato un'occhiata in giro e un po 'sopraffatto dalla scelta. Sto comunque andando a integrare RabbitMQ con Workling nell'app che sto costruendo, quindi se mai avrò bisogno di qualche conoscenza su una coda veloce, avrò questo e so se si adatta alle mie esigenze.

MODIFICA: trovare sempre più DJ che mi si addice bene, se mai "divento" su un sito, direi che Resque è dove vorrei andare.

EDIT: (Dic 2014) Quindi è passato molto tempo da quando ho chiesto questo, ma vedo che ottiene ancora alcuni punti di vista o alcuni voti, quindi ho pensato di aggiornarlo sul mio approccio ora quando si tratta del mio scelta dei lavoratori in background.

A mio parere, attualmente il modo migliore per eseguire processi in background in Ruby è utilizzare Sidekiq. Un sacco di gente ha davvero lodato Sidekiq per i suoi dipendenti filettati piuttosto che per processo per lavoratore, che può utilizzare una quantità di memoria significativamente inferiore a quella di Resque, che stavo usando prima di Sidekiq. Questo è buono ma per me questa non era la caratteristica killer. Usando Sidetiq con Sidekiq, la pianificazione dei lavori è così banale che sono passato e non ho mai guardato indietro, di gran lunga la più semplice pianificazione dei lavori che ho usato e ha reso Sidekiq un gioco da ragazzi.

Answer 1

come aggiornamento - GitHub sono trasferiti a Resque su Redis, invece di lavoro ritardata. Tuttavia si consiglia ancora delayed_job per installazioni più piccole:

https://github.com/resque/resque

Answer 2

Ecco alcune soluzioni di Ruby/Rails, uno o più di questi possono essere una buona misura a seconda delle esigenze:

http://xph.us/software/beanstalkd

http://rubyforge.org/forum/forum.php?forum_id=19781

http://backgroundrb.rubyforge.org

E, un soluzione hosted di Amazon che farebbe una grande coda per la condivisione tra Ruby/Rails e altri componenti di un sistema più grande:

http://aws.amazon.com/sqs

Spero che questo aiuti!

Answer 3

Chris Wanstrath di github è stato recentemente al meeting SF Ruby, parlando della loro coda. Hanno provato Starling, beanstalk e alcune altre varianti prima di stabilirsi su delayify_job di Shopify. Sono piuttosto aggressivi con il loro uso dello sfondo.

Ecco uno blog post from last year che parla del passaggio a DJ.

Dove mi trovo ora abbiamo laminato il nostro diversi anni fa, ma sto prendendo alcune idee da DJ per migliorare la gestione.

Answer 4

Rany Keddo ha dato uno useful presentation su Starling + Workling a RailsConf Europe l'anno scorso. Ha confrontato le diverse soluzioni disponibili al momento.

L'ultimo spostamento di Twitter da Starling + Workling probabilmente non significa molto per l'app di rotaie regolari. Hanno molti più problemi di scala e probabilmente hanno problemi legacy con il loro datastore che impedisce loro di ridimensionare la loro attuale implementazione.

Beanstalkd è una buona alternativa, semplicemente perché viene eseguito come un demone e dispone di wrapper in altri linguaggi di scripting (se si cambia direzione in futuro o si hanno componenti diversi scritti in altre lingue).

Questo link ha anche un buon confronto tra i vantaggi delle varie soluzioni di guide disponibili.

Answer 5

Io uso background_job che come delayed_job è una coda basata su database.

Un database fa una coda OK a condizione che non si stia facendo troppo traffico dentro e fuori.

Il motivo per cui mi piace background_job (e delayed_job) è che non richiedono un processo separato. Possono correre attraverso cron. Per me, questo è di fondamentale importanza perché i miei bisogni di messaggistica sono ancora più semplici delle mie magre abilità di sysadmin.

Answer 6

Suggerirei delayed-job come una soluzione semplice e semplice se non si prevede alcun carico pesante. Pro: facile da configurare, facile da monitorare, codice semplice, non ha alcuna dipendenza esterna. Precedentemente abbiamo usato ActiveMessaging (con ActiveMQ e stomp), ma era un overkill per il nostro progetto, quindi siamo passati a delayed_job per la sua semplicità.

In ogni caso, se avete bisogno di una soluzione molto matura e veloce, ActiveMQ è una scelta molto buona. Se non vuoi spendere troppo tempo per mantenere la soluzione di accodamento dei messaggi su vasta scala di cui non hai veramente bisogno, delayed_job è la strada da percorrere. Ecco uno good article sull'esperienza di Scribd con ActiveMQ.

Answer 7

Il server di messaggistica che si potrebbe desiderare di fare è RabbitMQ. Freschezza di Erlang, AMQP, buone librerie di Ruby.

http://www.bestechvideos.com/2008/12/09/rabbitmq-an-open-source-messaging-broker-that-just-works