Colas de mensajes en Ruby on Rails

Question

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 elegirlo. ¿La última publicidad de Twitter sobre la cola interna de Starling afecta las decisiones de diseño existentes?

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 han sido sobre Starling y Workling, y para ser sincero, la aplicación no es muy grande y esta solución probablemente sea suficiente, pero me encantaría obtener experiencia integrando la mejor solución posible ya que estoy seguro de que voy a integrar una en una aplicación más grande en algún momento.

¿Qué cola de mensajes sugeriría para una aplicación de Rails ???

EDIT: Gracias por las sugerencias, voy a ver algunos de ellos este fin de semana.

EDITAR De nuevo: he echado un vistazo y estoy un poco abrumado por la elección. Sin embargo, voy a continuar integrando RabbitMQ con Workling en la aplicación que estoy construyendo, y si alguna vez necesito algún conocimiento sobre una cola rápida, tendré esto y sabré si se ajusta o no a mis necesidades.

EDIT: Encontrar más y más que el DJ me sienta bien, si alguna vez lo "supero" en un sitio, diría que Resque es a donde iría.

EDIT: (diciembre de 2014) Ha pasado mucho tiempo desde que pregunté esto, pero veo que todavía tiene algunos puntos de vista o algunos votos, así que pensé que lo actualizaría en mi enfoque ahora cuando se trata de mi elección de trabajadores de base.

En mi opinión, actualmente la mejor manera de ejecutar trabajos en segundo plano en Ruby es utilizando Sidekiq. Mucha gente realmente elogió a Sidekiq por sus trabajadores enhebrados en lugar de procesar por trabajador, lo que puede consumir mucha menos memoria que los productos como Resque, que estaba usando antes de Sidekiq. Esto es bueno, pero para mí esta no era la característica más importante. Al utilizar Sidetiq con Sidekiq, la programación de trabajos es tan trivial que cambié y nunca he mirado hacia atrás, la planificación de trabajos más sencilla que he utilizado y que ha hecho que Sidekiq sea fácil de usar.

Answer 1

Como una actualización - GitHub se han trasladado a Resque en Redis lugar de trabajo retardado. Sin embargo, todavía recomiendan delayed_job para configuraciones más pequeñas:

https://github.com/resque/resque

Answer 2

Estas son algunas soluciones de Ruby/Rails, uno o más de estos pueden ser un buen ajuste en función 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 hospedada de Amazon que sería una excelente cola para compartir entre Ruby/Rails y otros componentes de un sistema más grande:

http://aws.amazon.com/sqs

Hope this helps!

Answer 3

Chris Wanstrath de github estuvo en la reunión de SF Ruby recientemente, hablando de su cola. Probaron Starling, Beanstalk y algunas otras variantes antes de decidirse por el trabajo retrasado de Shopify. Son bastante agresivos con el uso de fondos.

Aquí hay un blog post from last year que habla sobre su cambio a DJ.

Donde estoy ahora hicimos autostop hace varios años, pero estoy tomando algunas ideas de DJ para mejorar el manejo.

Answer 4

Rany Keddo dio un useful presentation sobre Starling + Workling en RailsConf Europe el año pasado. Comparó las diferentes soluciones disponibles en ese momento.

El último movimiento de Twitter fuera de Starling + Workling probablemente no signifique demasiado para la aplicación de rieles normales. Tienen muchos más problemas de escala y probablemente tengan problemas heredados con su almacén de datos que les impide escalar más allá de su implementación actual.

Beanstalkd es una buena alternativa, simplemente porque se ejecuta como un daemon y tiene envoltorios en otros lenguajes de scripting (si cambia de dirección en el futuro o tiene componentes diferentes escritos en otros idiomas).

Este link también tiene una buena comparación de pros y contras de las diversas soluciones de rieles disponibles.

Answer 5

Yo uso background_job que como delayed_job es una cola basada en la base de datos.

Una base de datos crea una cola OK siempre que no esté haciendo demasiado tráfico entrando y saliendo.

La razón por la que me gusta background_job (y delayed_job) es que no requieren un proceso por 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 exiguas habilidades de administrador de sistemas.

Answer 6

Recomendaría delayed-job como una solución muerta simple si no espera ninguna carga pesada. Pros: fácil de configurar, fácil de monitorear, código simple, no tiene dependencias externas. Anteriormente utilizamos ActiveMessaging (con ActiveMQ y stomp), pero fue un exceso para nuestro proyecto, por lo que cambiamos a retrayed_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 quiere perder demasiado tiempo en mantener la solución de colas de mensajes a gran escala que realmente no necesita, la tarea de retraso es un camino a seguir. Aquí hay un good article sobre la experiencia de Scribd con ActiveMQ.

Answer 7

El servidor de mensajería es posible que desee ir a RabbitMQ. Frialdad de Erlang, AMQP, buenas libs de Ruby.

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