Resque o Gearman - scegliere lo strumento giusto per i lavori in background

Question

Stiamo sviluppando un'applicazione web in cui con circa il 50% delle richieste di scrittura, finiamo per spingere i dati in più archivi dati e inserendo e aggiornando un numero significativo di record in tali archivi dati . Per migliorare i tempi di risposta, vogliamo elaborare tali richieste in modo asincrono in background.

La nostra applicazione Web viene scritta in Ruby on Rails.

Due soluzioni a cui sono incline sono Resque e Gearman.

Resque: Ulteriori informazioni qui: http://github.com/blog/542-introducing-resque Resque sembra molto adatto per Ruby ed è specificamente pensato per l'elaborazione dei processi in background. "I lavori in background possono essere qualsiasi classe o modulo Ruby che risponde all'esecuzione. Le classi esistenti possono essere facilmente convertite in lavori in background oppure è possibile creare nuove classi specificatamente per fare lavoro."

Gearman: non è specificamente pensato solo per lavori in background per l'elaborazione asincrona, ma è qualcosa che può sicuramente fare. Apparentemente più robusto, o almeno così sembra. Un altro vantaggio di Gearman è che mentre il codice client potrebbe essere in Ruby, il codice worker potrebbe essere, diciamo, PHP. Anche se al momento siamo completamente app Ruby on Rails, chissà se in futuro potremmo voler usare PHP o qualcos'altro a seconda del lavoro da svolgere.

Cosa mi consiglia? Hai esperienza con uno dei due? Quali sono le vere sfide della produzione della vita dovrei tenere a mente mentre scelgo tra i due? E sto anche confrontando la mela con la mela qui?

Answer 1

Ho una certa esperienza con Gearman quando stavo cercando un meccanismo di forking distribuito che potesse offrire una distribuzione del carico di lavoro per asincrona. elaborazione in un ambiente cluster.

Posso dirti che si lavora in un caso "simulato" in cui l'elaborazione asincrona è stata inviata a 2 macchine (2 lavoratori su ogni macchina = 4 lavoratori). Non in uno scenario reale (qualunque cosa ti dica). Lo scenario reale verrà implementato quando le "simulazioni" forniscono informazioni utili.

Il meccanismo che sceglierete è un solo fattore nella distribuzione del carico di lavoro, quindi assicuratevi di non finire con dati corrotti o non validi quando i "Lavoratori" distribuiti che lavorano in parallelo iniziano a scrivere sui datastore .

Suggerirei di adottare l'approccio di "simulazione" che ho fatto e di eseguire i test prima di decidere quale utilizzare.

saluti,