source open kafka benchmark jms rabbitmq activemq message-queue zeromq

jms - open - ActiveMQ o RabbitMQ o ZeroMQ o



queue open source (17)

¿Por qué extrañas a Sparrow , Starling , Kestrel , Amazon SQS , Beanstalkd , Kafka , IronMQ ?

Servidores de cola de mensajes

Los servidores de la cola de mensajes están disponibles en varios idiomas, Erlang (RabbitMQ), C (beanstalkd), Ruby (Starling o Sparrow), Scala (Kestrel, Kafka) o Java (ActiveMQ). Una breve descripción se puede encontrar here

Gorrión

  • escrito por Alex MacCaw
  • Sparrow es una cola liviana escrita en Ruby que "habla memcache"

Estornino

Cernícalo

  • escrito por Robey Pointer
  • Un clon de Starling escrito en Scala (un puerto de Starling de Ruby a Scala)
  • Las colas se almacenan en la memoria, pero se registran en el disco

RabbitMQ

  • RabbitMQ es un servidor de cola de mensajes en Erlang
  • almacena trabajos en la memoria (cola de mensajes)

Apache ActiveMQ

  • ActiveMQ es un intermediario de mensajes de código abierto en Java

Habichuelas

  • escrito por Philotic, Inc. para mejorar el tiempo de respuesta de una aplicación de Facebook
  • Servicio de cola de trabajo en memoria escrito principalmente en C
  • Docu: here

Amazon SQS

Kafka

  • Escrito en LinkedIn en Scala
  • Utilizado por LinkedIn para descargar el procesamiento de todas las páginas y otras vistas
  • De forma predeterminada, el uso de la persistencia, utiliza el caché del disco del sistema operativo para los datos en caliente (tiene un mayor rendimiento que cualquiera de los anteriores teniendo habilitada la persistencia)
  • Soporta tanto el procesamiento en línea como fuera de línea

ZMQ

  • La biblioteca de socket que actúa como un marco de concurrencia.
  • Más rápido que TCP, para productos agrupados y supercomputación
  • Transporta mensajes a través de inproc, IPC, TCP y multidifusión.
  • Conecte N-to-N a través de fanout, pubsub, canalización, solicitud-respuesta
  • E / S asíncronas para aplicaciones de paso de mensajes de múltiples núcleos escalables

EagleMQ

  • EagleMQ es un administrador de colas de código abierto, alto rendimiento y ligero.
  • Escrito en C
  • Almacena todos los datos en memoria y soporte persistencia.
  • Tiene su propio protocolo. Soporta trabajos con colas, rutas y canales.

IronMQ

  • IronMQ
  • Escrito en Go
  • Servicio de cola completamente gestionado.
  • Disponible tanto en versión cloud como en local.

Espero que esto nos sea de utilidad. source

Nos interesaría escuchar cualquier experiencia con los pros y los contras de ActiveMQ vs RabbitMQ vs ZeroMQ. La información sobre otras colas de mensajes interesantes también es bienvenida.

Abie, todo se reduce a tu caso de uso. En lugar de confiar en la cuenta de otra persona de su caso de uso, no dude en publicar su caso de uso en la lista de debate de rabbitmq. Preguntar en twitter te dará algunas respuestas también. Mis mejores deseos, alexis

Acerca de ZeroMQ aka 0MQ, como ya sabrás, es el que te enviará la mayor cantidad de mensajes por segundo (fueron aproximadamente 4 millones por segundo en su servidor de ref la última vez que lo verifiqué), pero como ya sabrás, el La documentación es inexistente. Le resultará difícil encontrar la manera de iniciar el (los) servidor (es), y mucho menos cómo usarlos. Supongo que en parte es por eso que nadie contribuyó con 0MQ todavía.

¡Que te diviertas!

Escribí sobre mi experiencia inicial con AMQP, Qpid y ZeroMQ aquí: http://ron.shoutboot.com/2010/09/25/is-ampq-for-you/

Mi opinión subjetiva es que AMQP está bien si realmente necesita las facilidades de mensajería persistente y no le preocupa que el corredor pueda ser un cuello de botella. Además, el cliente de C ++ falta actualmente para AMQP (Qpid no ganó mi soporte; no estoy seguro acerca del cliente ActiveMQ, sin embargo), pero quizás haya un trabajo en progreso. ZeroMQ puede ser de otra manera.

