Colas de mensajes en Ruby on Rails
Qué colas de mensajes usan las personas para sus aplicaciones Rails y cuál fue la fuerza impulsora detrás de la decisión de elegirla. ¿La última publicidad de Twitter sobre su cola en casa Starling falling down afecta a cualquier decisión de diseño existente?
Estoy trabajando en una aplicación que necesitará una cola de mensajes para procesar algunas tareas en segundo plano, no he hecho mucho de esto, y la mayoría de las cosas que he visto en el pasado ha sido sobre Starling y Workling, y para ser honesto, la aplicación no es muy grande y esta solución probablemente sería suficiente, pero me encantaría tener experiencia integrando la mejor solución posible, ya que estoy seguro de que integraré una en una aplicación más grande en algún momento.
¿Qué colas de mensajes sugerirías para una aplicación Rails???
EDIT: Gracias por las sugerencias, voy a ver algunas de ellas este fin de semana.
EDITAR de nuevo: He echado un vistazo y un poco abrumado por la elección. Sin embargo, voy a ir sobre la integración de RabbitMQ con Trabajando en la aplicación que estoy construyendo, entonces si alguna vez necesito algún conocimiento sobre una cola rápida, entonces tendré esto y sabré si se ajusta o no a mis necesidades.
EDITAR: Encontrar más y más que DJ me conviene muy bien, si alguna vez "superarlo" en un sitio diría que Resque es donde me dirigiría.
EDIT: (Dic 2014) Así que ha pasado mucho tiempo desde que pregunté esto, pero veo que todavía tiene algunas vistas o algunos votos, así que pensé en actualizarlo en mi enfoque ahora cuando se trata de mi elección de trabajadores de fondo.
En mi opinión actualmente la mejor manera de ejecutar trabajos en segundo plano en Ruby es usando Sidekiq. Mucha gente ha elogiado a Sidekiq por sus trabajadores roscados en lugar de procesar por trabajador, que puede usar significativamente menos memoria que Resque, que estaba usando antes de Sidekiq. Esto es bueno, pero para mí esta no era la característica asesina. Al usar Sidetiq con Sidekiq, la programación de trabajos es tan trivial que me cambié y nunca he mirado atrás, con mucho, la programación más fácil de trabajos que he utilizado y ha hecho que Sidekiq sea muy fácil de usar.
7 answers
Como actualización G GitHub se ha movido a Resque en Redis en lugar de Trabajo retrasado. Sin embargo, todavía recomiendan delayed_job para configuraciones más pequeñas:
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-07-31 12:15:48
Chris Wanstrath de github estuvo en el SF Ruby meetup recientemente, hablando sobre su cola. Probaron Starling, habichuelas mágicas y algunas otras variantes antes de decidirse por delayed_job de Shopify. Son bastante agresivos con su uso de backgrounding.
Aquí hay una entrada del blog del año pasado que habla sobre su paso a DJ.
Donde estoy ahora hicimos el nuestro hace varios años, pero estoy tomando algunas ideas de DJ para mejorar el manejo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-04-06 17:39:13
Recomendaría delayed-job como una solución simple si no espera ninguna carga pesada. Pros: fácil de configurar, fácil de monitorear, código simple, no tiene ninguna dependencia externa. Anteriormente usábamos ActiveMessaging (con ActiveMQ y stomp), pero fue un exceso para nuestro proyecto, por lo que cambiamos a delayed_job por su simplicidad.
De todos modos, si necesita una solución muy madura y rápida, ActiveMQ es una muy buena opción. Si no quieres pasar demasiado tiempo en el mantenimiento de la solución de colas de mensajes a gran escala que realmente no necesita, delayed_job es un camino a seguir. Aquí hay un buen artículo sobre la experiencia de Scribd con ActiveMQ.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-04-16 13:23:14
Aquí hay algunas soluciones Ruby / Rails, una o más de estas pueden ser una buena opción dependiendo de sus necesidades:
Http://xph.us/software/beanstalkd
Http://rubyforge.org/forum/forum.php?forum_id=19781
Http://backgroundrb.rubyforge.org
Y, una solución alojada de Amazon que haría una gran cola para compartir entre Ruby/Rails y otros componentes de una mayor sistema:
Espero que esto ayude!
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-04-06 15:22:07
El servidor de mensajería al que podrías querer ir es RabbitMQ. Erlang coolness, AMQP, good Ruby libs.
Http://www.bestechvideos.com/2008/12/09/rabbitmq-an-open-source-messaging-broker-that-just-works
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-04-16 13:31:09
Rany Keddo dio una útil presentación sobre Starling + Workling en RailsConf Europe el año pasado. Comparó las diferentes soluciones disponibles en ese momento.
El último movimiento de Twitter lejos de Starling + Workling probablemente no significa mucho para la aplicación rails regular. Tienen muchos más problemas de escala y probablemente tienen problemas heredados con su almacén de datos que les impide escalar más allá de su implementación actual.
Beanstalkd es un buen alternativa, simplemente porque se ejecuta como un demonio y tiene envoltorios en otros lenguajes de scripting (si cambia de dirección en el futuro o tiene diferentes componentes escritos en otros lenguajes).
Este link también tiene una buena comparación de los pros-contras de las diversas soluciones rails disponibles.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-04-06 18:49:36
Utilizo background_jobque como delayed_job es una cola basada en bases de datos.
Una base de datos hace una cola OK siempre y cuando no esté haciendo demasiado tráfico de entrada y salida.
La razón por la que me gusta background_job (y delayed_job) es que no requieren un proceso separado. Pueden correr a través de Cron. Para mí, esto es de importancia clave porque mis necesidades de mensajería son aún más simples que mis escasas habilidades de administrador de sistemas.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-04-06 22:52:03