ruby on rails - Resque o Gearman: elegir la herramienta adecuada para trabajos en segundo plano
ruby-on-rails asynchronous (1)
Estamos desarrollando una aplicación web en la que con aproximadamente el 50% de las solicitudes de escritura, terminamos empujando datos a múltiples almacenes de datos e insertando y actualizando una cantidad significativa de registros en esos almacenes de datos. Para mejorar el tiempo de respuesta, queremos procesar dichas solicitudes de forma asincrónica en segundo plano.
Nuestra aplicación web está siendo escrita en Ruby on Rails.
Dos soluciones a las que me inclino son Resque y Gearman.
Resque: Más información aquí: http://github.com/blog/542-introducing-resque Resque parece muy adecuado para Ruby, y está específicamente destinado para el procesamiento de trabajos en segundo plano. "Los trabajos en segundo plano pueden ser cualquier clase o módulo de Ruby que responda para funcionar. Sus clases existentes pueden convertirse fácilmente a trabajos en segundo plano o puede crear nuevas clases específicamente para hacer el trabajo".
Gearman: No está específicamente destinado solo para trabajos en segundo plano para el procesamiento asincrónico, pero eso es algo que definitivamente puede hacer. Aparentemente más robusto, o eso parece. Otra ventaja de Gearman es que, aunque su código de cliente podría estar en Ruby, el código de trabajador podría estar en, digamos, PHP. Aunque ahora mismo estamos completamente en la aplicación Ruby on Rails, quién sabe si en el futuro podríamos usar PHP u otra cosa dependiendo del trabajo en cuestión.
¿Qué recomendarías? ¿Tienes experiencia con cualquiera de los dos? ¿Qué desafíos de producción en la vida real debo tener en cuenta al elegir entre los dos? ¿Y estoy incluso comparando manzana con manzana aquí?
Tengo cierta experiencia con Gearman cuando estaba buscando un mecanismo de horquilla distribuida que pudiera ofrecer una distribución de carga de trabajo para asincrónico. procesamiento en un entorno agrupado.
Puedo decir que se trabajó en un caso "simulado" en el que se envió procesamiento asíncrono a 2 máquinas (2 trabajadores en cada máquina = 4 trabajadores). No en un escenario real (lo que sea que eso te diga). El escenario real se implementará cuando las "simulaciones" brinden información útil.
El mecanismo que va a elegir es solo un Factor en la distribución de la carga de trabajo, por lo tanto, asegúrese de no terminar con datos corruptos o no válidos cuando los "Trabajadores" distribuidos que trabajan en paralelo comiencen a escribir en las áreas de almacenamiento de datos.
Sugeriría tomar el enfoque de "simulación" que hice y hacer tus pruebas antes de decidir cuál utilizar.
Saludos,