¿Existe alguna razón convincente para usar un servidor basado en AMQP sobre algo como beanstalkd o redis?

Question

Escribo una pieza en un proyecto que se encarga de procesar las tareas fuera de la aplicación principal frente al servidor de datos, que está escrito en javascript utilizando Node.js. Necesita manejar tareas que están programadas en el futuro y potencialmente manejar tareas que están "en este momento". El "ahora mismo" simplemente significa que la próxima vez que un trabajador esté disponible operará en esa tarea, por lo que ese bit podría no importar. Los trabajadores van a hablar todos a recursos externos, un trabajo de ejemplo sería enviar un correo electrónico. Somos una tienda pequeña y no tenemos una tonelada de recursos, así que una cosa que no quiero hacer es comenzar a mezclar idiomas en este punto del proceso, y ya veo que Node puede hacer esto por nosotros con bastante facilidad, así que eso es lo que vamos a hacer, a menos que vea una razón convincente para no hacerlo antes de comenzar a codificar, lo cual es pronto.

Dicho todo esto, no puedo decir si hay una razón de peso para utilizar un servidor basado AMQP, como OpenAMQ o RabbitMQ por algo como Kue o Beanstalkd con un nodo cliente. Entonces, aquí vamos:

¿Hay alguna razón convincente para usar un servidor basado en AMQP sobre algo como beanstalkd o redis con Kue? En caso afirmativo, ¿qué servidor basado en AMPQ encajaría mejor con la arquitectura que expuse? Si no, ¿qué solución nosql (beanstalkd, redis/Kue) sería más fácil de configurar y más rápida de implementar?

Answer 1

FWIW, todavía no acepto mi respuesta, explicaré lo que he decidido y por qué. Si no obtengo ninguna respuesta que parezca mejor de lo que he decidido, aceptaré la mía más tarde.

Me decidí por Kue. Es compatible con varios trabajadores que se ejecutan de forma asincrónica, y con el clúster puede aprovechar los sistemas multinúcleo. Se extiende fácilmente para brindar seguridad. Está respaldado con Redis, que se usa para todo esto, así que sé que no respaldaré mi servidor de procesos de trabajo con un software no probado (eso no quiere decir que ninguno de los otros esté probado).

El más razones convincentes por las que escogí Kue es que proporciona una API JSON para que las aplicaciones del cliente (el primer cliente sea una aplicación web, pero también estamos planeando hacer aplicaciones para teléfonos inteligentes) pueda agregar trabajos fácilmente sin pasar por el aplicación principal frente a instancia de nodo, por lo que puedo estar totalmente fuera del camino del resto de mi equipo mientras escribo esto. No necesito una ruta, no necesito nada, y todo está provisto para mí, así que no necesito escribir nada para apoyar esto. Esto tiene otra ventaja, con una extensión para proporcionar seguridad l/p, solo los clientes autorizados pueden agregar trabajos, por lo que no tengo que exponer directamente mi servidor redis a las aplicaciones cliente. También tiene una consola web integrada y la API permite que el cliente retire listas de trabajos asociados con un usuario dado muy fácilmente, de modo que podemos mostrar al usuario todas sus tareas programadas en una vista de calendario ingeniosa con 0 esfuerzo de mi parte .

La otra razón de peso es la falta de una curva de aprendizaje pronunciada asociada con la obtención de Redis y Kue por mí. He configurado redis antes, y Kue es simple y efectivo.

Sí, soy un desarrollador perezoso, pero soy el tipo de desarrollador perezoso.

ACTUALIZACIÓN:

tengo que trabajar y hacer trabajos, el rendimiento es increíble. Dividí la lógica de recopilación de tareas en su propia instancia de nodo, básicamente todo lo que tengo que hacer es implementar mi repositorio en una nueva máquina y ejecutar el nodo task-server.js para escalar mis trabajadores. Es posible que necesite agregar algunas llamadas de búsqueda de empleo a Kue, debido a cómo implícito algunas cosas, pero eso será fácil.