node.js - RabbitMQ vs Socket.io?
websocket amqp (3)
Actualizar
¿Hay escenarios en los que necesito RabbitMQ para aplicaciones web donde Socket.io no es suficiente? Los usuarios del navegador deberían poder comunicarse entre sí a través de un servidor node.js. Uno de los usuarios escribe un mensaje y todos los demás usuarios lo obtendrán.
Cuando solo tienes estos requisitos simples, socket.io solo será suficiente. . Solo necesita una queue mensajes cuando quiere procesar sus trabajos (pesados) fuera de línea y de forma controlada.
http://en.wikipedia.org/wiki/Message_queue :
Las colas de mensajes proporcionan un protocolo de comunicaciones asíncronas, lo que significa que el remitente y el receptor del mensaje no necesitan interactuar con la cola de mensajes al mismo tiempo.
Esta oración debe ser asimilada. El productor (un proceso) pone un trabajo en la cola y el consumidor consume tomando el trabajo de la cola. El consumidor, la mayoría de las veces, son procesos múltiples que consumen múltiples trabajos al mismo tiempo. El consumidor no puede diferenciarse entre sí sobre los trabajos que están consumiendo.
Esto hace que la cola sea una estructura de datos Primero en entrar, primero en salir (FIFO).
Eso es, creo, una propiedad importante de la cola. La propiedad First-In-First-Out, aunque con una cola de mensajes avanzada como beanstalkd, puede dar prioridad a los trabajos.
Espero que esto tenga algún sentido;)
Estoy haciendo un desarrollo de aplicaciones web en vivo en tiempo real.
¿Podría explicar un poco mejor para que podamos darle una mejor respuesta?
No entiendo cómo funciona RabbitMQ. Pero a partir de una lectura rápida, parece que maneja la publicación / suscripción de mensajes.
Vea la cita sobre la cola de mensajes a continuación. Deja que se hunda por un tiempo. También puede leer el WIKI sobre las http://en.wikipedia.org/wiki/Message_queue .
Un usuario (en un navegador) publica algo y los suscriptores (en otros navegadores) reciben ese mensaje. ¿No es eso lo que Socket.io está haciendo con websockets?
Socket.io admite una gran cantidad de transportes diferentes (también websockets) y debería ser así porque los websockets no son compatibles con la mayoría de los navegadores. Pero, por ejemplo, Google Chrome ya admite websockets. Creo que los websockets son el transporte del futuro (¡pero aún no!). Cuando veas la página de soporte del navegador de Socket.io, verás que Socket.io admite todos los navegadores principales (algunos incluso antiguos). Lo bueno es que esto envuelve una buena API.
¿Cuáles son las ventajas / desventajas para cada uno de ellos?
Estás comparando manzanas con naranjas, por lo que comparar eso es algo extraño.
RabbitMQ
http://www.rabbitmq.com/tutorials/tutorial-one-python.html :
RabbitMQ es un intermediario de mensajes. La idea principal es bastante simple: acepta y reenvía mensajes. Puede pensarlo como una oficina de correos: cuando envía un correo al buzón de correo, está bastante seguro de que el Sr. Postman eventualmente entregará el correo a su destinatario. Usando esta metáfora, RabbitMQ es un buzón, una oficina de correos y un cartero.
Ventajas
- Es una cola de mensajes bastante buena. Personalmente, usaría redis o beanstalkd .
Desventajas:
- No es realmente para "navegadores".
Socket.io
Socket.IO tiene como objetivo hacer posible las aplicaciones en tiempo real en cada navegador y dispositivo móvil, borrando las diferencias entre los diferentes mecanismos de transporte.
Ventajas
- Es para navegador
Desventajas
- No es una cola de mensajes.
¿Puede Socket.io reemplazar RabbitMQ?
No, no puedes porque son dos cosas completamente diferentes. Estas comparando manzanas con naranjas. Debería tratar de comprender ambas descripciones de los sitios que cité.
Estoy haciendo un desarrollo de aplicaciones web en vivo en tiempo real.
Los usuarios del navegador deberían poder comunicarse entre sí a través de un servidor node.js. Uno de los usuarios escribe un mensaje y todos los demás usuarios lo obtendrán.
No entiendo cómo funciona RabbitMQ. Pero a partir de una lectura rápida, parece que maneja la publicación / suscripción de mensajes.
Un usuario (en un navegador) publica algo y los suscriptores (en otros navegadores) reciben ese mensaje. ¿No es eso lo que Socket.io está haciendo con websockets?
Aquí están mis preguntas:
- ¿Cuáles son las ventajas / desventajas para cada uno de ellos?
- ¿Puede Socket.io reemplazar RabbitMQ?
- ¿Hay escenarios en los que necesito RabbitMQ para aplicaciones web donde Socket.io no es suficiente?
RabbitMQ es una forma realmente flexible de crear topologías de red. Es maduro, tiene soporte y proviene de un espacio financiero (en finanzas al que han estado enviando mensajes durante mucho tiempo). Uso RabbitMQ en el lado del servidor y uso otros protocolos para conectarme a RabbitMQ a través de una "puerta de enlace".
Detrás de escena, RabbitMQ está escrito en un lenguaje funcional ultra conciso llamado Erlang. Eso no es gran cosa en sí mismo, pero la afirmación es que si sabes lo que estás haciendo y puedes decirlo en menos líneas de código, entonces es más confiable y comprobable en última instancia.
Por cierto, Erlang es usado por Facebook y Twitter para sus cosas detrás de escena.
Ahora, RabbitMQ es más que solo un tipo de conexión de red ... se basa en la "entrega garantizada". Esa característica es importante para las situaciones empresariales. RabbitMQ, alternativamente, podría usarse para escalar ... en realidad, hay más que eso ... No le estoy haciendo justicia.
No puedo comentar en node.js ya que aún no he tenido la oportunidad de jugar con él. Estoy feliz con RabbitMQ.
re: socket.io (¿estamos hablando de websockets?): si esto es para el navegador (como sugiere la publicación anterior), podría vincularlo con RabbitMQ. es decir, RabbitMQ es tan flexible.
RabbitMQ se usa para pasar mensajes a través de las aplicaciones, no necesariamente a los usuarios en un navegador. A continuación, podría implementar un cliente RabbitMQ en node.js, por ejemplo, que empuje los mensajes recibidos a un navegador.
Ver http://www.rabbitmq.com/blog/2010/11/12/rabbitmq-nodejs-rabbitjs/ para un ejemplo.