Redis Vs RabbitMQ como un agente de datos / sistema de mensajería entre Logstash y elasticsearch

90

Estamos definiendo una arquitectura para recopilar información de registro por parte de los remitentes de Logstash que están instalados en varias máquinas e indexan los datos en un servidor de elasticsearch de forma centralizada y utilizan Kibana como capa gráfica. Necesitamos un sistema de mensajería confiable entre los remitentes de Logstash y elasticsearch para otorgar la entrega. ¿Qué factores deben tenerse en cuenta al seleccionar Redis en lugar de RabbitMQ como agente de datos / sistema de mensajería entre los remitentes de Logstash y elasticsearch o viceversa?

elasticsearch  redis  rabbitmq  logstash 
— Salindaw
fuente

Respuestas:

94

Después de evaluar tanto a Redis como a RabbitMQ, elegí a RabbitMQ como nuestro corredor por las siguientes razones:

  1. RabbitMQ le permite utilizar una capa de seguridad incorporada mediante el uso de certificados SSL para cifrar los datos que está enviando al corredor y eso significa que nadie rastreará sus datos y tendrá acceso a los datos vitales de su organización.
  2. RabbitMQ es un producto muy estable que puede manejar grandes cantidades de eventos por segundo y muchas conexiones sin ser el cuello de botella.
  3. En nuestra organización ya usábamos RabbitMQ y teníamos un buen conocimiento interno sobre su uso y una integración ya preparada con el chef.

Con respecto al escalado, RabbitMQ tiene una implementación de clúster incorporada que puede usar además de un equilibrador de carga para implementar un entorno de agente redundante.

¿Mi clúster RabbitMQ es Activo Activo o Activo Pasivo?

Ahora, al punto más débil de usar RabbitMQ:

  1. la mayoría de los remitentes de Logstash no son compatibles con RabbitMQ pero, por otro lado, el mejor, llamado Beaver, tiene una implementación que enviará datos a RabbitMQ sin problemas.
  2. La implementación que Beaver tiene con RabbitMQ en su versión actual es un poco lenta en el rendimiento (para mis propósitos) y no pudo manejar la tasa de 3000 eventos / seg de un servidor y de vez en cuando el servicio fallaba.
  3. Ahora mismo estoy trabajando en una solución que resolverá el problema de rendimiento de RabbitMQ y hará que el cargador Beaver sea más estable. La primera solución es agregar más procesos que puedan ejecutarse simultáneamente y le darán más poder al transportista. La segunda solución es cambiar Beaver para enviar datos a RabbitMQ de forma asíncrona, lo que teóricamente debería ser mucho más rápido. Espero terminar de implementar ambas soluciones a finales de esta semana.

Puede seguir el problema aquí: https://github.com/josegonzalez/python-beaver/issues/323

Y verifique la solicitud de extracción aquí: https://github.com/josegonzalez/python-beaver/pull/324

Si tiene más preguntas, no dude en dejar un comentario.

— Tom Kregenbild
fuente
3
¿Redis tiene puntos más fuertes en comparación con RabbitMQ? Redis parece más fácil de configurar. Y si no necesita un gran rendimiento y la seguridad se gestiona por otros medios, es posible que RabbitMQ no sea necesario. Por favor corrígeme si estoy equivocado.
— Ricardo MS
Tiene razón, pero para estar seguro deberá comparar el rendimiento entre los dos productos
— Tom Kregenbild
4
"RabbitMQ es un producto muy estable que puede manejar grandes cantidades de eventos por segundo y muchas conexiones sin ser el cuello de botella". - Estoy bastante seguro de que eso también es cierto en Reddis. Así que esto NO es una ventaja de rabbitmq sobre Reddit
— Martin Thoma
"RabbitMQ le permite utilizar una capa de seguridad incorporada mediante SSL". ¿Reddis no permite también el cifrado de la capa de transporte?
— Martin Thoma
2
2019 aún no tiene TLS integrado en
— Redis
55