Estoy usando zeroMQ. Quería un sistema de paso de mensajes simple y no necesito la complicación de un corredor. Tampoco quiero un gran sistema empresarial orientado a Java.

Si desea un sistema rápido y simple y necesita compatibilidad con varios idiomas (uso C y .net), le recomiendo que consulte 0MQ.

Hay una comparación de las características y el rendimiento de RabbitMQ ActiveMQ y QPID dado en
http://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/

Personalmente he probado los tres anteriores. Según mi opinión, RabbitMQ es el mejor rendimiento, pero no tiene opciones de recuperación y recuperación de fallos. ActiveMQ tiene la mayoría de las funciones, pero es más lento.

Actualización: HornetQ es también una opción que puede considerar, es JMS Complaint, una opción mejor que ActiveMQ si está buscando una solución basada en JMS.

Hay una comparación entre RabbitMQ y ActiveMQ here . Fuera de la caja, ActiveMQ está configurado para garantizar la entrega de mensajes, lo que puede dar la impresión de ser lento en comparación con los sistemas de mensajería menos confiables. Siempre puede cambiar la configuración de rendimiento si lo desea y obtener al menos un rendimiento tan bueno como cualquier otro sistema de mensajería. Al menos tienes esa opción. Hay mucha información en los foros y las preguntas frecuentes de ActiveMQ para la configuración de escala, rendimiento y alta disponibilidad. Además, ActiveMQ admitirá AMQP 1.0 cuando se finalice la especificación, junto con otros formatos de conexión, como STOMP.

Otra ventaja de ActiveMQ es su proyecto Apache, por lo que hay diversidad en la comunidad de desarrolladores y no está vinculado a una sola compañía.

Hay una discusión en los comentarios de esta publicación del blog , sobre cómo Twitter escribe su propia cola de mensajes, lo que puede ser interesante.

Steve realizó extensas pruebas de carga y estrés de ActiveMQ, RabbitMQ, etc. ActiveMQ es bastante lento (mucho más lento que Kestrel), RabbitMQ se bloquea constantemente con demasiados productores y muy pocos consumidores.

Probablemente no tengas una carga similar a Twitter inicialmente, sin embargo :)

He usado ActiveMQ en un entorno de producción durante aproximadamente 3 años. Mientras hace el trabajo, alinear las versiones de las bibliotecas cliente que funcionan correctamente y están libres de errores puede ser un problema. Actualmente estamos buscando la transición a RabbitMQ.

No he usado ActiveMQ o RabbitMQ, pero he usado ZeroMQ. La gran diferencia que veo entre ZeroMQ y ActiveMQ, etc., es que 0MQ no tiene intermediarios y no tiene confiabilidad integrada para la entrega de mensajes. Si está buscando una API de mensajería fácil de usar que admita muchos patrones de mensajería, transportes, plataformas y enlaces de idiomas, definitivamente vale la pena ver 0MQ. Si está buscando una plataforma de mensajería completa, es posible que 0MQ no se ajuste a la factura.

Consulte www.zeromq.org/docs:cookbook para ver muchos ejemplos de cómo se puede usar 0MQ.

