Redis Vs RabbitMQ como um corretor de dados / sistema de mensagens entre Logstash e elasticsearch

89

Estamos definindo uma arquitetura para coletar informações de log por remetentes Logstash que são instalados em várias máquinas e indexar os dados em um servidor elasticsearch centralmente e usar Kibana como a camada gráfica. Precisamos de um sistema de mensagens confiável entre os remetentes Logstash e a elasticsearch para garantir a entrega. Quais fatores devem ser considerados ao selecionar o Redis em vez do RabbitMQ como um corretor de dados / sistema de mensagens entre os remetentes do Logstash e o elasticsearch ou vice-versa?

elasticsearch  redis  rabbitmq  logstash 
— Salindaw
fonte

Respostas:

93

Depois de avaliar o Redis e o RabbitMQ, escolhi o RabbitMQ como nosso corretor pelos seguintes motivos:

  1. O RabbitMQ permite que você use uma camada interna de segurança usando certificados SSL para criptografar os dados que você está enviando para o corretor e isso significa que ninguém vai farejar seus dados e ter acesso aos seus dados organizacionais vitais.
  2. RabbitMQ é um produto muito estável que pode lidar com uma grande quantidade de eventos por segundo e muitas conexões sem ser o gargalo.
  3. Na nossa organização já utilizávamos o RabbitMQ e tínhamos um bom conhecimento interno de utilização e uma integração já preparada com o chef.

Com relação ao escalonamento, o RabbitMQ possui uma implementação de cluster integrada que você pode usar além de um balanceador de carga para implementar um ambiente de broker redundante.

Meu cluster RabbitMQ é ativo ativo ou ativo passivo?

Agora, para o ponto mais fraco de usar RabbitMQ:

  1. a maioria dos remetentes de Logstash não suporta RabbitMQ, mas por outro lado, o melhor, chamado Beaver, tem uma implementação que enviará dados para RabbitMQ sem problemas.
  2. A implementação que o Beaver tem com o RabbitMQ em sua versão atual é um pouco lenta no desempenho (para meus propósitos) e não foi capaz de lidar com a taxa de 3000 eventos / s de um servidor e de vez em quando o serviço travava.
  3. No momento, estou trabalhando em uma correção que resolverá o problema de desempenho do RabbitMQ e tornará o remetente do Beaver mais estável. A primeira solução é adicionar mais processos que podem ser executados simultaneamente e darão mais poder ao remetente. A segunda solução é mudar o Beaver para enviar dados ao RabbitMQ de forma assíncrona, o que teoricamente deveria ser muito mais rápido. Espero terminar de implementar as duas soluções até o final desta semana.

Você pode acompanhar o problema aqui: https://github.com/josegonzalez/python-beaver/issues/323

E verifique a solicitação de pull aqui: https://github.com/josegonzalez/python-beaver/pull/324

Se você tiver mais perguntas, fique à vontade para deixar um comentário.

— Tom Kregenbild
fonte
3
O Redis tem algum ponto mais forte em comparação ao RabbitMQ? Redis parece mais fácil de configurar. E se você não precisa de um grande rendimento e a segurança está sendo tratada por outros meios, o RabbitMQ pode não ser necessário. Por favor me corrija se eu estiver errado.
— Ricardo MS
Você está correto, mas para ter certeza de que precisará comparar o desempenho entre os dois produtos
— Tom Kregenbild
4
"RabbitMQ é um produto muito estável que pode lidar com uma grande quantidade de eventos por segundo e muitas conexões sem ser o gargalo." - Tenho quase certeza de que é verdade também o reddis. Portanto, esta NÃO é uma vantagem do rabbitmq sobre o Reddit
— Martin Thoma
"RabbitMQ permite que você use uma camada interna de segurança usando SSL" - o reddis não permite a criptografia da camada de transporte também?
— Martin Thoma
2
2019 ainda o redis não tem TLS
— integrado
52

