javascript - bull - task queue node js
Procesos en segundo plano en Node.js (6)
¿Cuál es un buen enfoque para manejar procesos en segundo plano en una aplicación NodeJS?
Escenario : después de que un usuario publique algo en una aplicación, quiero procesar los datos, solicitar datos adicionales de recursos externos, etc. Todo esto lleva bastante tiempo, por lo que quiero sacarlo del ciclo de requisitos / res. Lo ideal sería tener una cola de trabajos donde pueda volcar rápidamente un trabajo y un demonio o un corredor de tareas siempre tomará el más antiguo y lo procesará.
En RoR lo hubiera hecho con algo como Trabajo retrasado. ¿Cuál es el equivalente de nodo de esta API?
Los trabajos en segundo plano no están directamente relacionados con el trabajo de su servicio web, por lo que no deberían estar en el mismo proceso. A medida que escala, el uso de memoria de los trabajos en segundo plano afectará el rendimiento del servicio web. Pero puede colocarlos en el mismo repositorio de código si lo desea, lo que tenga más sentido.
Una buena opción para la mensajería entre los dos procesos sería redis , si colocar un mensaje de vez en cuando está bien. Si desea "no dejar ningún mensaje", necesitará un corredor más pesado como Rabbit . Su proceso de servicio web puede publicarse y su proceso de trabajo en segundo plano puede suscribirse.
No es necesario que los dos procesos estén cohospedados, pueden estar en máquinas virtuales separadas, contenedores Docker, lo que sea que use. Esto le permite escalar sin muchos problemas.
Me gustaría sugerir el uso de Redis para programar trabajos. Tiene muchas estructuras de datos diferentes, siempre puede elegir una que se adapte mejor a su caso de uso.
Mencionaste a RoR y DJ, así que supongo que estás familiarizado con sidekiq. Puede usar node-sidekiq para la programación de trabajos si lo desea, pero es una imo subóptima, ya que su objetivo principal es integrar nodejs con RoR.
Para el demonio de los trabajadores, recomendaría usar PM2 . Es ampliamente utilizado y mantenido activamente. Resuelve muchos problemas (por ejemplo, implementación, monitoreo, agrupamiento), así que asegúrese de que no sea una exageración para usted.
Si desea algo ligero, que se ejecute en el mismo proceso que el servidor, le recomiendo Bull . Tiene una API simple que permite un control preciso sobre sus colas.
Si está buscando algo que funcione como un proceso de trabajo independiente, quizás busque en Kue . Puede ejecutarse como un servidor API RESTful e incluso tiene varias aplicaciones front-end escritas para él.
Si está familiarizado con Ruby''s Resque, hay una implementación de nodo llamada Node-resque
Bull, Kue y Node-resque están respaldados por Redis , que es omnipresente entre las colas de trabajadores de Node.js. Los 3 podrían hacer lo que hace DelayedJob de RoR, es cuestión de características específicas que desee y sus preferencias de API.
Si está utilizando MongoDB, le recomiendo Agenda . De esa manera, no se ejecutan instancias separadas de Redis y están presentes características como la programación, las colas y la interfaz de usuario web. La interfaz de usuario de Agenda es opcional y, por supuesto, se puede ejecutar por separado.
También recomendaría configurar una abstracción débilmente acoplada entre la lógica de su aplicación y el sistema de colas / programación para que se pueda cambiar todo el sistema de procesamiento en segundo plano si es necesario. En otras palabras, mantenga la mayor cantidad de lógica de aplicación / procesamiento lejos de las definiciones de trabajo de Agenda para mantenerlas livianas.
Sugiero usar un marco Node.js adecuado para compilar su aplicación.
Creo que el más potente y fácil de usar es Sails.js .
Es un marco MVC, así que si estás acostumbrado a desarrollar en ROR, ¡lo encontrarás muy fácil!
Si lo usa, ya presenta un poderoso administrador de trabajos (en términos de JavaScript).
new sails.cronJobs(''0 01 01 * * 0'', function () {
sails.log.warn("START ListJob");
}, null, true, "Europe/Dublin");
Si necesitas más información no dudes en contactarme!
Traté bee-queue y Bull y elegí toro al final. Primero elegí bee-queue b / c, es bastante simple, sus ejemplos son fáciles de entender, mientras que los ejemplos de toros son un poco complicados. El wiki de bee El origen de la cola de abejas también resuena conmigo. Pero el problema con bee es <1> su tiempo de resolución del problema es bastante lento, su última actualización fue hace 10 meses. <2> No puedo encontrar una manera fácil de pausar / cancelar el trabajo.
Bull, por otro lado, actualiza con frecuencia sus códigos, en respuesta a los problemas. La evaluación de la cola de trabajo de Node.js dijo que la debilidad del toro es "tiempo de resolución de problemas lento", ¡pero mi experiencia es lo contrario!
Pero de todos modos, su API es similar, por lo que es bastante fácil cambiar de una a otra.