Utilizo con éxito 0MQ para pasar mensajes en una aplicación de monitoreo de uso de electricidad (consulte http://rwscott.co.uk/2010/06/14/currentcost-envi-cc128-part-1/ )

Pocas aplicaciones tienen tantas configuraciones de ajuste como ActiveMQ. Algunas características que hacen que ActiveMQ se destaque son:

Tamaño de captación previa configurable. Subprocesos configurables. Conmutación por error configurable. Notificación administrativa configurable a productores. ... detalles en:

http://activemq.net/blog http://activemq.apache.org

Realmente depende de su caso de uso.

Comparar 0MQ con ActiveMQ o RabbitMQ no es justo. ActiveMQ y RabbitMQ son sistemas de mensajería que requieren instalación y administración. Ofrecen mucho más que ZeroMQ. Tienen colas reales persistentes, soporte para transacciones etc.

ZeroMQ es una implementación de socket orientada a mensajes ligeros. También es adecuado para la programación asíncrona en proceso. Es posible ejecutar un "Sistema de Mensajería Empresarial" en ZeroMQ, pero tendría que implementar mucho por su cuenta.

Asi que:

ActiveMQ, RabbitMQ, Websphere MQ y MSMQ son "colas de mensajes empresariales"

ZeroMQ es una biblioteca IPC orientada a mensajes.

Si también está interesado en implementaciones comerciales, debería echar un vistazo a Nirvana desde my-channel .

Nirvana se usa mucho en la industria de servicios financieros para plataformas de distribución de precios y operaciones de gran latencia y baja latencia.

Existe soporte para una amplia gama de lenguajes de programación de clientes en los dominios empresariales, web y móviles.

Las capacidades de agrupación en clústeres son extremadamente avanzadas y vale la pena verlas si la HA transparente o el equilibrio de carga es importante para usted.

Nirvana se puede descargar gratis para propósitos de desarrollo.

Solo puedo agregar mis 2 centavos sobre ActiveMQ, pero ya que es uno de los más populares:

El idioma que desea escribir puede ser importante. Aunque ActiveMQ tiene un cliente para la mayoría, su implementación de C # está lejos de ser completa en comparación con la biblioteca de Java.

Esto significa que alguna funcionalidad básica es inestable (protocolo de conmutación por error que ... bueno ... falla en algunos casos, no hay compatibilidad con la entrega) y otra simplemente no existe. Dado que .NET no parece ser tan importante para el proyecto, el desarrollo es bastante lento y no parece haber ningún plan de lanzamiento. El tronco a menudo se rompe, por lo que si considera esto, podría considerar contribuir al proyecto si quiere que las cosas sigan adelante.

Luego está el propio ActiveMQ que tiene muchas características interesantes, pero también algunos problemas muy extraños. Usamos la versión Fuse (Progress) de activemq por razones de estabilidad, pero incluso entonces hay un par de "errores" extraños que debes tener en cuenta:

  • Corredores que dejan de enviar mensajes en algunas ocasiones.
  • Los errores de diario que hacen que la cola muestre mensajes que ya no están allí (no se entregan al consumidor, pero aún así)
  • La prioridad aún no está implementada (está en la lista de problemas desde el inicio de la clase humana)
  • etcétera etcétera.

En general, es un producto bastante bueno SI puedes vivir con sus problemas:

A) no tienen miedo de involucrarse activamente al usar .NET
B) Desarrollar en java ;-)

ZeroMQ es realmente con cero colas! ¡Es realmente un error! No tiene colas, temas, persistencia, ¡nada! Es solo un middleware para sockets API. Si es lo que estas buscando genial! De lo contrario olvídalo! no es como activeMQ o rabbitmq.

Edit: Mi respuesta inicial tenía un fuerte enfoque en AMQP. Decidí reescribirlo para ofrecer una visión más amplia sobre el tema.

Estas 3 tecnologías de mensajería tienen diferentes enfoques para construir sistemas distribuidos:

RabbitMQ es una de las principales implementaciones del protocolo AMQP (junto con Apache Qpid). Por lo tanto, implementa una arquitectura de intermediario, lo que significa que los mensajes se ponen en cola en un nodo central antes de enviarlos a los clientes. Este enfoque hace que RabbitMQ sea muy fácil de usar e implementar, ya que solo en unas pocas líneas de código se admiten escenarios avanzados como enrutamiento, balanceo de carga o colas de mensajes persistentes. Sin embargo, también lo hace menos escalable y "más lento" porque el nodo central agrega latencia y los sobres de mensajes son bastante grandes.

ZeroMq es un sistema de mensajería muy ligero especialmente diseñado para escenarios de alto rendimiento / baja latencia como el que puede encontrar en el mundo financiero. Zmq es compatible con muchos escenarios de mensajería avanzados, pero al contrario de RabbitMQ, tendrá que implementar la mayoría de ellos mediante la combinación de varias partes del marco (por ejemplo, sockets y dispositivos). Zmq es muy flexible, pero tendrá que estudiar las 80 páginas de la guía (que recomiendo leer para cualquier persona que escriba un sistema distribuido, incluso si no usa Zmq) antes de poder hacer algo más complicado que enviar mensajes. entre 2 pares.

ActiveMQ está en el punto medio. Al igual que Zmq, se puede implementar tanto con el intermediario como con las topologías P2P. Al igual que RabbitMQ, es más fácil implementar escenarios avanzados, pero generalmente a costa del rendimiento en bruto. Es la navaja suiza de mensajería :-).

Finalmente, los 3 productos:

  • tener apis de cliente para los lenguajes más comunes (C ++, Java, .Net, Python, Php, Ruby, ...)
  • tener una fuerte documentación
  • son activamente apoyados