O Redis é criado como um armazenamento de dados de valor-chave, apesar de ter alguns recursos básicos do agente de mensagens.

RabbitMQ é criado como um agente de mensagens. Ele tem muitos recursos de agente de mensagens naturalmente.

— Ferhat
fonte
1
Sua declaração sobre o Redis não é mais precisa com a introdução do Stream no Redis 5. O RabbitMQ é definitivamente a melhor escolha para cenários de grande escala. Para um cenário de pequena a média escala (o que ocorre com a maioria dos projetos no mundo), o Redis é uma alternativa confiável, rápida e fácil de configurar.
— Reza
Obrigado pelo compromisso, seria bom se alguém escrevesse aqui sua experiência sobre as novidades do Redis.
— Ferhat
44

Eu tenho feito algumas pesquisas sobre este assunto. Se o desempenho é importante e a persistência não, o RabbitMQ é a escolha perfeita. Redis é uma tecnologia desenvolvida com um propósito diferente.

A seguir está uma lista de profissionais para usar RabbitMQ em vez de Redis:

  • O RabbitMQ usa o Advanced Message Queuing Protocol (AMQP), que pode ser configurado para usar SSL, uma camada adicional de segurança.
  • O RabbitMQ leva aproximadamente 75% do tempo que o Redis leva para aceitar mensagens.
  • RabbitMQ oferece suporte a prioridades para mensagens, que podem ser usadas por trabalhadores para consumir mensagens de alta prioridade primeiro.
  • Não há chance de perder a mensagem se algum trabalhador travar após consumir a mensagem, o que não é o caso do Redis.
  • O RabbitMQ possui um bom sistema de roteamento para direcionar mensagens para diferentes filas.

Alguns contras para usar RabbitMQ:

  • RabbitMQ pode ser um pouco difícil de manter, difícil de depurar travamentos.
  • As flutuações no nome do nó ou no ip do nó podem causar perda de dados, mas, se bem gerenciadas, as mensagens duráveis ​​podem resolver o problema.
— Arun Reddy
fonte
3
O Redis tem o Sorted Setsque permite interações do tipo fila prioritárias. O Redis também pode ser agrupado / fragmentado para enviar mensagens diferentes para filas diferentes em servidores diferentes. Não tenho certeza sobre SSL diretamente para Redis, mas estou olhando para AWS Elasticache e seu Redis 3.2.6 permite criptografia em repouso e em trânsito. Observação: não estou dizendo que Redis é o melhor para esse caso; apenas apontar esses pode não ser motivo para escolher RabbitMQ em vez de Redis.
— dwanderson
1
Além disso, não se esqueça de que o Redis é de thread único, portanto, se você tiver muitos editores / consumidores, isso pode ser um problema.
— Kedare
5

Eu estive me perguntando a mesma coisa. Recomendações anteriores do pessoal do Logstash recomendam Redis em vez do RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), no entanto, essa seção das notas não existe mais na documentação atual, embora haja notas genéricas sobre o uso de um corretor para lidar com picos aqui https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Embora eu também esteja usando o RabbitMQ com bastante satisfação, estou explorando um corretor Redis, uma vez que o protocolo AMQP é provavelmente um exagero para o meu caso de uso de registro.

— opennomad
fonte
2

Perguntas rápidas para fazer:

  1. por que você precisa de um corretor? Se você estiver usando logstash ou logstash-forwarder para ler arquivos desses servidores, ambos ficarão mais lentos se o pipeline ficar congestionado.
  2. você tem alguma experiência com administração de coelho ou redis? Todas as coisas sendo iguais, a ferramenta que você sabe como usar é a melhor ferramenta.

No reino das opiniões, administrei o redis como corretor e odiei. Claro, pode ter sido minha inexperiência com redis (não é um problema com o produto em si), mas era o elo mais fraco do pipeline e sempre falhava quando mais precisávamos.

— Alain Collins
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.