¿Cuál es la mejor forma de organizar los procesos de trabajo en Rails?

Question

Con frecuencia tengo algún código que se debe ejecutar ya sea en una programación o como un proceso en segundo plano con algunos parámetros. El elemento común es que se ejecutan fuera del proceso de envío, pero necesitan acceso al entorno Rails (y posiblemente a los parámetros que se pasan).

¿Cuál es una buena manera de organizar esto y por qué? Si desea usar un plugin o gema en particular, explique por qué lo encuentra conveniente; no se limite a enumerar un plugin que utilice.

Answer 1

Para mí, no querer mantener una gran cantidad de infraestructura adicional es una prioridad clave, así que he utilizado colas respaldadas por bases de datos que se ejecutan fuera de Rails.

En mi caso, he usado background_job y delayed_job. Con background_job, el trabajador se mantuvo en ejecución a través de cron, por lo que no hubo administración de daemon. Con delayed_job, estoy usando Heroku y dejándoles que se preocupen por eso.

Con delayed_job puede pasar tantos argumentos como necesite su ejecutor.

Delayed::Job.enqueue(MyJob.new(param[:one], param[:two], param[:three]) 

no he encontrado una buena solución a la ejecución de las cosas en un horario, aparte de usar script/runner a través de cron (yo prefiero usar script/runner más de una tarea Rake porque me resulta más fácil para probar el código).

Nunca tuve que tener un proceso de fondo programado regularmente que necesitaba acceso a una solicitud de Rails en particular, así que no ha sido un gran problema.

Sé que hay otros sistemas más fríos con más funciones, pero esto funcionó bien para mí y me ayuda a evitar la creación de muchos servicios nuevos para administrar.

Answer 2

Tengo un sistema que recibe solicitudes y luego necesita llamar a varios sistemas externos que usan servicios web. Algunas de estas solicitudes tardan más de lo que se puede esperar que espere un usuario y utilizo un sistema de colas empresariales (activemq) para manejar estas solicitudes.

Estoy usando el complemento ActiveMessaging para hacer esto. Esto me permite ordenar la solicitud y colocarla en una cola para procesamiento asíncrono con acceso a los datos de solicitud, sin embargo, tendrá que escribir un servicio de votación si desea esperar la respuesta.

He visto a Ryan Bates con railscast en Starling and Workling y se ven prometedores pero no los he usado.

Answer 3

Para las tareas programadas regularmente, solo uso las tareas de rake. Es simple, fácil de probar, de fácil comprensión y se integra bien con el entorno Rails. A continuación, ejecute estas tareas de rake con un trabajo cron en el intervalo que necesite (utilizo whenever para administrar estos trabajos porque estoy un poco analfabeto de cron).

Answer 4

Realmente no me gustan las gemas como delayed_job y background_job que persisten en una base de datos con el fin de ejecutar trabajos asincrónicos. Simplemente me parece sucio. Cosas transitorias no pertenecen a una base de datos.

Soy un gran admirador de las colas de mensajes para tratar tareas asincrónicas, incluso cuando no se necesita una escalabilidad masiva. Tal como lo veo, las colas de mensajes son la "lingua franca" ideal para sistemas complejos. Con una cola de mensajes, en la mayoría de los casos, no tiene restricciones sobre las tecnologías o los idiomas que están involucrados en lo que sea que esté construyendo.Los beneficios del uso de cola de mensajes de baja concurrencia es probablemente más notable en un entorno "empresarial" donde la integración siempre es un dolor masivo. Además, las colas de mensajes son ideales cuando su flujo de trabajo asincrónico implica múltiples pasos. RabbitMQ es mi favorito personal.

Por ejemplo, considere la situación en la que está la construcción de un motor de búsqueda. Las personas pueden enviar URI para indexar. Obviamente, no desea recuperar e indexar la página en solicitud. Así que construye alrededor de una cola de mensajes: el objetivo de envío de formularios toma el URI, lo arroja a la cola de mensajes para ser indexado. El siguiente proceso de araña disponible saca el URI de la cola, recupera la página, encuentra todos los enlaces, los vuelve a colocar en la cola si no se conocen y guarda el contenido en caché. Finalmente, se envía un nuevo mensaje a una segunda cola para que el proceso del indexador trate el contenido en caché. El proceso del indexador saca ese mensaje de la cola e indexa el contenido en caché. Muy simplificado, por supuesto, los motores de búsqueda son un montón de trabajo, pero entiendes la idea.

En cuanto a los demonios reales, obviamente, soy parcial de mi propia biblioteca (ChainGang), pero en realidad es solo una envoltura alrededor de Kernel.fork() que te da un lugar conveniente para manejar la configuración y el código de desmontaje. Tampoco está terminado todavía. La pieza del daemon es mucho menos importante que la cola de mensajes, en realidad.

En cuanto al entorno de Rails, bueno, eso es probablemente lo mejor deja como ejercicio para el lector, ya que el uso de memoria va a ser un factor significativo lo que con el proceso de larga duración. No quiere cargar nada que no tenga que hacer. A propósito, esta es un área en la que DataMapper patea el trasero de ActiveRecord. La inicialización del entorno está bien documentada, y hay muchas menos dependencias que entran en juego, lo que hace que todo el kit y el caboodle sean significativamente más realistas.

Lo único que no me gusta de cron + rake es que virtualmente se garantiza que rake imprime en salida estándar, y cron tiende a ser excesivamente hablador si tus trabajos cron producen resultados. Me gusta poner todas mis tareas cron en un directorio apropiadamente nombrado, luego hacer una tarea de rake que las envuelve, por lo que es trivial ejecutarlas manualmente. Es una pena que Rake haga esto, porque realmente preferiría tener la opción de aprovechar las dependencias. En cualquier caso, solo apunta a cron directamente en los scripts en lugar de ejecutarlos a través de cron.

Actualmente estoy en el medio de la construcción de una aplicación web que depende en gran medida de los procesos asíncronos, y tengo que decir que estoy muy, muy contento de haber decidido no utilizar Rails.