Redis se crea como un almacén de datos de valor clave a pesar de tener algunas capacidades básicas de intermediario de mensajes.

RabbitMQ se crea como un intermediario de mensajes. Tiene muchas capacidades de intermediario de mensajes naturalmente.

— Ferhat
fuente
1
Su declaración sobre Redis no es más precisa con la introducción de Stream en Redis 5. Definitivamente, RabbitMQ es una mejor opción para escenarios a gran escala. Para un escenario de pequeña a mediana escala (como lo son la mayoría de los proyectos en el mundo), Redis es una alternativa confiable, rápida y fácil de configurar.
— Reza
Gracias por el compromiso, sería bueno que alguien escribiera aquí su experiencia sobre las nuevas funciones de Redis.
— Ferhat
44

He estado investigando un poco sobre este tema. Si el rendimiento es importante y la persistencia no lo es, RabbitMQ es una elección perfecta. Redis es una tecnología desarrollada con una intención diferente.

A continuación se muestra una lista de ventajas para usar RabbitMQ sobre Redis:

  • RabbitMQ utiliza el Protocolo de cola de mensajes avanzado (AMQP) que se puede configurar para utilizar SSL, una capa adicional de seguridad.
  • RabbitMQ tarda aproximadamente el 75% del tiempo que tarda Redis en aceptar mensajes.
  • RabbitMQ admite prioridades para los mensajes, que los trabajadores pueden usar para consumir primero los mensajes de alta prioridad.
  • No hay posibilidad de perder el mensaje si algún trabajador falla después de consumir el mensaje, lo que no es el caso de Redis.
  • RabbitMQ tiene un buen sistema de enrutamiento para dirigir mensajes a diferentes colas.

Algunas desventajas de usar RabbitMQ:

  • RabbitMQ puede ser un poco difícil de mantener y de depurar fallos.
  • Las fluctuaciones de nombre de nodo o ip de nodo pueden provocar la pérdida de datos, pero si se gestionan bien, los mensajes duraderos pueden resolver el problema.
— Arun Reddy
fuente
3
Redis tiene Sorted Setsque permiten interacciones prioritarias similares a colas. Redis también se puede agrupar / fragmentar para enviar diferentes mensajes a diferentes colas en diferentes servidores incluso. No estoy seguro acerca de SSL directamente para Redis, pero estoy buscando AWS Elasticache y su Redis 3.2.6 permite el cifrado en reposo y en tránsito. Nota: no digo en absoluto que Redis sea mejor para este caso; solo señalar que esas pueden no ser razones para elegir RabbitMQ en lugar de Redis.
— dwanderson
1
Además, no olvide que Redis tiene un solo hilo, por lo que si tiene muchos editores / consumidores, eso puede ser un problema.
— Kedare
5

Me he estado preguntando lo mismo. Las recomendaciones anteriores de la gente de Logstash recomiendan Redis sobre RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), sin embargo, esa sección de las notas ya no existe en la documentación actual, aunque hay notas genéricas sobre el uso de un corredor para lidiar con picos aquí https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Si bien también estoy usando RabbitMQ con bastante satisfacción, actualmente estoy explorando un corredor de Redis, ya que es probable que el protocolo AMQP sea excesivo para mi caso de uso de registro.

— opennomad
fuente
2

Preguntas rápidas para hacer:

  1. ¿Por qué necesita un corredor? Si está utilizando logstash o logstash-forwarder para leer archivos de estos servidores, ambos se ralentizarán si la canalización se congestiona.
  2. ¿Tiene alguna experiencia en la administración de conejo o redis? En igualdad de condiciones, la herramienta que sabe cómo utilizar es la mejor herramienta.

En el ámbito de las opiniones, he manejado redis como corredor y lo odiaba. Por supuesto, esa podría haber sido mi inexperiencia con redis (no es un problema con el producto en sí), pero era el eslabón más débil en la tubería y siempre fallaba cuando más lo necesitábamos.

— Alain Collins
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.